Live data from Hacker News

Why would anyone choose Docker over fat binaries?

smashcompany.com

101–110 of 180 posts

Re: Why would anyone choose Docker over fat binaries?

#101
post #52

Well, the author is definitely missing the point. 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's the difference? * With containers I can put a Python app right alongside my binary but with total isolation. No need to fu…

> but other than that, what's the difference? The need to configure, manage, monitor and maintain a whole extra set of programs. Also, systemd can just as easily start the binary in a cgroup, eliminating most of the following concerns. > The isolation is broken Worth noting that behind the scenes, Linux is using the same in-memory versions of libc, even for containers. That isolation you speak of already doesn't exis…

> Kubernetes was built for Google's use case, in Google's environment. Attempting to use it with other restrictions and requirements is a nightmare.

That's a tremendous overstatement. The first part is just wrong, as was pointed out in earlier responses. The second part just smacks of your having been soured by a poor experience. We started with kubernetes in production at very small scale, just a few supporting services to begin with since there was a lot to learn. Currently we're running five or six of our core production apps on the GKE version of the platform and the experience has been very positive.

Re: Why would anyone choose Docker over fat binaries?

#102
post #52

Well, the author is definitely missing the point. 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's the difference? * With containers I can put a Python app right alongside my binary but with total isolation. No need to fu…

> schedulers like Kubernetes can also use your CPU and RAM limits to schedule containers. As far as I know, there's no equivalent tooling for doing this with fat binaries.

I much prefer the Docker and Kubernetes world, but you could actually do this (scheduling and bin-packing fat binaries) with Nomad's exec driver:

https://www.nomadproject.io/docs/drivers/exec.html

Re: Why would anyone choose Docker over fat binaries?

#104

Earlier quoted context omitted.

> * If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write. Of course you do, you just moved the logic into the "orchestration" and "management" lay…

> You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container. Don't group all container implementations into one category. You could certainly use FreeBSD Jails and Illumos Zones for isolating apps.

Those solutions still allow the host and all the other containers to be compromised through a kernel exploit, though, can't they?

The most secure isolation is provided with physical separation. Second best is VMs. Containers are a distant third.

Re: Why would anyone choose Docker over fat binaries?

#105
I use Docker mainly in situations where the required dependencies (Java, GTK, etc) conflict with the versions on my system. In this case, the service running in the container is required, unless I want to upgrade the operating system, and I'm on CentOS 7 for a reason (stability and security).

Re: Why would anyone choose Docker over fat binaries?

#106
It's sad when people have a myopic view of the use of technology.

Docker is a way to distribute an executable environment, very similar to distributing an application platform.

A "fat binary" is literally just a single monolithic executable application. It isn't an environment. It isn't a platform. It's ridgid and difficult to work with and, as the name implies, BIG.

There are many cases where a "fat binary" simply can not, does not, will not work. It's a very limiting way to distribute and run an application. Suggesting that a "fat binary" is somehow superior to a Docker environment is not only missing the forest for the trees, it's forgetting that there's a forest. The binary is just one tree.

Docker isn't more complex than what we had before. People just haven't been trained on the different patterns of deploying environments and platforms, in addition to applications. We used to build Docker-esque application platforms all the frigging time before Linux containers even existed, and they still exist without Docker. If you have a problem with Docker, that's fine, but it doesn't mean you have to box yourself into a totally different restrictive model.

People in this industry need to wake up and admit there are no simple solutions to complex problems. Don't believe the hype.

Re: Why would anyone choose Docker over fat binaries?

#107
post #54

* If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write. * We have a whole lot of HTTP services in a range of languages. Managing them all with fat…

This argument appears to be: when the application is crap, putting it in a container lets me deal with it without getting my hands dirty. This is probably true, but it isn't good.

This seems to be the main point of the article to me. If your language's toolchain makes it easy to make sufficiently* self-contained 'fat binaries' (like Go or Java), then Docker doesn't add much. If it doesn't, like Ruby or Python, then Docker is very useful.

* 'sufficiently' is doing a lot of work here. Go binaries might still need libc; Java tars-of-jars (or fat jars, if you're confused) still need a JVM, which needs a handful of shared libraries. But those things are relatively stable, generally backward-compatible, and one single big thing (libc or JVM), so it's fairly easy to manage having multiple versions installed anyway. More than zero work? Yes. Less work than managing a Kubernetes or Docker installation? Also yes.

Re: Why would anyone choose Docker over fat binaries?

#108

Earlier quoted context omitted.

> You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container. Don't group all container implementations into one category. You could certainly use FreeBSD Jails and Illumos Zones for isolating apps.

Those solutions still allow the host and all the other containers to be compromised through a kernel exploit, though, can't they? The most secure isolation is provided with physical separation. Second best is VMs. Containers are a distant third.

> Those solutions still allow the host and all the other containers to be compromised through a kernel exploit, though, can't they?

If I keep my boxes up to date I only need to worry about zero day kernel exploits. So if someone comes along and uses a zero day kernel exploit to escape my FreeBSD jail then they were going to get on the box anyway, because any attacker using a zero day is highly skilled and highly targeted.

> The most secure isolation is provided with physical separation. Second best is VMs. Containers are a distant third.

While I agree that physical isolation is the safest, I don't think it's so cut and dry between containers and VMs. Virtual machines have significantly more attack surface than either Jails or Zones, think of all the emulated devices.

Re: Why would anyone choose Docker over fat binaries?

#109
post #82

This article failed to mention the most important thing: An actual advantage of fat binaries. The closest he comes is saying that he feels the docker way is "old"... As compared with fat binaries, which is how desktop applications have been shipped for decades. Hell, size, the only clear would-be advantage, is only mentioned in a throaway sentence. > Yes, the network can be very powerful, but trying to use it for eve…

"I have a feeling he doesn't know the distinction between kubernetes and docker. They don't actually compete with each other, I don't even understand the comparison. Kubernetes uses docker."

Docker (the company) is itself responsible for this confusion. They're redefined what "docker" means a whole bunch of times.

Post reply on HN