Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why would anyone choose Docker over fat binaries?

smashcompany.com

Post reply on HN
Print view View original

61–70 of 180 posts

Re: Why would anyone choose Docker over fat binaries?

#61

Post by notyourday »

friend-monoid wrote: post #48

* 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…

> * 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" layer. You still need to write the code to correctly handle it. Throwing K8S at it is putting lipstick on a pig. It is still a pig.

> * We have a whole lot of HTTP services in a range of languages. Managing them all with fat binaries would be a chore - the author would have to give me a way to set port and listen address, and I have to keep track of every way to set a port. With a net namespace and clever iptables routing, docker can do that for me.

Nope, you wrote a set of rules and as long as everyone adheres to those rules things kind of work ( in a clever way ). Of course if you had the same kind of rules written and followed in any other method, you would arrive at the exactly the same place. In fact, you probably would arrive at a better place because you would stop thinking that your application works because of some clever namespace and iptables thing.

> * sometimes, I have to deploy and insecure app. Usually, it's a badly configured memcache or similar. With net namespaces, I can make sure only a certain server has access to that service, and that the service cannot ruin my host server.

You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container.

> load balancing. Luckily, I don't have to deal with extreme network loads which would require hand-made solutions, but just pushing up that number a little to do ad-hoc load balance makes things a lot easier

The time to build a template and instrumentation for your haproxy/nginx/varnish layer is when you don't have enough traffic and enough complexities.

Re: Why would anyone choose Docker over fat binaries?

#62

Post by pjmlp »

colejohnson66 wrote: post #42
pjmlp wrote: post #21

Earlier quoted context omitted.

I guess so. Usually everone that somehow thinks Go compilation model is inovative, never has used anything beyond scripting languages and possibily C in addition to them. MS-DOS used to call them "XCopy installs", NeXTSTEP had its fat binaries with directory structure, Windows and MacOS(pre OS X) can store all dependencies inside the .exe file and so on. In any case, fat binaries don't cover the dependencies with fil…

> MacOS(pre OS X) can store all dependencies inside the .exe file and so on. On macOS / OS X, it’s actually a .app folder

Yes, but on Mac OS pre-OS X you could use resource forks for that.

Re: Why would anyone choose Docker over fat binaries?

#64

Post by snuxoll »

notyourday wrote: post #61
friend-monoid wrote: post #48

* 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…

> * 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.

I can guarantee it pretty well on my RHEL and CentOS systems, SELinux prevents containers from accessing things they shouldn’t just like it prevents Apache from dumping /etc/passwd.

Re: Why would anyone choose Docker over fat binaries?

#65

Post by pjmlp »

Lazare wrote: post #39
snarfy wrote: post #36

"A fat binary (or multiarchitecture binary) is a computer executable program which has been expanded (or "fattened") with code native to multiple instruction sets which can consequently be run on multiple processor types. This results in a file larger than a normal one-architecture binary file, thus the name." [1] What does having an x86 and x64 binary in the same executable have to do with dependency management? You…

I assume you knew this and were just making a point, but: OP is using the term "fat binary" in a totally different and incompatible way to how your wikipedia link defines it. > every compiled language has that. It is not exclusive to Go. I don't think the article claimed it was. But it is a lot harder with C than Golang for various technical reasons, and it's much, much harder still with most scripting languages.

It is super easy to do static binaries with C, I was already doing it in 1992, the first time I actually used C on my life.

It only hard if one happens to mix glibc, a specific implementation of the ANSI C standard library, with any implementation of it.

Re: Why would anyone choose Docker over fat binaries?

#67

Post by betaby »

jamespo wrote: post #32
dijit wrote: post #29

Earlier quoted context omitted.

BSD Jails and Solaris Zones then. Everything old is new again, this time with an orchestration layer.

Some would say the orchestration layer is quite important

And people were running cfengine inside FreeBSD jails and Linux vservers in early 2000 already.

Re: Why would anyone choose Docker over fat binaries?

#68

Post by eeZah7Ux »

dsr_ wrote: post #54
friend-monoid wrote: post #48

* 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.

Spot on. Both fat binaries and containers very often translate in: "Nobody here cares about security. We deploy opaque blobs that will be unmaintained."

Re: Why would anyone choose Docker over fat binaries?

#69

Post by falcolas »

jchw wrote: 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 exist.

> [...] scheduling [...]

Ansible, Chef, Saltstack, etc.

> I have to manually manage each container port

You have 65,000 ports available to you. I don't think this is as big an issue as made out to be - people are lazy, which is the only reason there are so many conflicts over 8000 and 8443.

> Kubernetes, with enough hackery to work around bugs

Given the context that I am someone currently attempting that hackery - this shit just kinda works, some of the time. And when it fails, it's a morass of conflicting documentation, and responses of "well, you're not using the default distribution for your environment" (no shit, it's no longer supported) and "works on my single node minikube cluster". Give me ansible/chef/saltstack any day of the week. Hell, I'll even take cfengine at this point.

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

Re: Why would anyone choose Docker over fat binaries?

#70

Post by anilakar »

notyourday wrote: post #61
friend-monoid wrote: post #48

* 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…

> * 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…

I think that the main point was that docker skills are transferable, i.e. you can expect a new hire to be productive in less time. Too many companies still have in-house build/deploy systems that are probably great for their purpose but don't offer valuable experience that would be usable outside that company.
Post reply on HN