You can consider serverless computing the next evolutionary step to make things easier for developers. Data centers, virtual machines, Elastic Compute Cloud (EC2), Simple Storage Service, and so on – these were the steps that brought us to today’s notion of serverless architecture.
What does this term encompass? How exactly does it benefit developers? And, more importantly, how can you leverage it in everyday software development? Let’s start with the basics and then pinpoint some benefits and challenges of serverless architecture.
Table of Contents
Serverless is a cloud-based code execution model where cloud providers, instead of developers, deal with servers and computing resource management. There are no virtual machines or physical servers: they are deployed automatically in the cloud by vendors.
Cloud providers take care of provisioning, maintaining, and scaling the serverless architecture. What’s more, the serverless architecture allows launching apps as needed: you don’t pay for ‘always-on’ server components to run your app when it’s not being used. Instead, some event triggers app code, and the resources are dynamically allocated for that code. You stop paying as soon as the code is executed.
So, in a nutshell, serverless architecture is a way to build your cloud-based application without managing infrastructure. It eliminates the need for routine tasks like security patches, capacity management, load balancing, scaling, etc.
Still, serverless does not mean there are no servers at all. The term is somewhat elusive. Servers are simply eliminated from the app development since they are managed by the vendors.
An application like this usually consists of single-purpose functions where one function means one action execution. A developer creates a module or function that executes a certain action and sends it to the cloud provider. To update it, a developer uploads a new version and initiates the change. At the same time, the developer integrates pre-built backend services with a serverless architecture.
There is one more thing that can take the infrastructure management burden off developers – containers. While also cloud-based, and allowing breaking and deploying applications into small units, containers are quite different from serverless computing.
Unlike traditional servers and virtual machines, serverless computing and containers allow developers to build more flexible and scalable apps. Despite these similarities, serverless and containers have quite a few differences.
Both serverless computing and containers significantly reduce infrastructure expenses, but serverless more so. While serverless architecture provides more speed to releases and iterations, containers offer more control over the environment. It is also possible to use hybrid architectures.
One more concept we should distinguish from serverless computing is FaaS. We can separate two types of serverless – BaaS (backend-as-a-service) and FaaS (functions-as-a-service), which are overlapping.
BaaS includes apps that use third-party servers to manage server-side logic (the backend is the service). With FaaS, you upload frontend code to a service like AWS Lambda or Google Cloud Functions, and the provider takes care of backend things like provisioning, managing processes, etc. The server-side logic remains in developers’ hands, but it runs in stateless compute containers. FaaS here is your code as a third-party platform that you pay for only when you use it.
FaaS can be used without serverless architecture. You can replace part of your app with the FaaS functionality, but it can increase computing costs when the need to scale arises. Instead, serverless computing offers a broader range of functionality than pay-per-use FaaS options since it encompasses a variety of technologies and is considered more cost-efficient.
While serverless computing started as FaaS, it includes all sorts of cloud services now. There are eight common types of serverless systems, distinguished due to their primary purpose.
In a serverless compute service like AWS Lambda, developers can run code on-demand or on-schedule. The FaaS platform will provide containerized runtime only. In addition to supporting the most popular runtimes such as Python, Node.js, .NET, and so on, some platforms support custom runtimes as well.
AWS Lambda allows implementing external API calling, writing data to a database, authenticating a user login, and almost anything else a traditional infrastructure offers.
Queuing services hold data when it is moved from one part of an app to another. It decouples services with an asynchronous communication process and controls the volume of data. AWS SQS is a service for queuing.
This system receives the flow of data packages and analyzes and processes them in real-time. It can be used as a buffer, but stream processing is more useful for analytics: detecting patterns, applying conditions, and reacting according to circumstances. AWS Kinesis can process video and data streams, data firehose, and data analytics.
It allows receiving messages from different sources and delivery to various destinations. The event bus resembles a queue buffer, but it can process multiple topics while a queue works with particular messages only. You can set custom rules for delivering messages to subscribers. AWS EventBridge event bus has numerous third-party integrations, from customer support to security suits.
The serverless database space range is vast:
Blob storage, such as AWS S3, is used to store text files, videos, or images. For big data analysis, it is integrated with Lambda and Amazon Athena.
The most common models for API implementation are REST and Graph. REST allows two systems to communicate with the help of HTTP methods. It requires knowing the endpoints, parameters, and filters in advance. For REST architecture, there is an AWS API Gateway. Graph API allows combining filters, selecting which data points to return, aggregating information before retrieval, etc. For Graph, there is the AWS AppSync service.
A serverless user management system allows apps to authenticate, authorize, and manage users applying high-level security standards. AWS Cognito provides the level of security that can be replicated by an extended app development team only.
Here’s an example of how different types of serverless systems can be combined in one ecommerce app:
We’ve already mentioned that serverless is much more convenient and offers more functionality than traditional server-based infrastructures. Developers can make releases faster, scale better, and reduce infrastructure expenses. Let’s explore these points in more detail.
Developers can focus on business logic since infrastructure provisioning, management, and scaling are not their tasks anymore. Also, the function code is faster to write as it is designed to do one thing at a time. Updates are quick and easy as well: the new code is uploaded, and changes are initiated through calling API, without deploying the entire application.
Serverless architecture includes BaaS building blocks for common functionalities – the types of serverless systems mentioned in the previous paragraph. So, you have ready-made solutions for databases, file storage, API, etc., which help you integrate your app with backend services and instantly reach system stability.
Serverless architectures can scale both up and down according to the demand for the specific functions. The providers ensure horizontal autoscaling, so any unexpected traffic spikes are accounted for, and won’t put your system down.
We’ve already mentioned this benefit: developers pay only for the number of resources they use. There’s also an offering from AWS Lambda for a free usage tier that includes 1M requests per month and 400,000 GB-seconds of compute time.
This pricing model boils down to reduced operational costs, as you pay for the executed code only (which is milliseconds), and it means around 30% monthly savings on memory usage.
With all these advantages, there are still some limitations to a serverless architecture.
Despite the fast adoption of serverless, people still often choose server-centric infrastructures. The main concerns around serverless app development are function timeouts, minimal time-lag, costly cloud migration, privacy, and vendor lock-in. They fall under the following groups.
Running on Lambda, serverless apps may have several performance issues:
Since serverless infrastructures span across multiple services and functions, issue detection and debugging becomes a real challenge. There are solutions for gathering logs and metrics, but there’s still a lot of data to analyze. Specific third-party tools like Dashbird, Thundra, etc. can help you out here: you can automate visualization, set alerts, and get some insights into the root of the problem and release pipelines.
Serverless architectures are allocated on public cloud environments and have significantly more surface area than traditional apps. Therefore, watch out for functions with overly generous IAM policies, outdated libraries, and unauthorized requests.
Migrating to the cloud and migrating from one cloud to another is quite a challenge since serverless is specific to every provider. While there are tools like the Serverless Framework, managing multi-cloud workloads requires significant effort. On the other hand, cloud providers offer rich and varied services, so the need to switch a provider may never arise.
One more issue is that your expenses will grow with the number of levels you need to manage. Containers may turn out less expensive when you need to host multiple layers of complex logic, or something that runs 24/7, with consistent workloads. In this case, having everything in one container will make sense.
Speaking of cost, let’s have a closer look at how serverless cloud services are billed.
Pay-per-use is a standard model for all cloud providers. But there’s more to that. Let’s take AWS Lambda and Azure Functions, for example: the cost per function invocation is 20 cents for one million invocations. Sounds cheap, right? However, this is not the main element of the total cost.
Since the invocation of functions requires significant computing resources, FaaS providers also charge for the combination of allocated memory and function execution time. For AWS Lambda, it’s $0.00001667 for every GB-second used. The amount of memory is configurable, therefore the price of function execution depends on configuration.
Even considering the additional expenses, the use of Lambda is still very cheap: one million invocations with the average time of 500 ms and 128 MB allocated memory will cost you around $1.25. If run continuously, this function will cost you nearly $6 per month. Furthermore, in an attempt to attract more users, AWS Lambda and Azure Functions offer generous free tiers to a function using 128 MB of memory running 24/7 for a month.
Still, serverless architecture is not always a money saver. Certain workloads require considerable computing resources, and functions should be validated against the FaaS environment limitations.
Also, we recommend comparing the price of serverless functions from different providers here. Historically, Amazon was the first cloud provider to offer a FaaS platform, AWS Lambda. Other providers you can consider are Google, with Cloud Functions, and Microsoft, with Azure Functions, as well as open-source alternatives such as Apache OpenWhisk, Spring Cloud Functions, and Fn Project.
At Relevant, we opt for AWS serverless architecture because of all the benefits we’ve mentioned: it helps to start quickly, gain system stability instantly, and reduce time to market significantly. It scales automatically, costs less, and our clients love the TCO of their serverless applications.
We know a thing or two about developing serverless apps, so drop us a line if you need help or want to find out more about our expertise.