Sometimes buzzwords make sense, in the right context. This was the right context. Assuming you use containers, you're likely to not log into them and keep them

Sometimes buzzwords make sense, in the right context. This was the right context. Assuming you use containers, you're likely to not log into them and keep them up to date and secure by running apt-get upgrade. The most common workflow is indeed: build your software in your CI system, in the last step create a container with your software and its dependencies. Then update your deployment with a new version of the whole image. A container image is for all intents and purposes the new "static binary". Yes, technically you can look inside it, yes technically you can (and you do) use dynamic linking inside the container itself. But as long as the workflow is the one depicted above, the environment no longer has the requirements that led to the design of dynamic linking. It's possible to have alternative workflows for building containers: you could fiddle with layers and swap an updated base OS under a layer containing your compiled application. I don't how common is that, but I'm sure somebody will want/have to do it. It all boils down to whether developers still maintain control over the full deployment pipeline as containers penetrate the enterprises (i.e. whether re retain the "shift to the left", another buzzword for you). Containers are not just a technical solution, they are the embodiment of the desire of developers to free themselves from the tyranny of filing tickets and waiting days to deploy their apps. But that leaves the security departments in enterprises understandably worried as most of those developers are focused on shipping features and often neglecting (or ignoring) security concerns around things that live one layer below the application they write.