Necessary change. Now writing stuff in fast languages suddenly matter in cost, changing the landscape of when these solutions might become viable for a chase.
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.
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.
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.
Thats me. We've got some fun things we do behind the scenes to keep Lambda container image support snappy. SO yes, up to 10gb artifacts with container image support.
I don’t know how this is related to my comment. In my case we used a slow language (although Python’s poor performance and its large bundle sizes are only indirectly related at best) and we had to spend a lot more by moving to ECS/Fargate. If we were using Go, our bundle sizes would’ve been 30x smaller (I checked) and would’ve fit in a lambda easily. Not only would it have fit easily, it would have made a lot of progress before the Python version even finished importing its dependencies. And in top of all of that, it would have out-performed the Python version by a good order of magnitude. If anything, my anecdote supports the idea that Amazon wants you to use fast languages, especially now that they offer per-ms pricing for lambdas.
I've been here for a while resisting the temptation to write a sarcastic comment. Speed has been the opposite of what matters for decades. Every change is always trading speed for something else. And suddenly some offer by Amazon is going to change that? Seems unlikely.
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.
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 ;)
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.
