>Debian packages are compatible with the Debian release they are from.

That won't save you if an application requires newer tooling or libraries than whatever is in Debian stable. Once that happens the application needs to bundle its dependencies. But that is precisely why people use containers.

You say container, but if you're at AWS, for example, and you're using any API of theirs, either the original deprecated EC2 API, or the Docker API, or the Kubernetes API... its all a real honest to god VM underneath, provided by Firecracker.

In other words, the technology I have used non-stop since it was mainlined in 2008 is the technology all of you use today. I can deploy a VM, you can deploy a VM, the difference is the API we use to do it, but they're all VMs.

And yes, my VMs are not required to be Debian Stable, and I can deploy any version as needed. That is why we have VMs, so we do not need to dedicate entire machines to a single application with unusual dependencies. Something big companies like Amazon and Google and Microsoft realized is the true wisdom that sysadmins like me have always known: even the damned kernel is a dep that should be tracked, and sometimes this does matter, and the only way you can deploy kernels on a per-application basis is with VMs.

Something container jockeys will never understand: containers that are offered through the OCI facility in the kernel has multiple discrete userlands, but one kernel. You do not have a hypervisor with its own kernel.

Docker, real namebrand Docker, is an OCI consumer. Using something that implements a compatible API is not Docker, but merely a compatibility shim.