In several previous posts I described how to setup your Spring Boot application and run it on AWS Elastic Beanstalk. Although this is a great step to go from a physical server to one in the cloud there is an even better step possible! Going serverless. That means no costs for any server and no maintenance or configuring of servers! That sounds good, right? AWS has made it quite easy to go serverless with the combination of AWS Lambda and AWS API Gateway. In this post I will describe what it took for my Spring Boot application that runs on Elastic BeanStalk to run the same functionality serverless.
The first step I took was getting rid of the Spring Boot dependencies since we don’t need that container anymore. I replaced them with the dependencies for the Spring Core and Spring Configuration. Also the plugins were changed to build a jar that can be used for the AWS Lambda.
The pom’s most important parts went from this:
... <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-security</artifactId> </dependency> ... ... <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> ...
To this:
... <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${spring.version}</version> </dependency> ... ... <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <configuration> <createDependencyReducedPom>false</createDependencyReducedPom> </configuration> <executions> <execution> <phase>package</phase> <goals> <goal>shade</goal> </goals> </execution> </executions> </plugin> ...
Next step is to modify the Java code so the RestController functionality is called by implementing the AWS Lambda interface:
public class LambdaFunctionHandler implements RequestHandler<InvoiceRequest, InvoiceResponse> { private static final Logger LOGGER = LoggerFactory.getLogger(EasyInvoiceController.class); private EasyInvoiceController easyInvoiceController; @Override public InvoiceResponse handleRequest(InvoiceRequest input, Context context) { easyInvoiceController = Application.getBean(EasyInvoiceController.class); InvoiceResponse result = null; try { result = easyInvoiceController.generate(input); } catch (ExecutionException e) { LOGGER.error(e); } catch (InterruptedException e) { LOGGER.error(e); } return result; } }
With this class (and some plain Spring configuration) the RestController functionality that was first called with the incoming HTTP request is now called by a Lambda request.
In my case I was also able to get rid of my Spring Security code since I didn’t need to secure the incoming request in the Lambda code as this will be done in the API Gateway.
Next step is to upload the Lambda functionality (the generated jar file in the target folder) and make sure it works by testing it. I made use of the S3 bucket upload facility and added some environment variables:
Last step is to call the Lambda from the API Gateway by defining the API. See the screenshot for an example:
I must say that this serverless architecture might not be working for all use cases but it should at least be considered when designing new applications/ (micro)services or when changes in the architecture are made anyway.
Another note is that it took me quite some effort to get the API Gateway working with the Lambda I created but I still think it is a great solution for certain cases.
Pingback: Java Web Weekly, Issue 154 | Baeldung
Pingback: Monthly notes 14 – Rule of Tech
Hi!
First of all, you do great job!
Do you have the example code uploaded in github?
Are you using Lambda Proxy Integration?
Thanks!