serverless-java-container VS AWSLambdaJavaSnapStart

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.

I've heard that server providers like Amazon Web Services offer dynamic scaling serverless architecture https://aws.amazon.com/serverless/

AWS Docs - Official documentation for all things AWS serverless

Although not what I would consider 'core' cloud services, the orchestration and communication services are key to event driven development and robust application design. If you are structuring your application to take advantage of event flow, these are tools you are going to want to be familiar with, and will be instrumental in your success by saving you time, money, complexity, and management overhead. This about wraps up what I want to cover with serverless cloud services, though there is so much out there to explore. Tune in tomorrow as we start to put all of this together with best practices.*

If you're new to the application development world, API stands for Application Programming Interface, an interface that offers a 'service' of sorts for applications to consume. Google Maps, for instance, has a public API that you or I could use if we're building an application to locate all of the restaurants in our town. They surface this, and many, many other data points via documented endpoints, and we can use things like API keys to access this data. If you're a developer, chances are you will build an API at some point in your career, if not several, and you will definitely work with them. As a key building block in application development, AWS provides a few API solutions.

As an AWS Hero and a Principal Software engineer at a large Fortune 100 enterprise, I have been focused solely on serverless technologies and enablement over the last 3 years. I have spoken quite extensively about our serverless journey, what serverless means in a large enterprise, and how to be successful in a corporate setting. Everything I have learned has been through experience, on-the-job. The serverless definition I resonate with most states that serverless is event-driven, your resources scale up and down without you needing to manage them, and follows an "only pay for what you use" model. Let's break this down a bit further:

In the part 2 of the series we introduced AWS Serverless Java Container and in the part 3 we demonstrated how to write AWS Lambda with AWS Serverless Java Container using Java 21 and Spring Boot 3.2. In this article of the series, we'll measure the cold and warm start time including enabling SnapStart on the Lambda function but also applying various priming techniques like priming the DynamoDB invocation and priming the whole web request. We'll use Spring Boot 3.2 sample application for our measurements, and for all Lambda functions use JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" and give them all 1024 MB memory.

In our experiment we'll re-use the application introduced in part 8 for this. Here is the code for the sample application. 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 GetProductByIdWithPureJava17Lambda can be used with and without SnapStart and the second one GetProductByIdWithPureJava17LambdaAndPriming uses SnapStart and DynamoDB request invocation priming. We'll measure cold starts using the following memory settings in MBs : 256, 512, 768, 1024, 1536 and 2048.

For the sake of explanation we'll use our Spring Boot 3.2 sample application and use Java 21 runtime for our Lambda functions.

Medium Size application with DynamoDB persistence. We'll re-use the application introduced in part 8 for this. 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 can be used with and without SnapStart and the second one uses SnapStart and DynamoDB request invocation priming. There are bunch of dependencies declared in pom.xml like aws-lambda-java-core, aws-lambda-java-events, slf4j-simple, crac, dynamodb and url-connection-client. The deployment size of such application is 15 MB.

and others will be a part of a separate project and therefore also used without the usage of the all other AWS Serverless Java Container APIs only for purpose of mocking the API Gateway Request/Response (i.e. for Priming). I've already used them for Priming requests for Quarkus and Micronaut frameworks. Dependency to the AWS Serverless Java Container was included by default for the Micronaut on AWS Lambda SnapStart Priming example and needed to be added explicitly for the Quarkus on AWS Lambda SnapStart Priming example only to implement web request priming. We'll make use of these abstractions in one of our subsequent articles when we'll discuss cold and warm start time improvements for Spring Boot 3 application on AWS Lambda using AWS Lambda SnapStart in conjunction with priming techniques.

Using the asynchronous DynamoDBClient means that we'll be using the asynchronous programming model, so the invocation of getItem will return CompletableFuture and this is the code to retrieve the item itself (for the complete code see)

Let's figure out how to configure the HTTP Client. There are 2 places to do it : pom.xml and DynamoProductDao

In our experiment we'll re-use the application introduced in part 9 for this. 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 GetProductByIdWithPureJava21Lambda can be used with and without SnapStart and the second one GetProductByIdWithPureJava21LambdaAndPriming uses SnapStart and DynamoDB request invocation priming. We'll measure cold and warm starts using the following memory settings in MBs : 256, 512, 768, 1024, 1536 and 2048. I also put the cold starts measured in the part 12 into the tables to see both cold and warm starts in one place. The results of the experiment below were based on reproducing more than 100 cold and approximately 100.000 warm starts for the duration of our experiment which ran for approximately 1 hour. Here is the code for the sample application. For it (and experiments from my previous article) I used the load test tool hey, but you can use whatever tool you want, like Serverless-artillery or Postman. Abbreviation c is for the cold start and w is for the warm start.

Small HelloWorld-style application which consists of Lambda receiving the APIGateway request with product id and basically prints this id out. There is no persistence layer involved. The application is that simple, that there is now priming to be applied. There are only several dependencies declared in pom.xml like aws-lambda-java-core and slf4j-simple. The deployment artifact size of such application is 137 KB only.

For measurement purposes I created/copied the sample application and configured Lambda functions to use Java 17 runtime for Lambda and 1024 MB memory .