Introduction To Serverless Architecture
To understand what serverless architecture is, it helps to know what servers are. A server is a machine (such as a computer system) that manages network resources. Its purpose is to store, manage, send, and process data. There are many types of servers, such as web servers, proxy servers, cloud servers, and dedicated servers. If you’re developing apps for your business, then you’ll need an application server. However, setting up and managing your own server can be very challenging, especially dealing with any issues that occur. Apps may also require more resources to run as you add functionality or their use increases. It’s due to these challenges that you may want to consider a serverless architecture.
Serverless Architecture Defined
Even though it’s called a “serverless” architecture, this term is a little misleading. You will still need a server to deploy your apps to the cloud. The reason it’s called “serverless” is because you don’t have to set up the server on your own. Instead, the server is set up and managed by any number of cloud solution providers on your behalf. It’s essentially a type of cloud computing in which your service provider handles all server-related tasks and responsibilities for you. By using a serverless architecture, you won’t have to provision, scale, or manage any of the servers you’re actually using to deploy your apps to the cloud.
Serverless vs. Traditional Architecture
Traditional architecture is a server that is accessed online to provide information or services. For example, traditional servers are used to host websites and to deliver them to your browser. Servers can be very expensive to set up, especially for enterprise-sized businesses. The larger they are, the more space they take up and the more they cost to maintain. With a serverless architecture, you don’t need to set up and manage a server on-site.
What Are Functions as a Service (FaaS)?
FaaS is a form of serverless architecture that allows you to develop, run, and manage the functionalities of your apps without having to build a server. FaaS tends to be used for building microservices apps because it can provide on-demand functionality and won’t incur charges when not in use.
Functions As A Service (FaaS) Vs Platform as a Service (PaaS)
At first glance, FaaS may seem like the exact same thing as PaaS. Although they are both examples of serverless architecture, there is one major difference. A PaaS will always have at least one server process running at any given moment that is receiving external requests. In order to scale, a PaaS will have to boot up additional server processes. The PaaS provider will charge the developer directly for this and as a result, scalability remains visible despite the service being serverless.
Unlike PaaS, FaaS does not require server processes to be running at all times. This does mean that initial requests can take slightly longer; however, caching can be enabled to ensure that future requests are executed almost instantly. The big advantage is that with FaaS, you’ll only pay for function execution time and not for the process idle time that you’ll be charged for with PaaS. Basically, FaaS provides higher scalability and lower costs, while Paas provides lower latency.
Benefits Of Serverless Architecture
There are numerous advantages to using a serverless architecture over a traditional architecture. The following are some of the major benefits of a serverless architecture to consider:
Reduce Operational Cost
Renting or buying the machinery required to set up servers on-site can be very expensive. Not to mention that you’ll only have a set amount of resources to use. When scaling is required, you may need to set up more servers. And as technology advances, your older systems will need to be replaced. As you can see, going serverless will eliminate installation costs, dependency costs, maintenance costs, support costs, patching costs, and license costs.
It’s also worth mentioning again that there will be periods of idle time or underutilization which you will still be paying for if you have on-site servers. With an FaaS serverless architecture, you won’t be paying for the servers you are using during these down times. Finally, with a serverless architecture, you’ll be sharing a predefined service with others, which means that the economy of scale can help lower your costs even more.
Elasticity Vs Scalability
Scalability is never a problem with a serverless architecture. Normally, your developers would have to set up and tune your auto-scaling policies or systems. With a serverless architecture, whoever you choose as your provider will be responsible for scaling the capacity of your server to make sure that the current demand is met. Not only can capacity be increased automatically when needed, it can be decreased as well. This is known as elasticity.
This flexibility will enable your developers to run code themselves without having to rely on support and infrastructure engineers. It also means that because your serverless architecture can scale down when demand is low, you’ll only be paying for the resources you need.
Effect on Productivity
Through FaaS, you’ll be able to simply back-end software development since developers will no longer have to directly handle multithreading or HTTP requests in their code.
Easier Operational Management
Besides saving money, the use of serverless architecture can actually improve operational management as well. These are just a few ways in which serverless architecture can help make operational management easier:
Automatic Scaling Reduces Operational Management
Because scaling is automatic with an FaaS, your team won’t have to worry about how many requests you can handle concurrently before running out of memory or experiencing a decline in performance.
Simpler Packaging And Deployment
It’s relatively easy to package and deploy a FaaS function, and entails merely packaging your code into a zip file. With a traditional server architecture, the process would be much more involved. And if you’re just beginning to build a new app, you won’t even have to upload anything. You can just write your code directly into the console of your provider.
Lesser Time To Market
Since less time is spent on operations, deploying your apps or making any changes to your apps takes far less time than usual. This is particularly advantageous for development teams that have implemented an agile software development process. With the ability to add and change code piece by piece, you’ll eliminate the traditional deployment process roll out, which is typically much more complicated.
Greener Computing
Cloud computing, in general, has contributed to greener computing in that companies don’t have to build servers on-site. Through serverless architecture, such as FaaS, companies will also make much more efficient use of their resources and not use resources they don’t need.
Drawbacks
Although there are many benefits to using serverless architecture, there are a few drawbacks to be aware of before you decide to use one. Here are some of the main drawbacks of a serverless architecture:
Performance
Since serverless code isn’t running when not in use, it can result in greater response latency when compared to code that’s continuously running on a dedicated server. If it takes the runtime a particularly long time to get started, it will extend the latency even further. Either way, the performance can be diminished.
Resource Limits
Providers often put a limit on resources, which means that serverless architecture may not be the best option for high-performance computing needs.
Monitoring And Debugging
Monitoring the performance of your code or identifying excessive resource usage issues can be a lot more difficult when using serverless architecture. Even though you can time entire functions, you won’t be able to attach debuggers, APM tools, or profilers to more effectively diagnose the issue. You also won’t be able to replicate performance characteristics within a local environment since the environment that the code runs on in a serverless architecture is rarely open source.
Security
Although the provider is responsible for taking care of certain operating system vulnerabilities, the total attack surface will be much bigger than if you were using a traditional server architecture, thereby increasing the likelihood of a successful attack. This is because a serverless architecture consists of more components than a traditional architecture — and each one of those components is a potential entry point to your serverless application.
Privacy
When using a serverless architecture, there will be a couple of potential privacy concerns that you should be aware of. It’s not uncommon for a serverless environment to run on a proprietary public cloud environment. This can cause some privacy issues since you will be sharing resources with other companies being hosted by the vendor and because external employees may have access.
Vendor Lock-In
Different providers implement serverless architecture in different ways. This means that switching from one provider to another can present a real challenge since you will need to update your operational tools, make changes to your code, and possibly even change your design or architecture. Moving your code from one serverless architecture to another is going to be quite difficult as well. This is because it won’t be possible to do so without moving other parts of your infrastructure. Basically, once you choose a vendor, it will be difficult to move to a different vendor in the future.
Recommended Users
Serverless architecture makes complete sense for businesses with smaller needs, or if they have apps with few functions that require hosting. This way, they don’t have to devote internal resources to setting up and maintaining a server. However, the efficient use of resources makes serverless architecture a good fit for enterprises hosting complex applications as well.
Take for example the digital agency Postlight. Their Readability Parser API was available for free and was used by several of their tools, including their Mercury Reader Chrome extension, which can be used to remove ads from articles. Unfortunately, it was costing them roughly $10,000 a month to host their Readability Parser API for free. To cut costs and make the API more effective, they rewrote it in JavaScript and switched to a serverless architecture. One of the major expenses contributing to the high monthly bill was their data expenses. When they switched to serverless, they eliminated the use of a database, replaced it with short-term caching instead, and dropped their cost to $370 a month.
Components Of a Serverless App
There are several vendors to choose from when it comes to developing serverless apps, the most popular of which is arguably AWS. Since AWS Lambda is generally considered the most popular option, let’s look at the components of a serverless app built using their serverless architecture. In this case, a serverless app will include the client application, the web server, the Lambda Functions, the security token service, the user authentication, and, finally, the database.
Client Application
Your app’s user interface is rendered on the client side in a modern frontend JavaScript app. This allows you to use a simple and static web server. AWS officially supports a variety of languages, including not just Java, but also Node.js, Go, C#, Ruby, and Python.
Web Server
A serverless app still needs to be hosted on a web server. Amazon S3 offers a simple web server on which all of your app’s static HTML, CSS, and JavaScript files can be served.
Lambda Functions (FaaS)
Different functions are used in different serverless architecture providers as the key enablers of your app. Lambda functions are used for the AWS Lambda framework.
Lambda’s Business Model
In more traditional cloud-based business models, virtual machines or containers are leased to the customer. These machines and containers all have network addresses and might as well be called servers. When leasing one of these “servers,” you pay for the amount of time that the server exists and all of the resources that it consumes.
The Lambda business model is a lot different. Instead of leasing a “server” you lease a “function.” The function is a unit of code that executes a task on behalf of some other code, such as a web app. You’re only leasing this unit of code for the amount of time that it’s alive, meaning that you’re only paying for the time that the code is operating. The total cost of leasing a function is based on not just the amount of time that the space is active, but also the size of the memory space that’s reserved for the function.
Lambda Calculus
The term “Lambda Function” is based on the Lambda calculus, which is a formal system in mathematical logic that can get quite complicated. It’s a universal model of computation introduced in the 1930s by the well-known mathematician, Alonzo Church, who was researching the foundations of mathematics. The Lambda function uses the Lambda calculus very loosely as it only takes one argument and returns a value for that argument.
Security Token Service (STS)
Security token service provides the users of your app with a temporary API key and secret key that can be used by the client app to invoke the Lambda functions. Basically, your administrators can use the STS, which is a software tool, to grant users they trust with temporary and limited access to public cloud resources. These keys are generally valid for a short period of time, whether it be for minutes or hours. Once expired, AWS will no longer provide access to API requests; however, end-users can request new credentials once their access has expired.
User Authentication
Amazon uses an identity service called AWS Cognito, which is integrated with AWS Lambda. This feature allows you to add user sign-up and sign-in features to both mobile and web apps without difficulty. It can authenticate users through social identity providers as well, including not just Amazon but also Facebook and Twitter.
Database
Serverless architecture still requires servers, which means that databases are required as well (although a database is not always essential for a serverless app). For example, Amazon’s AWS DynamoDB offers its clients a fully managed NoSQL database. Other types of databases used for serverless architecture include Google Cloud Store, FaunaDB, and Amazon Aurora Serverless.
Popular Applications
Serverless architecture can be used for all kinds of different applications. Popular applications of a serverless architecture include:
Google Cloud’s Serverless Platform
Amazon’s AWS isn’t the only serverless platform in the game. Google also offers a highly-regarded serverless platform in the form of Google Cloud. Here’s what you can expect when choosing Google Cloud as your serverless solution provider.
Features
Google is known for building comprehensive feature sets for its users, and this is no different when it comes to its serverless platform. Some of the main features offered by Google Cloud’s serverless platform include:
Write Your Preferred Code
One of the big advantages that Google Cloud has over other serverless solutions is that it allows developers to use whatever languages, frameworks, runtimes, and libraries that they want. This flexibility allows your development team to work to their strengths. Additionally, you’ll be able to deploy your code as functions, source code, containers, or apps.
Serverless For Compute And Beyond
Google not only provides exceptional compute services, they also offer data storage, data analytics, messaging, and machine learning services through their Google Cloud platform. They will handle all infrastructure-related tasks, from configuring and provisioning to scaling, load balancing and general management, leaving you to focus on building your apps.
Run Serverless Workloads Anywhere
Another significant advantage afforded by Google Cloud’s serverless platform is that you can move your serverless workloads to any platform you want. This can be done without sacrificing a consistent developer experience. Through the use of the Knative open API and the Kubernetes runtime environment, you’ll be able to run your workloads on Google Cloud, on-site, or on a third-party cloud provider.
UI-Driven Applications
Using a traditional architecture, all flow, control, and security is managed by a central server application. When using a serverless architecture, these matters will not be managed by a central go-between. With a serverless architecture, choreography is favored to orchestration. Each one of these matters plays a more architecturally aware role, resulting in more flexibility and making the UI-driven app more adaptable to change.
However, while a serverless architecture does allow for a better division of concerns, it does make the app a little more complex as a result of the multiple backend components, and it will require better distributed monitoring as a result. It also means that you will need to depend more on the security capabilities of the underlying platform.
Message-Driven Applications
Message-driven applications are user-centric apps that must be able to instantly respond to UI requests. They must also be able to capture the user activity data for processing. A good example of this is an online ad. When a user clicks on an ad, it will need to redirect them to a landing page as quickly as possible. As this happens, you also need to collect data concerning the event of the click so that the advertiser can be charged.
In a traditional architecture, such an application would function like this: the ad server would respond to the user and post a click message to a channel at the same time. The message would then be processed by a click processor app to update the database. This would not happen at the same time. With a serverless architecture, this process would change slightly.
In a serverless environment, the message-consumer app would be replaced with an FaaS function that runs within an event-driven context provided by the serverless solution provider. The vendor is responsible for both the FaaS environment and the message broker, which is why those two systems are closely related in a serverless architecture. Additionally, within an FaaS environment, several messages can be processed at the same time through the initiation of multiple copies of the function code.
Companies That Use Serverless Applications
Countless enterprise-sized companies use serverless applications to their advantage. The following are a few well-known examples:
- Netflix – Netflix is constantly adding to its streaming app. Studios send the media files of their movies and TV shows. Netflix has to parallel process and encode all of these files before repackaging and deploying them. They add new content on a daily basis and they serve 7 billion hours of video to over 50 million customers throughout 60 different countries. To improve the efficiency of their processes, reduce their error rates, and to save time, they count on AWS Lambda to build a rule-based, self-managing infrastructure.
- Reuters – Reuters uses serverless architecture for its analytics service. Using AWS, it is capable of processing upwards of 4,000 events per second and can reliably handle traffic that spikes to up to twice their normal size.
- AOL – AOL has closed a significant number of data centers in addition to having decommissioned roughly 14,000 in-house and collocated servers as a result of the adoption of serverless architecture. Not only have they been able to save millions of dollars on energy resources, they have also improved their ability to extend their global reach.
- Telenor – Telenor is a company that designs and develops IoT (Internet of Things) solutions to companies like Volvo and Hitachi. They have adopted serverless architecture via AWS for all new service development, which has allowed them to cut their development time for new IoT products in half, allowing it to speed up its clients’ time-to-market.
- Intent Media – Intent Media is a machine learning company that focuses on the travel industry. They help companies implement predictive analytics that help maximize revenue per website visitor. To do this, they process a massive amount of data on the behavior of visitors every day. Before switching to a serverless architecture, Intent Media was constantly running up against its 23 TB limit, which forced engineers to make technical compromises. It also resulted in massive administrative overhead since all administration and management in the cloud was performed in-house. They also experienced downtime a few times every year. Switching to serverless architecture helped solve many of these issues as a result of the ability to scale on demand.
- IBM MQSeries – IBM MQ is a messaging middleware platform that provides flexible and dependable messaging for applications. It facilitates the exchange of information using messaging queues and provides a single messaging solution for a variety of environments, including on-premise, IoT, mobile, and cloud. Through the use of AWS Quick Starts, clients can deploy production-ready IBM MQ servers on AWS into a configuration of their choice.
Serverless Architecture Is The Future
There are many advantages to going serverless. A serverless architecture allows you to make more efficient use of your resources, can greatly reduce costs, and can help you get to market quicker. But the main advantage of using a serverless architecture over a traditional architecture is that it will allow you to focus on developing your apps instead of spending valuable time and resources on setting up and maintaining infrastructure.
While there are a few drawbacks to going serverless, these drawbacks will certainly be addressed as the technology improves. It also hasn’t stopped some of the biggest companies in the world, such as Coca Cola and Netflix, from going serverless. They know that serverless architecture will set the standard in the not too distant future.
Do you need guidance with serverless architecture? Get in touch with our experts today!