Honest question: How is Lambda runtime version rot acceptable to an "awesome" top exec like Jeff Barr? Is someone else demanding he siphon resources away from maintaining key services? What data-driven metric says maintaining service quality shouldn't be continually prioritized?
I'm open to any explanation, but the logical conclusion I see if the lack of prioritization only really makes sense if internally, Lambda is considered a gimmicky toy. Where is the "Customer Obsession" mantra here?
A large portion of the most valuable work in software is of the boring, unsexy variety needed to keep key pillars working smoothly.
If I was an AWS exec I’d say managed runtimes are legacy, with the introduction of containers move to containers for new deploys.
I’ve been critical of Lambda in the past and critical when people use Kubernetes/Docker because it’s Kubernetes/Docker. The container support in Lambda has been a game changer, it’s one of them now they’ve done it you think why didn’t they think of that earlier, it’s a great fit.
If they do that they remove one of the key benefits of AWS Lambda and that's that customers don't have to care about the underlying operating system and just have to care about their function code.
And I'm sure if they'd would look at the numbers of how many AWS Lambda Functions use zip packages vs. Docker images they'd see that something like >90% use zip packages. Based on that they'd be insane to deprecate the use of zip packages.
Deprecating zip packages doesn’t mean zip packages no longer work, it means pretty much what they’ve done, ignored the managed runtimes with the view if the current runtime doesn’t do what you want, make your own with exactly what you need using tools you are likely already using with no vendor lock-in.
For things like Python most people don’t care about the underlying operating system from the projects in multiple orgs I’ve worked in. They go to Dockerhub, type Python, pick the image with the highest downloads and run pip install inside it. If you use Go, Rust, anything that creates a static executable you use “FROM scratch” with the only thing inside the container being the executable.
Those who do care about the underlying image are likely large orgs with a set of already blessed base images or people using things like Nix to build containers.
From a large org perspective and developer experience getting a “registry” for free because packaging as a standards compliant OCI image means instead of effectively creating your own registry on top of s3, you get a far more robust one with tagging, asset hashes, layering etc out the box. I never had a issue with zip archives but containers removes a bunch of roll your own boilerplate registry.
"Earns trust"
For the Amazon leadership principles.
(From an Amazon cdo engineer looking over at aws, nothing official of course)
Developers gain trust in AWS lambda by having it support the current runtimes, and keeping the old ones running for a long time. Lambda will always run the functions you want it to.
For some tension:
When I've taken free beers to chat with the lambda folks, it seems like they have a linearly growing oe burden for each new runtime version they support, and at least 4 or 5 years ago, I couldn't see a path towards avoiding that