If anyone's migrated software that someone who has left the company installed on a random VM to a new data center you'll know the pain of not being able to do this hermetically.

To me the beauty of it is that one text file describes a build environment and you can pass it around quite easily to reproduce it.

You can also tag it, sort of like a url or git branch and pass that around.

So what happens is - someone needs to use your code, you can tell them how to install it on a system - but you also give them a docker file that is a working environment. Then, it's not your problem.

They can look at the dockerfile and see what has been installed -- and also very important -- what is NOT installed.

Another thing is that it helps with incremental development. You can build your environment via the dockerfile layer by layer and if a layer is broken or unnecessary, you can remove it without having to rebuild all the layers before that.

In comparison, I've also used LXC containers and setting those up is more like installing a VM because there doesn't seem to be a dockerfile equivalent.

That said, docker is confusing as the article alludes to, because there's a company trying to build a business model around it.

What I'm talking about is:

  apt-get install docker.io

They're also trying to control the namespace. For example, they don't let you have your own private registry, which is like a local dns server. It would break "the global namespace" and incidentally their business model.

Redhat is wise to them, and their version of docker has --add-registry. If I was an enterprise customer, I wouldn't want my containers going out to the internet to get up-to-date (sometimes inadvertently). It makes runtime docker containers more sketchy

Where as docker/runc and podman/crun became standards, similar to the way Android & Chrome OS took off. To the extent that they're contributing back to the ecosystem (they are), great I feel.

As of April 13, 2017 when that blog post went live, Podman did not yet exist. Dan Walsh had not yet made the initial commit that began Podman's life: https://github.com/containers/podman/commit/2b74391cd5281f6f...

So I think it's safe to say that Podman was not mentioned in the article because it did not exist when the article was written.

These days Podman is alive and well. I use it a lot more than Docker now. The fact that Podman can run/create Kubernetes Pods (without needing K8s) is a compelling feature for me.