[BFLpL0QNek]

They’ve provided custom runtimes which removes the need completely for managed runtimes giving you whatever version you like. They also did it in a way with Docker that’s simple and powerful.

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.

[Dunedan]

> If I was an AWS exec I’d say managed runtimes are legacy, with the introduction of containers move to containers for new deploys.

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.

[BFLpL0QNek]

Of course 90% will use zip packages, container support is relatively new in the lifetime of Lambda.

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.