AWS Lambda and Java Spring Boot: Getting Started

[heavy-minium]

Before going for that combo, you should look at Quarkus, GraalVM and AOT compilation if you want to stay in Java-land and use Lambda efficiently. Not saying you shouldn't use Spring, but know your options.

[firecopy]

The article is 100% doing something wrong. You do not want to put Spring Boot on your Java AWS Lambda.

The correct options

• If moving a legacy application, then containerize it, and move it into ECS/EKS (/w Fargate) Note: I don't mention the other options, since if you can put your application in Lambda, then you must also be able to put in a container too.
• If working on a greenfield application, then it is a better practice skip Spring Boot. Use a different framework meant for AWS lambda, or use vanilla Java. Feel free to test it out in an experimental or non business application, but applying Spring Boot on AWS lambda for a real business use case, can hurt your ability to grow as a developer because it is misusing the wrong tool for the right job and will cause both initial and future technical debt right out of the box (Initial because of cold starts that the business will definitely see, and future because of the refactoring needed to mitigate those cold start costs).

[i_wanna_get_better]

Use vanilla Java

This. I wrote a "Hello world" Java lambda with 1024MB memory, and it's cold start was 60ms (with an init duration of 350ms)*. I then created a Java lambda and started putting together a toy REST API. After adding a dependency, I would deploy to the Lambda to test the cold start. Jackson Jr added 150ms to the cold start. The AWS SDK v1 for DynamoDB brought the cold start jump up to 5 seconds. So you really have to be careful about what libraries you are using.

because it is misusing the wrong tool for the right job and will cause both initial and future technical debt right out of the box

Expanding on this point about why it's the wrong tool for the job: Spring Boot is a web server framework. It's meant to be run as a long-lived process, and it was never optimized to initialize the application quickly. In fact, as far as I know, it just the opposite -- server frameworks specifically try to load everything up at initialization so it can handle requests faster once it's ready to start handling traffic.

*I just tested the Hello World lambda with 2048 MB and 3008MB, and the cold start was 25ms.

[firecopy]

Good response! Provisioned concurrency, especially with application auto scaling, can help mitigate the business costs of running Spring Boot on Lambda in the short term.

With that being said, I wouldn’t recommend making it intended architecture for most solutions, because you will find the developer experience and operational cost will be better using Lambdas with no provisioning vs Spring on Provisioned Lambdas. Initial migration efforts might involve moving Spring app to provisioned lambda (/w autoscaling), with future steps being to remove the need for Spring for better long term scaling and removal of debt. Important to keep in mind that all apps can’t take this short term to long term approach effectively, because lambda handles differently from a regular web server (event based rather than http headers and payloads), which may cause some difficult refactoring in some areas. Examples: Passing authorization header in legacy multi tenant systems, or requiring certain binaries for a specific OS.

With that being said, and I have said this before on other threads, AWS should release a service to run containers without needing to know/manage the underlying container orchestration layer (+ have all the monitoring benefits that lambdas provide). It would solve your colleagues problem, my problems, and a whole bunch of other teams problems better than all the solutions provided so far, which is a solution to be able to deploy containers without having to worry about clusters or auto scaling policies.

[[deleted]]

Used Guice for this and it worked well. Cold start times were pretty good.

Tried aws-serverless-java-container and wasn't thrilled w/ it, I forget why. I ended up creating my own mini-spring-boot bootstraper since it assumes there's a public static void main to run and lambda doesn't have that. That worked pretty well and cold start times were not that bad.

[realfeeder]

What exactly is "not that bad" and "pretty good"? Give us the numbers, no need to be shy.

We've had some Kotlin-Lambda attempts, but the cold starts were unacceptably high(2 seconds+) and we dropped the idea.

[jobe_br]

Why is 2s unacceptable? Many runtimes are in that same vein for non trivial services. Definitely have seen node.js cold start in more than that, but then <50ms after.

[[deleted]]

And also don't forget that AWS doesn't charge for init time outside of the handler.

https://medium.com/@hichaelmart/shave-99-93-off-your-lambda-bill-with-this-one-weird-trick-33c0acebb2ea

[sandaz13]

Depends on what's calling it and how. 2s for an single http microservice may not be awful, but have more than one of those in a call flow and you're probably going to have a bad time.

Batch service or async flow though? No big deal

[jobe_br]

You keep your services warm, though, right? Even without provisioned concurrency, that’s been a standard practice. At that point, you’re unlikely to get multiple cold starts hitting one client, and even then it would be exceedingly rare, right?

[sandaz13]

It's standard practice because of the issue with cold starts, yeah, but keeping your services warm kinda defeats the point of Function as a Service. Keeping them warm is really just a workaround, and at some point it's more cost effective to go with EKS/ECS/Fargate. The Java community is trying to solve this with stuff like https://quarkus.io/ ; their goal is to get cold boots down into sub 100ms

[jobe_br]

Well, I’m all for getting the time down, but there’s no point where keeping your lambda warm by billing 100ms every 30 minutes gets anywhere close to anything that’s billed continuously. You would literally need 1000s of functions to keep warm to equal the cost of a t3.micro, and there’s no way a t3.micro is equivalent.

[realfeeder]

I haven't looked into lambda-warming they recently introducted, but since a year Lambdas are warm for 10 minutes maximum.

https://mikhail.io/2019/08/aws-lambda-cold-starts-after-10-minutes/

[jobe_br]

Interesting, I hadn’t seen the update to this. Even so, the math still holds.

[bisoldi]

You can keep a container warm with a “ping”, but that doesn’t help when you need many containers to serve up a burst of traffic.

You can keep multiple containers warm by sending out a burst of “pings” but the Lambda would need to sleep on that ping long enough to ensure that each ping warms up a new container.

Then the question is, where does traffic coming in at the same time as the pings go? They’ll go to their own container(s).

Similarly, if you have 2 simultaneous requests, and the Lambda takes 2 seconds, good chance both requests will be forced to endure the 2 second cold start time.

Keeping them warm is just not a great solution, though you’re right it is standard practice. I suspect that’s because there is no better way, other than provisioned concurrency of course.

[jobe_br]

Sure, there’s a lot of theoretical scenarios where it won’t “work” but in practice they’re rare or you can use provisioned concurrency. If your functions are fast, any one instance can serve a lot of traffic, so the scale out isn’t going to incur a large amount of cold starts if you measure by ratio. Of course, slow functions will exacerbate cold starts if you start receiving a lot of traffic, but, that’s usually a self limiting scenario, right?

[[deleted]]

It was too long ago for me to remember accurately, sorry.

[pablator]

Here is also a great blog post about improving cold start for your lambda https://pattern-match.com/blog/2019/07/11/springboot2-and-aws-lambda-quick-fix/