Bilel Khaled

Since October 09, 2020, Lambda’s new feature Lambda Extensions was preview-released.
The official information is below.

Introducing AWS Lambda Extensions – In preview
Building Extensions for AWS Lambda – In preview
aws-samples / aws-lambda-extensions –Github

I read these briefly, but my impression was, « I’m not sure what I’m happy about … ». I am sad because I have poor understanding.
However, when I read Lumigo’s blog, which provided the extension at the same time as the release as an official partner, I understood it well, so I would like to edit and convey what i’ve learned.

https://hatenablog-parts.com/embed?url=https://lumigo.io/blog/aws-lambda-extensions-what-are-they-and-why-do-they-matter/

Lumigo is a 3rd Party tool and vendor that helps you monitor and debug for serverless and microservices applications.
* Therefore, the following story is from the standpoint of a tool that provides monitoring functions such as Lumigo or its vendor. In addition to monitoring, Extensions can have security and governance functions, and the extensions of such vendors have already been published.

Monitoring tool when not serverless

First, consider monitoring an application that isn’t serverless, for example running on an EC2 instance. In these cases, you usually have a resident program called an agent or daemon on the server that collects various metrics and periodically sends the data to the external (off-server) monitoring tool endpoint. .. The data will then be visible in the monitoring tool.

This resident program is designed to be as light as possible on the server. If the monitoring tool becomes a performance bottleneck, it will be overwhelming. For example, sending data to a tool’s endpoint isn’t done every time you collect data, but several batches. Doing so will reduce the number of requests and reduce the load.

Also, the resident program is application-independent, so it does not have to be implemented in the same language as the application.

Not possible with Lambda

This approach is not possible with Lambda. This is because the resident program cannot be installed in the Lambda runtime environment. Only AWS, not the 3rd Party, was able to collect metrics via X-Ray and CloudWatch.

So the 3rd Party tool vendor had to take a different approach. Within the Lambda call, you can either have the metric data sent to your endpoint, or you can have CloudWatch Logs send the data and reference the contents of the CloudWatch Logs from your tools.

In the case of the previous company, it is necessary to prepare a library for each language. In the latter case, you will be charged extra for CloudWatch Logs. Often this is more expensive than Lambda itself.

Whichever method you choose, you cannot save the data and send it in bulk later, as you did with a resident program. This is because the execution environment may be destroyed before sending. It also increases the implementation cost of having developers add code. It also increases the execution time of the function.

With Lambda Extensions …

• Simply install Extensions as a Lambda Layer, and you can monitor (transmit metrics) with a 3rd Party tool like Lumigo. You don’t need to add any additional processing inside your Lambda function. There are no language restrictions.
  • * It may be necessary to set the environment variables of the function to set Extensions.
  • * If you have access to AWS resources with Extensions, you need to give that permission to the role that attaches to the function.
• You can save the data and send it in bulk later. Before the execution environment is destroyed, Extensions will be sent a SHUTDOWN event to allow it to do something for 2 seconds.
  • You will not be charged for this 2-second process during the preview period, but will be charged after GA.
• The impact on execution time can occur. Roughly speaking, I try not to extend the processing time as much as possible by parallel execution, but the phase does not end until all the processing including Extensions is completed, so it seems that there is a possibility that it will have an effect.
  • First, when creating a Lambda execution environment, so-called Cold Start , the extension initialization starts before the runtime initialization, and the initialization of each extension is executed in parallel and also in parallel with the runtime initialization. However, the end of the init phase for the entire function is when the runtime and all Extensions are ready. In other words, if it takes a long time to prepare Extensions, the Cold Start time may increase.
  • In addition, the processing at the time of function execution is the processing of each extension and the processing of the function, all executed in parallel. However, the end of this execution phase is the same as the previous init phase, when the processing of the function and all Extensions is completed. Therefore, if you have an extension with a long processing time, the execution time will increase and the billing will also increase.
  • PostRuntimeExtensionsDurationThere are more metrics called CloudWatch metrics . A metric that records extra execution time by Extensions. Use this to find out if Extensions are having a negative impact on performance.

* The following figure is easy to understand regarding the relationship between processing parallelism and each phase.( AWS Lambda Extensions: What are they and why do they matter | Reprinted from Lumigo )

Summary

Did you understand the benefits of Extensions? In short, it’s a « new feature that makes it easy to use your favorite tools with Lambda » written in the AWS release blog, i hope it’s more clear now for you x)