If you're sensitive to a 25% performance improvement, why not switch languages and get a 1000% performance improvement?

An easily tested compatible upgrade that gets a free performance boost… vs lots of engineering effort to rewrite… yeah that’s just not going to fly with management. Who are probably looking at the 25% performance boost as a 20% cost reduction not a 20% speed increase

It is possible[1]. You are better off this way than the AWS "native" way.

1. https://dev.l1x.be/posts/2023/02/28/using-python-3.11-with-a...

The only problem with that is that Docker lambdas boot slower than lambdas with the built in runtime (not ridiculously slow, but could be 2x or something). God help you anyway if you’re trying to do something latency sensitive on Lambda, but if you are then you probably don’t want to add more time for a docker pull.

I used to believe the same thing, I've began thinking it might now be false yet often repeated. AWS claims that:

> Lambda also optimizes the image and caches it close to where the functions runs so cold start times are the same as for .zip archives.[0]

This[1] article shows almost no discernable difference in .NET cold start times between containerised and regular lambdas.

It's easy to imagine developers pushing up bloated images, slowing startup down and blaming docker/AWS for it.

[0] https://aws.amazon.com/blogs/compute/working-with-lambda-lay...

[1] https://www.kloia.com/blog/aws-lambda-container-image-.net-b...

The situation does keep changing - AWS does optimize things.

I'm not so sure it's a black/white true/false. Depends on what goes in the docker image. It's something like for larger deployments docker is faster but for small deployments it's the other way.

We've actually observed the opposite at our company. Moving from a Python 3.8 built-in to Docker based changed our response times from about 40ms to 30ms on average.