For per ms billing to matter, you probably want to limit your language choices.

Wow, I haven’t read yet, but I’m very curious if this affects the size limits on the lambdas. I’ve tried to build lambdas for a small Python use case, but by the time I imported pandas and a few other libraries I exceeded the 250 mb limit and migrated to ECS/Fargate, but the startup times were much longer.

This should be at the top of this thread! This is huge and fixes my #1 gripe with Lambda -- that managing dependencies is "non-standard" and you can't use tools like Docker. Plus, the 250MB limit is brutal.

This is really, really exciting!

Oh that's quite big news if you run an app that has to be deployed cross cloud.

We use very little serverless at the moment, because the three clouds we need to deploy to have infuriating differences between their execution and deployment environments. Eg. How they manage dependancies, the runtimes, how you describe and deploy each function.

Compared at least to K8 where the containers you build run just fine wherever you put them.

The thing you put inside the container still has to speak Lambda's API, but yes, pretty cool.

It sounds like you are assuming that faster code means you need to sacrifice something which has negative consequences. If you know upfront you need faster code you may choose a statically compiled language and I don't see it as a sacrifice.

Speed has always mattered, though I agree we are light-years away from optimization levels once considered standard. OTOH, so are we WRT complexity of applications.

Amazon is not going to change software development per se, but at least at some of their customers' sites calculations will be done how many hours can be allocated for a n% reduction in runtime. So, if you live in an amazon-universe, this is a real "game changer". Bystanders may chuckle ;)

Speed has never not mattered; whoever told you that hand waved over a ton of nuance and did you a disservice. The reality is that for a lot of work loads an increase in speed is not worth the tradeoff (key word) of increased maintenance burden.

All else being equal, faster services are cheaper to run. Faster services can service more requests per compute/memory resource, which means you don't have to buy as many servers/containers/whatever. This is particularly important if you're being billed by the ms, which is the context we're talking about here.