What is Serverless?
Overview
The term ”Serverless” is a misnomer. Your code (or data) does reside in servers (or at least in storage volumes that can be attached or mounted to servers), but their infrastructure and management are so removed from the developer, that it feels “Serverless”. This type of service/product is also known as Function-as-a-Service. Today, serverless products come in many forms, but their fundamental principle remains the same. The developer provides the application code (or data) to the serverless service and the Cloud provider handles all aspects of management for the runtime of that code. That management can be configured. For example, maximum concurrency is a typical configuration that a developer can provide.
The history of serverless computing can be traced back to the early days of cloud computing when AWS introduced AWS Lambda in 2014, the first serverless function service. With serverless functions, developers write a function that would otherwise exist in a small application. This function accepts objects as arguments that are standard across all invocations. However, the contents of those objects are not necessarily the same across all invocations since request arguments are passed through these objects. The application code is loaded onto a virtual machine and that code is invoked as soon as a request arrives. This all happens very quickly — often in less than a second.
How AWS Lambda Works
Source: AWS Re:Invent 2022 Keynote (it is public information).
AWS Lambda uses a specialized virtual machine with minimal overhead that is able to start up in milliseconds called Firecracker.
- It starts up using a common snapshot that has all the dependencies for the language’s environment pre-installed.
- Then, your function-specific code is transferred and loaded.
- Finally, it starts up the language’s runtime and runs your code.
These steps only occur on the very first invocation of your function, or if your function hasn’t been invoked recently (the cache miss case in the diagram above). If your function has been invoked in the past few minutes, then the request will most likely result in a cache hit. In this case, there is no cold start, and the invocation is the same as it would be if your code was running on a long-running server.
Notice that empty slots are maintained in hosts to avoid the overhead of starting up a new host during the cold start of a customer’s Lambda function.
Why Virtual Machines?
As you can see from the above diagram, AWS Lambda functions are multi-tenant, meaning that your Lambda function is running on a host with other customers’ Lambda functions. Virtual machines are used instead of containers or processes to separate different running Lambda functions in order to provide guaranteed resource isolation.
Other Serverless Services
After AWS Lambda, other existing services added serverless features. Even some databases have serverless offerings. Other Cloud platforms also followed suit and added their own serverless offerings.
Use Case
Serverless services are ideal for inconsistent workloads — this is where pricing is extremely attractive. However, provisioned services are typically more cost-effective for large workloads that run consistently. It’s also important to note that AWS Lambda has a 15-minute timeout. For longer runtime, AWS Fargate (the serverless alternative to ECS) is the recommended serverless offering. This Nuvalence blog post provides an excellent break-even analysis of AWS Lambda vs Fargate. This Thundra blog post includes EC2 in its comparison.
Author
Sam Malayek works in Vancouver, using this space to fill in a few gaps. Opinions are his own.