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.
Originally published on Altostra.
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.
The possibilities
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.
Looking forward
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.
Learn more
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:
