I'm sure they don't need me to tell them they'll be inundated with demand...
I believe the performance boost will not be meaningful and the only important factor is cost per GB*s, given that most Lambda workloads are IO bound or simple event handlers that barely take 1s to run anyway.
Nevertheless this is exciting stuff, specially given that NodeJS might be lambda's most popular runtime and thus we might only be a toggle flip away from a 20% discount.
But NodeJS is second!
It's certainly easier to figure out what's going on in a smaller container though! I've had to debug some nasty situation with layers in Python Lambdas before and it's not fun...
Also, for performance undoubtedly Golang is by far the optimal AWS Lambda runtime.
Consequently, I see NodeJS in every single application ever as pretty much the default runtime, with a bit of Java (renowned for being by far the worst AWS Lambda runtime) primarily to leverage code reuse and of course Golang.
If anyone reading this picked Python for your AWS Lambda runtime, do you mind telling why? I would love to hear your rationale as I'm sure I'm missing an important take.
I assume the answer's roughly the same for anyone - it's odd to me that you're talking about 'ideal Lambda runtime', I'd be surprised if many people care. You're going to choose your language by however you were going to choose your language otherwise, and then run it on Lambda. And python is more popular than node in general.
If you really wanted every last gram of performance, you'd be running an optimised compiled binary anyway, not using any of the provided runtimes.
That's a great point. I admit I followed the same exact rationale motivated by code reusie to go with Java runtimes in projects that consisted mainly of peeling responsibilities out of legacy Java services, and Java is notoriously by far the worst performing Lambda runtime.
Granted, this was before lambda's pricing granularity was updated from 100ms down to 1ms. Nowadays, a JDK invocation easily costs 50x the cost of a NodeJS lambda invocation, not to mention the concurrency consequences.
> I assume the answer's roughly the same for anyone - it's odd to me that you're talking about 'ideal Lambda runtime', I'd be surprised if many people care.
Sure, there are other constrains and requirements, but in the context of AWS Lambdas, and taking into account the way they are priced and the fact that they run on a single vCPU and that they are mainly IO-bound, NodeJS is very hard to beat. If you're starting out a project, you're not totally ignorant regarding AWS Lambda's pricing, and you are free to pick whatever runtime you want, it is very hard to justify any rational choice other than NodeJS or, alternatively, Golang.
> If you really wanted every last gram of performance, you'd be running an optimised compiled binary anyway
Hence Golang.
Meanwhile, NodeJS gets you about 90% where Golang takes you without taking a single step outside of the happy path.
> Hence Golang.
Sure. Or rust, C++, C, .. whatever.
Libraries and code reuse. Python has libraries for everything, and we have written a whole host of Python libraries of our own. We know how to do what we want to do in Python and many of our lambda functions started their life in either python CLI scripts or as part of a Flask app. "Copy pasting" working code into AWS Lambda is much quicker and easier than rewriting in Node or Go.
If we're 'moving' to anything it would be moving some functions to C(++)
At @dayjob we’ve got plenty of Lambda workloads where we’re butting up against the maximum execution time limit; while that's mostly a “not optimally architected for Lambda” problem, an extra ~20% capacity before that becomes a constraint rather than a concern would be welcome.
My take is that a 50% discount in price/performance and a 20% discount in price per execution unit that's only a toggle flip away is something that everyone loves and is eager to jump onboard.
The only exception is when your workload stubbornly stays within free tier limits, which in that case you have no compelling reason to do the work.
There's a pull request that went up about 40 minutes prior to my comment.
So it looks like it's coming, soon.