AWS Lambda supports nearly any programming language by enabling developers to run serverless functions with either supported or custom runtimes. Once a runtime is deprecated, however, AWS will set dates for when you can no longer create or update functions using that runtime. You will then need to decide what course of action to take to ensure your Lambda functions continue running as expected.
In this post, we’ll weigh the various options you can pursue when a critical Lambda runtime is deprecated by AWS. We’ll also show you how Datadog can identify which Lambda functions are running outdated runtimes so that you can determine how to update them.
When AWS discontinues support for a specific runtime you rely on to build out your serverless application, you have three main options to keep your application running:
When AWS deprecated the go1.x runtime in December 2023, we at Datadog observed that customers chose to package function code as container images more often than expected. Because AWS was pushing customers to use custom runtimes, we expected to see custom runtimes account for most of the growth. Instead, we saw that there was a larger increase in container image packaged runtimes.
Packaging function code as container images enables developers to avoid being tied to specific AWS-supported runtimes and allows easy portability across different environments and workloads. For example, if a customer has workloads across a multi-cloud environment, packaging Lambda code in a container image can simplify deployments by standardizing the release process across all platforms using containers.
This approach also involves less operational overhead compared to migrating to a custom runtime you maintain yourself or rewriting all of your code in a supported language. While refactoring and rewriting your code would add significant delays to your project timeline, maintaining a custom runtime requires continuously updating and developing security patches and bug fixes and ensuring compatibility with Lambda’s execution environment.
Though packaging functions as container images has its benefits, there are still tradeoffs to consider. For instance, while container images are convenient for bundling dependencies, they are more complex to inspect and maintain for vulnerabilities compared to a zip file package. If a security vulnerability like Log4j is discovered, you would need to scan the entire container image to identify and update the vulnerable dependency. With a zip file package or custom runtime, however, it’s simpler to inspect specific files.
Before you can make any decisions around deprecated Lambda functions, you first need to identify which functions are using deprecated runtimes. If you manage many Lambda functions, especially across different environments, it can be difficult to track which ones are using deprecated runtimes. You may also have older, forgotten functions that could still be running outdated runtime versions.
Datadog helps you overcome this challenge by detecting which functions are using deprecated runtimes and marking them with warnings within the Lambda view of the Serverless page.
You can click on a warning to get more contextual information such as the name of the deprecated runtime and the function’s associated service. And once you’ve identified deprecated Lambda functions, you can see whether an updated runtime is available, decide to use a custom runtime, or package your function as a container image.
In this post, we looked at how organizations may approach handling Lambda functions running deprecated runtimes and discussed how, among our customers, most choose to package Lambda functions as container images rather than rewrite their code or maintain a custom runtime. We also looked at how you can use Datadog to warn you when Lambda functions are deprecated. To learn more about Datadog’s serverless warnings, check out our documentation.
If you don’t already have a Datadog account, you can sign up for a 14-day free trial to get started.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。