As a steady 20+ year Linux user who doesn't directly code for a living (I do teach a few intro type classes) this resonates a lot. I never quite understood why "Docker" ended up being such a big deal in the way it was/is.
Now, I don't doubt or disagree that it is a potentially extremely useful technology, buut it seemed (and still seems) crazy and nonsensical to me that it is enough to power a whole "business model," of the size it apparently got. Somewhat similar to "curl" or "ssh," or even the Linux kernel -- it could sit under a lot of stuff and be very important, but would work much better as a free and/or open source without limitations kind of thing.
Docker might not seem very impactful if you use Linux on your computer with a handful of apps. If you're shipping software from 20 different teams, half of them extremely drowned in tech debt, and all not being very respectful of each other's resources containerization is a great way to get isolation & system configuration locked down in an extremely low effort way while also giving your engineers an extremely ergonomic development environment that directly mirrors production.
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
But docker the company is forcing two versions - a community edition and an enterprise edition. I tried it on macos and it had tons of telemetry too.
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
TBH, the Linux container spectrum includes LXC vs xen vs KVM vs openvz vs linux-vserver vs UML vs firejail vs nsjail vs appimage vs flatpack vs snap vs custom things like Steam's Linux Runtime.
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.
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.
> 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.
