Why would anyone choose Docker over fat binaries?
Well, the author is definitely missing the point.<p>In scenario 1, I put a Go binary onto a server and make a systemd unit file. In scenario 2, I put a Go binary in a docker container and launch it on a Kubernetes cluster. Scenario 2 is wasting a ton more cycles and RAM, but other than that, what&#x27;s the difference?<p>* With containers I can put a Python app right alongside my binary but with total isolation. No need to futz around with chroots or making a static build of Python and embedding my scripts into it.<p>* What if I need libc, for example to link to SQLite or something? Suddenly my Go binary requires libc. The isolation is broken!<p>* Systemd can use Cgroups to limit RAM or CPU, but schedulers like Kubernetes can also use your CPU and RAM limits to schedule containers. As far as I know, there&#x27;s no equivalent tooling for doing this with fat binaries.<p>* Without Docker, I have to manually manage each container port. Can&#x27;t run two apps with pprof servers on the same box. With Docker, I only have to care about public ports, and can port-forward into debug ports manually, and with Kubernetes I never have to care about port conflicts.<p>* Kubernetes, with enough hackery to work around bugs, can actually do seamless deployments where it checks your internal health endpoint or command before making the container available. As far as I know, the alternative to this is writing crappy scripts that try to do this without declarative logic to back it.<p>You could go on and on. It doesn&#x27;t have to be Docker. Could use rkt as well, or really any container engine. The point is that the container engine + scheduler pattern is immensely useful, and if it weren&#x27;t, Google would already be on the next thing.<p>If you&#x27;re just setting up a single server with a single program, fine. Drop a binary on it and call it a day. But when you want to implement CI&#x2F;CD and schedule applications across multiple servers and do load balancing and so on, you might feel like you&#x27;re reinventing the wheel a bit considering those problems were all already solved by Kubernetes.