I would like a solution that allows to manage json objects, calls to SOAP services and access to the DB via Spring data on a set of lambda services.
But on the net I read that lambda functions should be very simple.
Maybe Spring cloud is the solution?
Regards
In my opinion Spring Boot isn't a good technology choice for AWS Lambda but it's possible. The best way to start using it is to checkout the different wrappers and helpers in aws-serverless-java-container. There is also a good blog post about Spring Cloud Functions on AWS Lambda if that's interesting to you.
The internet tells you that Lambda functions should be simple because then they're easier to scale. If you create another monolith using Spring Boot on top of AWS Lambda, then this is not what AWS Lambda should be used for.
Below I'm listing advantages and disadvantages of using Spring Boot in AWS Lambda. There are probably more but these are the first ones that came to my mind.
Advantages
- You can setup an API Gateway with proxy integration to AWS Lambda and then handle all the REST endpoints like you're used to with Spring Boot.
- You don't have to manage your instances because AWS Lambda is doing that for you.
- As soon as one Lambda function instance has started a Spring Boot container, this function will respond in a consistent way in terms of performance as expected from Java (at least that's my experience with Java Lambda functions).
Disadvantages
- More complexity because you need to map an API Gateway event to an HTTP event that Spring Boot can handle. That's what the wrappers mentioned above already do for you.
- A longer cold start time for your Lambda functions because Spring Boot is too slow to startup quickly like it's expected from Lambda functions. This means, you'll have spikes in your response times when a new Lambda function instance is started. If this is unacceptable, then don't choose Spring Boot with AWS Lambda.
- You'll have multiple Spring Boot containers running without much control because AWS Lambda spins up instances if they are needed. You can control the max and min number of instances, but that's it.
- Making SQL queries from AWS Lambda can be a pain due to the uncontrollable number of instances. You might run out of connections quite quickly if a spike hits your Lambda functions because it spins up more and more instances.
Having said that, I have used Java Lambda functions in the past and it is great to run them in the background doing some data processing. However, I'm not convinced that they are a good choice for "customer facing" endpoints like a REST API (except if you keep a minimum of Lambda instances running but then you can question if AWS Lambda is the right choice for you).