31–40 of 180 posts
The author is right about k8s. And what do you need to run stuff in k8s? Containers. And what is a pretty good container format? Oh yeah, Docker.
Although other containers exist, let’s be honest, people running k8s are almost always running Docker containers in them. And it all works amazingly well.
How do I run fat binaries in k8s? In a production ready and battle tested way please.
That being said, there are many people who are using Docker primarily to solve the DLL hell problem of shared libraries. And containers don't really provide that great of a solution as far as security is concerned; VM's will also be more secure.
And the statement that the Go language is the pioneer for fat binaries is, well, just wrong. People were using static binaries (with, in some cases, built-in data resources) to solve that problem for literally decades. MacOS, for one.
I also remember working with one of the eventual co-founders of Red Hat back when MIT was interested in a proprietary math analysis tool for SCO, but which we were planning on running on Linux. MIT had purchased a site license, which he was going to implement by checking the network address to see if it was 18.x.x.x. He was going to provide a statically linked SCO binary that had this check. The funny thing was that his development system was Linux (it was more developer friendly), and he was cross-compiling to create a statically-linked SCO binary --- which we were then going to run on Linux using SCO emulation. But that statically-linked binary was basically a "fat binary", which would work on any system (including any Linux distribution) that supported the set of system calls SCO used. (Ah, the early-90's, before Red Hat was founded and before IBM had "discovered" Linux, were simpler times....)
I'm far from a big fan of Docker, but can definitely see the appeal for providing a solution to those problems, even if some see it as unprincipled. In our case we'd already put a lot of effort into building mostly self-contained binaries and Docker is still useful (admittedly mostly just as a component of Kubernetes; we'd cheerfully replace it with rkt or something if there was a good option).
Docker container is an extension of that idea. If you can distribute some of the libraries, why not distribute entire execution environment? Why not isolate your application from external environment even further?
The more you control the environment the less work you have to do to make sure the application will work.
My point of view, there are two types of applications with diametrally different development process:
1. applications where you have to invest a lot of effort into making it resistant to the environment -- it has to work regardless of the differences in user environment. Think for example in terms of a PC game that must run on different GPUs, with different driver versions, on different OS versions, with different applications installed.
2. applications where it is enough to show that there is a set of circumstances when the application works correctly -- think in terms of typical enterprise application where DEVs would place it on the server and then the environment would be religiously preserved to not risk application breaking.
Developing type 2 applications is much, much, much less effort.
By distributing type 1 applications along with the environment we basically reduce the cost of developing them because now it would be enough to develop them up to type 2 applications standard.
For example: you may create a simple bash script to do something. If you distribute it as just script file, you need to make the script work on every bash on every type of mainstream Linux distribution.
If you distribute the script as a docker image it is enough for you to make that script work on that particular image (for example Ubuntu x.x) and you don't need to worry about other possibilities.
This is the essence and value in distributing of applications as Docker images.
What does having an x86 and x64 binary in the same executable have to do with dependency management? You can have a fat binary that is dynamically linked. If you have an x64 OS then the 64 bits run, but they still call OS libraries if the app is dynamically linked.
Static linking [2] is what compiles all the dependencies into one big executable, but every compiled language has that. It is not exclusive to Go.
Fat binaries solve one of the problems which Docker containers solve. It doesn't solve the security isolation problem, or the resource control issue. That being said, there are many people who are using Docker primarily to solve the DLL hell problem of shared libraries. And containers don't really provide that great of a solution as far as security is concerned; VM's will also be more secure. And the statement that t…
...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 can package up all our existing code into docker containers, sprinkle some magic orchestration all over the top, and ship that.
I can also see, as per the article, an argument that we'd be much better off with fat binaries. But here's the thing: You can dockerise a PHP app. How am I meant to make a fat binary out of one? And if your answer is "rewrite your entire codebase in golang", then you clearly don't understand the question; we don't have the resources to do that, we wouldn't want to spend them on a big bang rewrite even if we did, and in any case, we don't really like golang.
All of which makes this article seem oddly academic to me. There's a lot of value to something that can be layered on top of your existing solution for those of us who aren't starting greenfield projects.
[1]: Also, while "fat binaries" is a great term, it's one that already exists and means something totally different.
"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…
> 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.
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.
On UNIX world older examples than the ones you provided, would be HP-UX vaults and Tru64.