I would not use Spring, or Java for that matter, for lambdas, speaking from experience.

"Lambda containers" is a bit of a misnomer, as you can have multiple instances of a function run on the same container, it's just that initial startup time once the container shuts down that is slow (which can be somewhat avoided by a "warming" function set to trigger on a cron).

I would definitely go with containers if your intention is to use Spring. ECS containers can autoscale just the same as lambdas.

There's some work being done to package Java code to run more efficiently in serverless computing environments, but IIRC, it's not there yet.

Thanks! I wasn't planning it, but can't hurt to ask.

When I looked the Lambda API looked uncomplicated to implement (I saw an example somewhere) and it felt like you could just write a few controllers and gain the ability to run a subset of functionality in Lambda, especially if your app could be kept warm.

(to your cron comment, I thought that the reserved capacity would mean the container would be forcibly kept warm?)

Provisioned concurrency is nice, but can get pricey, especially in an autoscaling scenario. It moves you from a pay-per-usage situation to hourly fee + usage model. I would wait until your requirements show you absolutely need it. For most use cases, you will either have enough traffic to keep the lambda warm, or can incur the cost of the cold start. Warming functions did the trick for us. If you think about it provisioned concurrency is paying for managed warmers.

Spring is a one thing, Java is really another. One can use Java without reflection, and then the cold starts are really reduced. Additionally, there's a GraalVm which is optimized VM which should be even faster. On top of that, if the reflection is not used, these days one can compile Java to the native image, which has none of these problems.

When you say fast though, you really are talking in comparison to other methods of using Java on Lambda. But compared to using something like Go, they are all slow.

Each container handles requests serially. This doesn’t preclude you from spawning multiple threads in Lambda to do background work though.

Serially, but up to ten requests in a single batch

> By default, Lambda polls up to 10 messages in your queue at once and sends that batch to your function.

From https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html