AWS Lambda Cold Start Times

Yeah I tried that, it doesn't work. Ultimately the provisioning algorithm is a black box.

I wonder ho w much time was spent requiring all of aws-sdk. The v3 sdk is modular and should be quicker to load. Bundlers like rebuild save space and reduce parsing time.

The main downside of Lambda, in particular for user facing applications is that the incentives of the cloud provider and you are completely opposed. You (the developer) want a bunch of warm lambdas ready to serve user requests and the cloud provider is looking to minimize costs by keeping the number of running lambdas as low as possible. It's the incentive model that fundamentally makes Lambda a poor choice for these types of applications.

Other downsides include the fact that Lambdas have fixed memory sizes. If you have units of work that vary in amount of memory required you're basically stuck paying the costs of the largest units of work unless you can implement some sort of routing logic somewhere else. My company ran into this issue using lambdas to process some data where the 99% of requests were fine running in 256mb but a few required more. There was so way to know ahead of time how much memory the computation would require ahead of time. We ended up finding a way to deal with it but in the short term we had to bump the lambda memory limits.

That doesn't even get into the problems with testing.

In my experience, Lambdas are best used as glue between AWS components, message processors and cron style tasks.

no, it's the direct translation of the benchmark of this post

cold start should be a thing of the past, hence the "failed to reinvent themselves to stay relevant"

you need to speak to the hardware directly, not to the VM or the embedded compiler

with ARM and ultimately RISC-V coming, that's gonna be even more true

I think if you get to this point with lambda you're probably overthinking it. I think language runtime choice is important because some choices do have a cost, but likewise, choosing lambda is a tradeoff -- you don't have to manage servers, but some of the startup and runtime operations will be hidden to you. If you're okay with the possible additional latency and don't want to manage servers, it's fine. If you do and want to eke performance, it might not be.

Larger lambdas mean a higher likelihood of concurrent access, which will result in cold starts when there is contention. Your cold starts will be slower with more code (It's not clear how much the size of your image affects start time, but it does have SOME impact).

It's best to just not worry about these kinds of optimizations -- that's what lambda is for. If you *want* to worry about optimizing, the best optimization is running a server that is actively listening.

Scope your lambda codebase in a way that makes sense. It's fine if your lambda takes multiple event types or does routing, but you're making the test surface more complex. Just like subnets, VPCs and everything else in AWS, you can scope them pretty much however you want and there's no hard fast rule saying "put more code in one" or "put less code in one", but by there are patterns that make sense and generally lots of individual transactions are easier to track and manage unless you have an explicit use case that requires scoping it to one lambda, in which case do that.

There are a few cases where I've advocated for bigger lambdas vs smaller ones:

* grapqhl (there still isn't a very good graphql router and data aggregator, so just handling the whole /graphql route makes the most sense)

* Limited concurrency lambdas. If you have a downstream that can only handle 10 concurrent transactions but you have multiple lambda interactions that hit that service, it might be better to at least bundle all of the downstream interactions into one lambda to limit the concurrency on it.