What all has changed in the AWS Lambda in the past one year…
Serverless computing, in general, is now considered a rapid way to build modern cloud-native applications. Like every major design systems in the past decades, the Serverless has also gone through a number of changes and improvements over time.
It has been only 6 years since AWS launched the Lambda service and this year, by far, has seen some major improvements. Lambda alone can do so little, but the thriving eco-system of services (integrations and event-emitters) is helping the overall Serverless Computing on AWS to cater to a vast variety of use cases.
This was one of the quotes from Andy Jassy at the recently concluded re:Invent 2020 keynote.
Forrest Brazeal wrote a great post about recent Lambda additions and the trend-shift in Serverless computing for better Serverless computing.
Let’s look at some of the most important features and their impact going forward.
Lambda functions are a bit slow (cold) to start
Yes, because this is designed to be a serverless, pay-per-use, auto-scaling, and low-operations system. That means heavy-lifting is done by AWS. To work on the other features, Lambda service had to compromise on this one.
A year back, Lambda service announced the availability of the Provisioned Concurrency. This means we can define how many Lambda functions will be kept in memory to avoid spending extra time on serving new requests.
This does not break any promise of serverless computing. We still don’t need to worry about servers and we can configure the concurrency when required.
Lambda functions have limited storage
Lambda service had default ephemeral storage of only 512Mb and need to rely on S3 for all the persistence.
In mid-2020, AWS announced the integration of EFS with Lambda to allow low-latency, high throughput file processing. This feature helps Lambda function to process large files seamlessly.
The biggest difference in using EFS vs S3. EFS is a file system, so the code can use the file system APIs instead of using the S3 APIs.
Lambda functions are not exactly PAY-PER-USE
Lambda service calculates the billing on a 100ms time block. So for example, if a function takes 55ms to complete the processing, the Lambda service will still charge for a 100ms time block. That’s like paying nearly double the cost, and at a large-scale, this is a big amount.
With a recent announcement, Lambda service now charges in a 1ms block. That means for a 55ms function execution, we will be paying around 55ms only.
Lambda service can only run functions
Yes, and this is a good thing. Lambda was originally designed to build micro-functions that can run independently to execute code based on the attached events.
With the latest announcement, now Lambda service can run Functions (as in code in zip file) or Containers (as in containers).
Depending on your understanding of Serverless computing, this is a very interesting addition. This allows builders to leverage Serverless computing without making major changes in their existing software packages, provided they are containerized.
If your goal is to design better cloud-native software, you will find this feature a very good option for future design.
Lambda functions have very limited memory
Lambda functions can only configure up to 3GB of RAM. There is no way to configure the CPU, and it is allocated proportionally based on the amount of RAM configured.
With the latest announcement, Lambda functions can now allocate up to 10 GB of RAM.
With CPU proportional to the amount of RAM, now you can perform more complex tasks in a function and may still be fine with the 15 minutes maximum time duration.
Lambda functions provide limited control and insights
Yes, it does, because the promise is to get away from the low-level details and instead focus on building features.
But that is changing, with steep adoptions, builders need more insights and control so that they can design better serverless functions without adding more code.
With the latest announcement, Lambda Extensions can help extract and augment the internal details. Extensions help integrating external tools like a “sidecar” without making any changes in the function code.
With these many changes, we hope to see newer and better use cases in the future with Lambda and Serverless services.
Some good sessions on Serverless from the re:Invent 2020
Adrian Cockcroft’s architecture trends and topics for 2021
https://virtual.awsevents.com/media/t/1_pskgtbiq/188376503
How LEGO.com accelerates innovation with serverless
https://virtual.awsevents.com/media/t/1_b9a1su9s/188376503
Building revolutionary applications the serverless way
This is not about Serverless is better and other systems need to match up. This is about building and running better and efficient software for tomorrow.
