Docker Considered Harmful (2016)
catern.com
catern.com
He links to about 20 different tools/services with the attitude of "docker is just doing all this stuff that already existed!" as if that's a bad thing.
But it's not. It's the whole freaking point.
Docker took a bunch of existing tools and consolidated them into a single general tool, which acts as a foundation to build on.
Hell, they picked a shipping container as a logo for a fucking reason. We also shipped all the same goods before a shipping container was invented, but it was slow, inefficient, and required custom solutions for each port/ship/good. Shipping containers solved that by providing a single foundation upon which you can standardize and extend.
Docker does the same thing.
This is a bad article.
Abstraction layers are fundamental to software development, and not a bad thing.
Docker is a win because they have mainstreamed self-contained, "vm-like" applications that achieve native performance. The collective developer mind can now neatly wrap up the idea of an application into an execution environment that can be easily shared and distributed.
But again, these posts are useful because in the reductionist ranting, the author often lifts the curtain on how these abstractions really work, and that alone is useful to teach.
I think we used to call that a 'binary', but I'm old.
Docker is a strong solution to the problem of dependency conflicts between different software packages. It's what allows me to run software that only works with gcc 7 while my system is on gcc 8.
Docker just combined these concepts elegantly in a way that “clicked” with many people, and was fairly pragmatic.
The only major complaint I have about docker is its client/server model, it just makes so many things more complicated. It seems podman is doing great work in this area though.
Dynamic linking was a terrific solution to code size issues... 30 years ago. Back at the dawn of 32-bit computing, it was typical to see a multi-user machine with 1MB of RAM, for everyone to share.
Also, back then, systems weren't so well connected, and library releases happened once a year or so. Security wasn't as big a concern.
I can't help but think that if we (as an industry) had moved towards a Nix-like package system, we might not have gone down the container route. You just specify which exact versions of which libraries your application depends on, that's it.
Recently, I just tried to build a php binary for a system I don't have root access. Since that system don't have many things that are required to build php, I decided to build a static binary on my computer. Then, its dependencies are really complicated to compile with static linking, so I still can't get it work.
Docker might be bad because it creates an abstraction to something you might have to go digging around in anyway so the abstraction is leaky.
That abstraction also has complexity in it's own right. There are a lot of docker-related issues - e.g. how to dockerize data stores - so there is non-trivial complexity cost incurred when reaching for docker.
The argument could be that we've added a layer of complexity without much gained.
The same sorts of issues are there when you make the choice of AWS - abstractions that are themselves complex that, at the same time, are leaky.
An abstraction where I have to understand the layers underneath is not very useful.
Only when I got to the 5th section did it make some sort of argument, which ended up being about Docker not using an init system to manage daemons, and the usual problem this brings to badly-written images (process reaping). Ignoring the fact that plenty of daemon managers exist, and are used both with and without Docker, like supervisord.
docker run -it —-rm ruby
and I can try some code in the repl. Yes, I‘m sure I could fix it somehow, but I didn’t have time for it today, I just needed to get this short script working.It has encouraged people to move to a more immutable architecture, which makes many types of common problems easier to solve.
The value of Docker for me is the ecosystem, not the technical implementation.
Seems to hit a very similar mark.
Over almost 10 years of experience, I've learned 10x more due to tools like docker where first it made things accessible and useful, which drives me to learn more about how things work, to the point where _eventually_ I might have learned enough to write my own toy docker clone. None of that would have happened if I didn't find the tech interesting, which wouldn't have happened if it hadn't allowed me to run a few databases easily, without port conflicts, without more than a few commands and a pretty basic understanding of linux I had at that point.
Accessibility is the gateway to understanding. And try not to forget how you got to wherever you are, while also realizing that others may have different easier paths thanks to technology paved by those who did have the understanding you might already have.
Docker is great stuff. Don't know how they're going to make money but I'm happy the tech exists.
Copying a (voluntarily controversial) phrase to put on one’s rant on the new technology du jour is lazy.
https://www.researchgate.net/publication/315468931_A_Study_o...
This is really bad, yet unsurprising, when you bundle together hundreds of MBs of packages into each image.
Nothing to do with the BIOS, because now pretty much every CPU has the VT-x extension.
Docker (and the many, nice alternatives) standardize the format and build nice features on top. It abstracts away the lower-level stuff.
Neat to know about if you're interested in how it all works... doesn't mean it's harmful.
It seems to come from the same place that used to lead so many fledgling software companies to decide to write their own in-house CRM or bug tracker instead of buying a commercial product. Yes, the commercial product is big and complicated and takes time to learn and implements a hundred features you don't need. Yes, the absolute minimum implementation will take no time to hack together. But this is a trap. All that stuff you thought was just window dressing will inevitably prove to be critically important to someone at your company. A 90% solution will not work for the long haul, and rolling your own will inevitably send you down a path that ends in tears, blood, and the endless quagmire of implementing the last 10% of needed features that proverbially take 90% of the effort. And then 99%. And then 99.9%.
I know I can run dozens of docker containers but prob nowhere near the same number of VMs
(genuine question, not rhetorical or trolling.)
2016 opinion, yes?
Did I miss something?
Why, what, how, who, is it considered, harmful?