The typical deployment scenario for a Spring Boot application in AWS involves running the Java application on an EC2 instance 24 hours a day. Of course, the application could be deployed in AWS ECS as a Docker container, but it still runs continuously on an EC2 instance. In each case, the EC2 instances need to be monitored and you pay for compute capacity used by that EC2 instance. More Additional Info At Spring Boot Online Training

AWS Lambda provides low cost compute with zero maintenance. Lambda runs your code on demand, without provisioned and managed servers. Lambda automatically runs and scales your code. You are charged for every 100ms your code executes and the number of times your code is triggered. If the code isn’t running, you pay nothing.

Lambda has clear cost and maintenance benefits. But what does it take to run the standard Spring Boot application as a Lambda? How does it work? What are the drawbacks? These are the questions that will be answered in this blog through a tangible example.

Lambdas Are Triggered By Events

Lambdas have many use cases. They can be triggered by events on S3 buckets, SNS, Kinesis Streams and DynamoDB tables. In addition, AWS API Gateway can be used to trigger Lambda code.

Today, we’ll discuss running a Spring Boot application as a Lambda and accessing the APIs via an API Gateway. The API Gateway will give a nice demonstration of accessing our Spring Boot code via a REST API.

For good measure, we’ll use Cloud formation scripts to make this setup reproducible and version controlled. Think infrastructure as code.

Let’s Get Started

The repository provides a basic Spring Boot application with a single REST API that we’ll use for testing. The project README.md provides detailed instructions on running the application or you can simply use your favorite IDE.

Let’s clone the repository and start the application:

git clone https://github.com/gemerick/spring-boot-lambda.git
cd spring-boot-lambda
mvn spring-boot:run

Conversion

The Lambda branch of the repository contains the completed code that enables running the application as a Lambda.

git checkout lambda
Let’s discuss the key parts.

Dependency

AWS Labs provides the AWS Serverless Java Container. We must add this dependency to the Maven pom.xml.

<dependency>
  <groupId>com.amazonaws.serverless</groupId>
  <artifactId>aws-serverless-java-container-spring</artifactId>
  <version>[0.1,)</version>
</dependency>

There are also two build profiles defined. See the profiles section of the pom.xml. The default is now to build for Lamda, while a command line option on MVN will build a standard Spring Boot application running Tomcat.

mvn package -Dboot

Handler and Configuration

Create the LambdaHandler class in the same package as the application. This code is the same as that is detailed by the AWS Serverless Java container quick start. The only addition is to enable the lambda Spring Boot profile.

handler.activateSpringProfiles("lambda");
Create a standard Spring Boot configuration class Config. We are disabling beans used for HTTP handling and optimizing for Lambda execution. @EnableWebMvc is required for Lambda deployment. The @Profile annotation makes these beans only load when the Lambda profile is enabled. Thus, the code can still run as a Spring Boot application outside of Lambda.

@EnableWebMvc
@Profile("lambda")

Deployment with SAM

AWS CloudFormation provides a common language for describing and provisioning all the infrastructure resources in your cloud environment.
AWS SAM is a model used to define serverless applications on AWS. SAM is based on Cloudformation and provides a simplified syntax. Using SAM greatly simplifies the code to create serverless applications. A sam.yaml template is defined for this project.

The deployment steps will require AWS CLI to be installed and configured. Follow these steps to deploy the Lambda:

• Clean and rebuild the code as a shaded jar, not as a Spring Boot jar.
mvn clean package
• Create an S3 bucket to hold the application code. This bucket name must be unique across S3, so adjust for your use in the next two steps.
aws s3 mb s3://spring-boot-lambda-0403
• Copy the jar file to the S3 bucket and update the information into a SAM template

aws cloudformation package --template-file sam.yaml --output-template-file target/output-sam.yaml --s3-bucket spring-boot-lambda-0403

Conclusion

Spring Boot makes it easy to create stand-alone, production-grade Spring-based applications that you can “just run.”

We’ve shown that these applications can quickly be updated to run in AWS Lambda, which provides low cost, zero maintenance compute that automatically scales. At the same time, we can build and test the applications prior to deployment, like we are accustomed to.
When the application is ready, it can easily be deployed with CloudFormation and AWS SAM can do a lot of the heavy lifting. Cold start times must also be taken into account when choosing Lambda. To get in-depth knowledge, enroll for live free demo on Spring Boot Training

CLEANUP
It’s always a good habit to clean up unused resources in AWS. Unlike other resources, Lambdas won’t cost unless you use them, but let’s keep our good habits intact:

aws cloudformation delete-stack --stack-name spring-boot-lambda