serverless-java-container VS AWSLambdaJavaSnapStart

AWS’s serverless compute offerings—Lambda, Fargate, and App Runner—provide developers with powerful tools to build scalable, efficient applications without infrastructure management. Lambda excels in event-driven, short-lived tasks, Fargate supports complex containerized workloads, and App Runner simplifies web app deployment. By understanding their features, use cases, and limitations, developers can select the best service for their needs, accelerating development and reducing costs. For further exploration, visit the AWS Serverless page (AWS Serverless) or Serverless Land for tutorials and resources.

Quick Start Guide: Spring Boot 3

Base Project I referred to the official AWS GitHub repository for serverless Java projects

In 2024’s cloud-native world of microservices, containers, and serverless functions, the right log format gives you clarity. It’s not just data. It’s a roadmap to faster solutions.

The key dependency to make it work and translate between Spring Boot 3 (web annotation) model and AWS Lambda is the dependency to the artifact aws-serverless-java-container-springboot3 defined in the pom.xml. It's based on Serverless Java Container which natively supports API Gateway's proxy integration models for requests and responses, and we can create and inject custom models for methods that use custom mappings.

The AWS Serverless Java Container makes it easier to run Java applications written with frameworks such as Spring, Spring Boot 2 and 3, or JAX-RS/Jersey in Lambda. We have already seen that Micronaut framework also uses AWS Serverless Java Container.

Serverless has grown to mean many things and can even mean something different depending on whose cloud you are paying for. But for our team and for the purpose of this article, serverless is a way of building and running applications without having to manage the underlying infrastructure on AWS.

Read the Quick Start here: https://github.com/awslabs/aws-serverless-java-container/wiki/Quick-start---Spring-Boot3 Thanks to Mark Sailes for all of his help with this tuto

Having knowledge about microservices architectures, serverless, and related concepts is highly beneficial. This includes understanding chaos testing techniques with AWS Fault Injection Simulator.

To ensure reliability, Lambda manages multiple copies of each snapshot. Lambda automatically patches snapshots and their copies with the latest runtime and security updates. When we call the function version for the first time and as the calls increase, Lambda continues new execution environments from the cached snapshot instead of initialising them from scratch, which improves startup latency. More information can be found in the article Reducing Java cold starts on AWS Lambda functions with SnapStart. I have published the whole series about Lambda SnapStart for Java applications.

If you don't like to use APIGatewayProxyRequestEvent SnapStart priming, please also remove the dependency to aws-lambda-java-serialization in the pom.xml as it contributes additional 4.5 MB to the Lambda deployment artifact size.

You can find the source code in my pure-lambda-21 repo. I only updated dependencies in the pom.xml to use its recent versions.

You've probably already read my article series about AWS Lambda SnaptStart and know that I like to explore SnapStart priming techniques. In the next part of this article series, I'll explain how these flame graphs gave me some ideas about how to prime even more and therefore to reduce the cold starts of the Lambda function. Stay tuned !

The Z Garbage Collector. There are 2 different ZGC algorithms: default and the newer one- generational. You can set it explicitly in AWS SAM template by adding -XX:+UseZGC or -XX:+UseZGC -XX:+ZGenerational to the JAVA_TOOL_OPTIONS environment variable.

AWS Lambda SnapStart which significantly reduces cold start times is currently only available for Java Corretto managed runtimes (11, 17 and 21) and not for Docker container images. You can explore jlink tool to assemble and optimize a set of modules and their dependencies into a smaller custom runtime image and Class data sharing (CDS) though which helps reduce the startup time for Java programming language applications, in particular smaller applications, as well as reduce footprint. The advantage of using the Docker Image as deployment artifact for Java is the ability to use recent Java runtime like Java 23 which will be released in September.

In pom.xml you see all dependencies with the scope provided (by the Lambda layer attached).

In our experiment we'll use the sample application. There are basically 2 Lambda functions defined in the AWS SAM template which both respond to the API Gateway requests and retrieve product by id received from the API Gateway from DynamoDB. One Lambda function GetProductByIdWithPureJava21LambdaWithCommonLayer can be used with and without SnapStart and the second one GetProductByIdWithPureJava21LambdaAndPrimingWithCommonLayer uses SnapStart and DynamoDB request invocation priming.

For the sake of exploration we'll use the sample application for creating the Lambda layer with Java 21 runtime packaging the following dependencies into the layer :

In our experiment we'll re-use the application introduced in part 8 for this and rewrite it to use asynchronous HTTP client. You can the find application code here. There are basically 2 Lambda functions which both respond to the API Gateway requests and retrieve product by id received from the API Gateway from DynamoDB. One Lambda function GetProductByIdWithPureJava17AsyncLambda can be used with and without SnapStart and the second one GetProductByIdWithPureJava17AsyncLambdaAndPriming uses SnapStart and DynamoDB request invocation priming. We give both Lambda functions 1024 MB memory.