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

71–80 of 180 posts

Re: Why would anyone choose Docker over fat binaries?

#71

Post by hennsen »

awirth wrote: post #57
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…

But here's the thing: You can dockerise a PHP app. How am I meant to make a fat binary out of one? For years Facebook (reportedly) did this with hPHPc. Not a very good idea these days, but it's certainly within the realm of possibilities for large companies.

Yes, and we all know every shop in town has resources comparable to Facebook‘s...

Re: Why would anyone choose Docker over fat binaries?

#72

Post by cobookman »

Fat binaries solve only for dependency. Containers also deal with isolating environment variables and filesystem.

Each program doesn't have to worry about what else is running on the machine. It also helps you deal with the differences between say Ubuntu and redhat. Not all nix os have the same filesystem directory setup.

Re: Why would anyone choose Docker over fat binaries?

#73

Post by notyourday »

anilakar wrote: post #70
notyourday wrote: post #61

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…

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.

In my observation, Docker skills is a modern day ability to type "make", without being able to actually write a Makefile or debug a Makefile.

Re: Why would anyone choose Docker over fat binaries?

#74

Post by stuartaxelowen »

awirth wrote: post #57
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…

But here's the thing: You can dockerise a PHP app. How am I meant to make a fat binary out of one? For years Facebook (reportedly) did this with hPHPc. Not a very good idea these days, but it's certainly within the realm of possibilities for large companies.

It seems you've misunderstood the problem.

Re: Why would anyone choose Docker over fat binaries?

#75

Post by tyingq »

hennsen wrote: post #71
awirth wrote: post #57

Earlier quoted context omitted.

But here's the thing: You can dockerise a PHP app. How am I meant to make a fat binary out of one? For years Facebook (reportedly) did this with hPHPc. Not a very good idea these days, but it's certainly within the realm of possibilities for large companies.

Yes, and we all know every shop in town has resources comparable to Facebook‘s...

You can compile a statically linked PHP interpreter. Probably a bit of messing around with configure and makefiles, but doable.

Re: Why would anyone choose Docker over fat binaries?

#76

Post by Silhouette »

anilakar wrote: post #70
notyourday wrote: post #61

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…

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.

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?

Re: Why would anyone choose Docker over fat binaries?

#77

Post by Spooky23 »

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…

It pushes thinking up to the app/middleware stack and away from server instances.

Re: Why would anyone choose Docker over fat binaries?

#78

Post by philipov »

Is pyinstaller a sufficient solution for creating fat binaries in python? I'm not interested in using go, and I also have C++ binary dependencies that need to be deployed but which come to me already built.

EDIT: "Or rather, if the problem is resource and dependency and configuration management, we should solve the problem by moving to those languages that support fat binaries."

Oh, so this article is really just an advertisement for Go. That sure spoils it.

Re: Why would anyone choose Docker over fat binaries?

#79

Post by pacala »

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.

Re: Why would anyone choose Docker over fat binaries?

#80

Post by noahwilde »

Silhouette wrote: post #76
anilakar wrote: post #70

Earlier quoted context omitted.

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.

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.
Post reply on HN