Spring Boot 3.4 application on AWS Lambda- Part 5 Docker Container Image with AWS Serverless Java Container

Introduction

In the article How to develop and deploy Lambda function with Java (21) runtime we already introduced how to develop the application using Lambda Docker Container Image runtime.

Not let's convert our sample application introduced in the article Spring Boot 3.4 application on AWS Lambda- Part 1 AWS Serverless Java Container and deploy it using Docker Container Image as a AWS Lambda runtime instead of Corretto Java 21 runtime.

How to write AWS Lambda function with Docker Container Image as a runtime with AWS Serverless Java Container and Spring Boot 3.4

The steps to change the existing application with Java Corretto 21 runtime to be deployed as Docker Container Image runtime introduced in the article How to develop and deploy Lambda function with Java (21) runtime remain completely the same.

We need a Dockerfile and some changes in the template.yaml.

The sample simple application also remains the same, see the architecture below:

But I updated the application introduced in the article Spring Boot 3.4 application on AWS Lambda- Part 1 AWS Serverless Java Container to use Docker Container Image as a AWS Lambda runtime and published the source code in the spring-boot-3.4-with-aws-serverless-java-container-as-lambda-docker-image repository. Of course, since then other minor or major updates of the libraries have been released, but I assume that no other changes besides the version updates in the pom.xml are required to make the applications work.

Following needs to be installed in order to build and deploy the sample application:

• Java 21, for example Amazon Corretto 21
• Apache Maven
• AWS CLI
• AWS SAM
• Docker

In order to build the application, execute mvn clean package.

In order to create and publish the Docker image of this application into the Amazon ECR repository follow the steps described in the article How to develop and deploy Lambda function with Java (21) runtime.

In order to build the application, execute sam deploy -g --image-repository {$ECR_REPOSITORY}.

In order to create the product with id equal to 1, execute

curl -m PUT -d '{ "id": 1, "name": "Print 10x13", "price": 0.15 }‘ -H "X-API-Key: a6ZbcDefQW12BN56WEZ34" https://{$API_GATEWAY_URL}/prod/products

In order to retrieve the product with id equal to 1, execute

curl -H "X-API-Key: a6ZbcDefQW12BN56WEZ34" https://{$API_GATEWAY_URL}/prod/products/1

Measuring cold and warm start time of the AWS Lambda function with Docker Container Image as a runtime with AWS Serverless Java Container and Spring Boot 3.4

All techniques to measure AWS Lambda performance introduced in the Measuring cold and warm starts of Lambda function with Java 21 runtime are also still valid. Lambda SnapStart can't be enabled for the Docker Container Images as of now.

The results of the experiment below were as well based on reproducing more than 100 cold and approximately 100.000 warm starts with Lambda function GetProductByIdFunction with 1024 MB memory setting for the duration of 1 hour. For it I used the load test tool hey, but you can use whatever tool you want, like Serverless-artillery or Postman.

I additionally measured Lambda performance using 2 different Java compilation options : tiered compilation, which is the default compilation option in Java 21 and compilation option XX:TieredStopAtLevel=1 for which you need to additionally set JAVA_TOOL_OPTIONS environment variable of the Lambda function to "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" in the template.yaml as showed below:

Globals:
  Function:
    Runtime: java21
    ...
    Environment:
      Variables:
        JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"
      ....

So let's provide the results of the measurement. Abbreviation c stays for the cold start and w is for the warm start.

Cold (c) and warm (w) start time in ms:

Scenario Number	c p50	c p75	c p90	c p99	c p99.9	c max	w p50	w p75	w p90	w p99	w p99.9	w max
tiered compilation	4903.73	4982.78	5103.76	5506.55	5556.31	5556.64	6.40	7.21	8.39	18.92	45.82	1211.4
-XX:+TieredCompilation -XX:TieredStopAtLevel=1 compilation	4893.94	4992.75	5093.56	5561.87	5578.57	5583.38	6.30	7.05	8.26	18.55	44.42	1221.14

Conclusion

In this article, we updated our sample application introduced in the article Spring Boot 3.4 application on AWS Lambda- Part 1 AWS Serverless Java Container and deployed it using Docker Container Image as a AWS Lambda runtime. We also measured Lambda performance with the different Java compilation options. The results for both cold and warm start times were very close for both compilation option choices.

It's worth investigating which not required dependencies can be excluded in the pom.xml to reduce the cold start times, see some thoughts about it already described in the article Spring Boot 3.4 application on AWS Lambda- Part 1 AWS Serverless Java Container.

In next part of this series, we'll update the sample application introduced in the article Spring Boot 3.4 application on AWS Lambda- Part 3 Spring Cloud Function AWS to be deployed as a GraalVM Native Image using Lambda Custom runtime.

If you have read my article(s) and liked its content, please support me by following me on my GitHub account and giving my repos a star.