> don't routine security updates mean you're constantly rebuilding and redeploying these images? In my experience, no. Dockerfiles tend to obfuscate deeper de

> don't routine security updates mean you're constantly rebuilding and redeploying these images? In my experience, no. Dockerfiles tend to obfuscate deeper dependencies. Either there's stale dependencies or uncontrolled versioning. In both cases you're running mystery meat in production. > And if so, how is that more efficient than just using Puppet / Chef / Ansible and a 'real' server? The fundamental DNA of configuration managers is to take a closed world - a server - as given and try to make it into the world as desired. But this assumes you can come up with a safe, terminating and not-too-long plan for doing so. Very frequently that is not the case. What gets done in such cases? The server gets backed up, wiped and rebuilt from a clean state. And that's more or less what you get from a container-centric substrate over a server-centric substrate. Just as I don't care about how the JVM allocates or collects my objects, I don't care about how a container orchestrator builds my processes. The idea predates containers, but many ideas predate their economical realisation. I am most familiar with BOSH, which does this at a whole-VM-centric level (and which, like Kubernetes, was inspired by Borg). Or the 12 Factor App, which focused on this idea from a devops perspective. But I would be unsurprised to find carvings from the 4th Dynasty outlining a similar idea.