The future of serverless with AWS Lambda Extensions
AWS has recently announced the preview of Lambda Extensions, a new way to integrate tools with Lamba functions. In this post, we take a quick look at what Lambda Extensions are and what possibilities they open for us in the future.
October 22 2020 · 4 min read
As time goes by, more developers start using Lambdas in numerous ways that fit their unique use cases. As a result, developers' input to the AWS Lambda team grows, allowing them to make the service more adapted to various needs.
The latest feature for the Lambda service, although in preview, is Lambda Extensions. Lambda extensions enable developers and 3rd party service providers to better integrate with the Lambda service and provide complementary tools that help with instrumentation, security, logging and much more.
How they work
Lambda Extensions run alongside the function itself, either internally—as part of the process—or externally as another process. Lambda Extensions have access to the new Lambda Extensions API and lifecycle events, allowing implementors to provide various services at specific points of the function execution.
To use an extension, you attach it as a Lambda Layer or use one of the already available partner extensions. When the Lambda function cold-starts, the extensions are registered and initialized. Each Lambda Extension must signal the Extensions API that it's ready, and once all extensions are ready, the function handler is executed.
In contrast to today, you no longer have to inject code into your function handler to use 3rd party tools. Instead, the extensions are run independently, can communicate with the function, and if need to, the function can choose to communicate with the extension.
What are they for
The primary use-cases are for instrumentation of security, configuration, tracing, and logging tools. These can now live alongside the function.
The Lambda Extensions enable us to add 3rd party tools in a more straightforward way than today. It doesn't require us to inject and run 3rd party code inside the Lambda handler function or to redirect the Lambda handler to a Lambda Layer and back. Instead, when added, the extensions load and shutdown by themselves.
In addition to the "standard" use-cases, we see a vast range of other solutions that Lambda Extensions can bring.
Since the Lambda Extension can run in a separate process in the same Lambda container, the main
function process can communicate with the Lambda Extension over the
localhost address or by placing
files in the
/tmp directory—I disregard other ways of communication, on purpose, for simplicity.
With the above in mind, we can implement the sidecar pattern in an external Lambda Extension process and attach it to all our functions in a stack as a Lambda Layer. Such a sidecar extension can provide services like configuration, communication proxy and more.
Keep in mind that Lambda Extensions need to finish loading and signal the Extensions API that they're ready before the function can be invoked. This essentially means that long startup times for extensions translate to longer cold starts of the Lambda function.
Lambda Extensions is a significant step forward for serverless technologies and the 3rd party solutions that help make their adaption easier. We at Altostra are excited about the possibilities and the opportunities this new feature brings and will post more on the topic in the future as we release new and exciting features.
We avoid going too deep into the technical details, as the information is already available online. If you wish to dive deeper into Lambda Extensions, we have gathered a few sources for you: