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

121–130 of 180 posts

Re: Why would anyone choose Docker over fat binaries?

#121

Post by manigandham »

merb wrote: post #120
manigandham wrote: post #119

I really don't see how this is an argument - Docker containers are like zip-files for deploying these very same app binaries, whether fat or lean - except containers are very easy to define, are able to run anything inside, can easily be uploaded/downloaded over HTTP, and abstract away all the systemd/init/background service nonsense into a clean API. That alone is worth it, and it's what makes Kubernetes so powerful…

> and abstract away all the systemd/init/background service nonsense into a clean API. hm?! what?! > That alone is worth it, and it's what makes Kubernetes so powerful, by taking that basic runtime abstraction and further lifting it up beyond the VMs/nodes themselves. how is a damn yaml file over 40 lines simpler than a 7 lines systemd? (i didn't even count the setup of kubernetes, since you prolly never did) also an…

It that really the argument? Because "40 lines" are more than "7 lines"?

Both are simple to write, but K8S services for me are much easier to define. They're also far more configurable and usable across machines. Write it once and you're done, and add in the ability to use service-oriented storage and networking policies and it provides far greater power and flexibility than ever before.

My point is that there is no point comparing these things since a docker container can hold all the fat binaries you want inside... so it's not either/or at all.

Re: Why would anyone choose Docker over fat binaries?

#122

Post by pfranz »

noahwilde wrote: post #80
Silhouette wrote: post #76

Earlier quoted context omitted.

If a company has existing in-house systems that are working well, why should they care about "valuable experience that would be usable outside the company"? Unless you think it's their responsibility to train people so those people can then leave and take the benefit of that training to some other, possibly competing, business?

Companies don't have a moral responsibility to do that, but it's a smart retention strategy. If good devs feel like they're learning useless non transferable skills, they'll be more likely to leave for the sake of their career. If they feel like the business is investing in them, they'll be more likely to stay.

Resume Driven Development can be just as bad for everyone involved.

Re: Why would anyone choose Docker over fat binaries?

#123

Post by manigandham »

dijit wrote: post #29
pjmlp wrote: post #22

Earlier quoted context omitted.

chroot only protects the file system, sandboxes are much more than that.

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

Sure, but at some point it goes from niche to mainstream and that matters. Plus the docker registry model is a big deal that we didn't have before. Having a universally accessible way to just download a container and run it is arguably the secret to success this time around.

Re: Why would anyone choose Docker over fat binaries?

#124

Post by manigandham »

danmaz74 wrote: post #88
Lazare wrote: post #38

I admit: I find the argument for "fat binaries"[1] over containers compelling. There's just one problem... ...let's say I'm working on an existing code base that has been built in the old-style scripting paradigm using a scripting language like Ruby, PHP, or (god help us) node.js. Let's say we're well aware of the shortcomings are are looking for a migration path to move into the future. I can just about see how we c…

> built in the old-style scripting paradigm using a scripting language like Ruby, PHP, or (god help us) node.js I feel like I didn't get the memo... is the new-style we're all supposed to use microservices?

No. Containers give you value regardless of the language or amount of "services" you use.

Having an easy way to wrap and deploy, publish/download over HTTP, and use a simple API to run and keep running is new and valuable, hence all the popularity.

Re: Why would anyone choose Docker over fat binaries?

#126

Post by mwcampbell »

> It seems sad that so much effort should be made to keep old technologies going,

I strongly disagree with this part. To make progress as a technological civilization, without constantly wasting time reinventing things, we need to keep old technologies working. So, if Docker keeps that Rails app from 2007 running, that's great. And maybe we should still develop new apps in Rails, Django, PHP, and the like. It's good to use mature platforms and tools, even if they're not fashionable.

That word "fashionable" brings me to something that really rubs me the wrong way about this piece, and our field in general. Can we stop being so fashion-driven? It's tempting to conflate technology with pop culture, to assume that anything developed during the reign of grunge music, for example, must not be good now. But good technology isn't like popular music; something that was a good idea and well executed in 1993 is probably still good today.

Besides all that, as others have explained, platforms like Kubernetes have other advantages over just dropping a self-contained binary on a Linux server.

Re: Why would anyone choose Docker over fat binaries?

#127

Post by seabrookmx »

pacala wrote: post #79
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…

Extra scenarios: * Not all our libraries are available in the same ecosystem. We need to mix JVM with C++ with a sprinkle of Python [via jep]. * We run a lot of small variations over the same code base. We'd rather not wait to re-deploy 99% of a fat binary for each run.

Another good point is that Docker's layered filesystem allows for caching that greatly benefits the use case you're describing.

We have an old .net app we pushed to servers via zip files, and the sheer size of the zip ended up being a burden after many deployments. Docker's caching and "docker prune" make things a lot easier.

Re: Why would anyone choose Docker over fat binaries?

#128

Post by SOLAR_FIELDS »

supermatt wrote: post #6

Its INCREDIBLY naive of the author to be slamming docker usage because they think everything should be a fat binary - and what are they even calling a fat binary? How do I make my node app a fat binary? Would they be happier if we wrapped up docker + images in an executable and called that a fat binary? Also, I think the author is simply confused about what docker itself is, complaining about its lack of network orch…

This is not intending to diminish your point because I agree with you, but you can in fact make a fat binary with Node: https://github.com/nexe/nexe

I have used it when I cannot guarantee to have Node.js installed on location I am deploying app to. It works pretty well, but the C compilation of all the Node bindings took quite awhile when I was using it (about 2 years ago). I think a build of a small project took around 10 minutes at the time.

Re: Why would anyone choose Docker over fat binaries?

#129

Post by Spivak »

lightedman wrote: post #86
snuxoll wrote: post #64

Earlier quoted context omitted.

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

"I can guarantee it pretty well on my RHEL and CentOS systems" Slashdot tried that with CentOS and failed miserably. I have my doubts regarding your guarantee.

Link? I want to see what they actually tried.

Re: Why would anyone choose Docker over fat binaries?

#130

Post by Spivak »

pmoriarty wrote: post #104
2trill2spill wrote: post #100

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.

> Second best is VMs. Containers are a distant third.

I will grant you that containers are harder to isolate since it's same problem as isolating individual processes. But there isn't really a meaningful difference between a kernel exploit and a hypervisor exploit.

Post reply on HN