Live data from Hacker News

Docker Considered Harmful (2016)

catern.com

101–110 of 188 posts

Re: Docker Considered Harmful (2016)

#101
I think people who don't prefer Docker find it hard to articulate what is wrong with it.

To me it is really a question of, how do you vet software before you use it ? Will you take the time to understand your stack before it's deployed? When you employ certain abstractions, how much visibility do you lose ? Is it worth it ?

Docker is fine as one of many alternatives, but to turn your nose up at well written, battle tested software which is part of most Linux distro's is a little crazy. I would definitely bet that people who chose to learn how cgroups work, how systemd works will see their skills age more gracefully.

It reminds me of Dev-ops candidates that I have interviewed that laugh at the idea of ssh-ing to deploy a new version of code, without understanding that Ansible is generally doing the same.

Re: Docker Considered Harmful (2016)

#102
post #71

Earlier quoted context omitted.

No they haven't. They are lurking around the corner waiting to hit you when you least expect it. The mugging you are about to get is what your ops team has had and are trying to prevent. Enjoy the learnings...

There is only one possible place where this can really grow to be that kind of a problem: It's when ops isn't being involved. (And if the relationship between development and ops has broken down to the point that each one is trying to work around rather than with each other, you're already screwed. The rest is just details.) If ops is involved, then there's no real reason they can't take charge of making sure that an…

> (And if the relationship between development and ops has broken down to the point that each one is trying to work around rather than with each other, you're already screwed. The rest is just details.)

IMO 90% boils down to that, regardless of what technology one side or other wants to use. If Ops is trying to push Dev to use a particular technology or vice versa. This happens whether you're talking Docker or a particular programming language.

Either side will see their preference as solving the problem of doing their job in the best way possible. If both sides are deaf to the problems seen by each other, it becomes a problem.

Honestly, the place where I see this stuff more than anything is when developers want tools that make them more productive, because the technological merits are harder to convey.

Re: Docker Considered Harmful (2016)

#103
post #6

This feels a bit like "Why use Dropbox when rsync exists?" type of argument. Sure, you can do everything docker does with shell scripts, and you've been able to for decades, but many people didn't, because it was "complicated". There is often a huge amount of value in simplifying things, even if it means losing some of the power and the end result being objectively worse.

Reminded me of this HN comment regarding Dropbox right when it launched: https://news.ycombinator.com/item?id=9224

Re: Docker Considered Harmful (2016)

#104

Like any hyped up technology, Docker gets pitched as an "easy, works out of the box, secure by default solution" but it is almost anything but. But also like any technology, if you take the time to really understand what it is doing and what problems it can solve for you, it can be really awesome to work with. Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you ca…

> Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you can use the 10 technologies it wraps around and manage them yourself instead?" Why would I want to do that if I don't have to? Or if you can't? One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations…

> One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations for OS X and Windows. That removes a lot of friction for developers who work in companies where IT won't support Linux on employee workstations.

Vagrant does this, too. Sure, it runs a VM, but so does Docker.

Re: Docker Considered Harmful (2016)

#106
post #77
post #61

The point of Docker is basically that the container-image developer is specifying the sandbox, instead of the sysadmin specifying the sandbox. None of the things mentioned solve the problem of the sysadmin having to "design" the solution from the top down. Docker does. A Docker image is an appliance. You don't architect it; you just configure it. You don't have to care which OS it's running inside. Docker images runn…

You do have to care which OS it's running inside if only to know when to patch it for $vulnerability_of_the_day. It sure is convenient to consider it as a blackbox that you 'just' need to configure, but that's just pushing responsibility to the developer(s). In my short experience, the latter seldom care about security. When a security breach occurs, who is going to take the fall ? The sysadmins that supposedly run o…

Let's be clear: This is a general problem with distributed infrastructure. Not necessarily docker. Any org that scales beyond 100+ engineers/services/artifacts is just not going to hire same proportion of infra people to toss application configuration over the wall to.

In the past, we have done:

* Let applications write librarian-chef cookbooks, have a chef server aggregate them

* Let applications write ansible playbooks, aggregate them in a central repo using galaxy

All of them carry the same pitfalls. If its not the OS, then you have to decide how to patch the version of OpenJDK that the developer hardcoded. If its not OpenJDK, then its maven or npm.

We have seen both sides of the arguments:

* Sysadmins cry "security"

* Developers cry "freedom"

The root cause of both arguments is fear and control. The end goal when these words (security vs freedom) get thrown in is not to find solutions, but rather to make the discussion end. Sysadmins will gladly sweep maven/nexus problems under the rug as long as they are the ones doing automation. Developers will gladly disregard all infrastructure engineering principles as long as they have full access to do whatever they want with their application.

Automation is the solution to both. Call it SecOps or whatever bullshit term. But in the end, automated security practices are necessary one way or another.

Re: Docker Considered Harmful (2016)

#107

Earlier quoted context omitted.

> Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you can use the 10 technologies it wraps around and manage them yourself instead?" Why would I want to do that if I don't have to? Or if you can't? One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations…

> One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations for OS X and Windows. That removes a lot of friction for developers who work in companies where IT won't support Linux on employee workstations. Vagrant does this, too. Sure, it runs a VM, but so does Docker.

Vagrant runs a VM per app. Sometimes more. Big difference.

Re: Docker Considered Harmful (2016)

#108
post #11
post #6

This feels a bit like "Why use Dropbox when rsync exists?" type of argument. Sure, you can do everything docker does with shell scripts, and you've been able to for decades, but many people didn't, because it was "complicated". There is often a huge amount of value in simplifying things, even if it means losing some of the power and the end result being objectively worse.

Docker has reached the point that it is complicated. A lot of people never did cgroups just because it is lower, starting to touch kernel stuff. Few people want to go there. Docker is one of those things that you can install and run; it takes a small amount of time to get running. As you said, value in simplifying things. That being said... Anyone who takes the stance that containers are better than X/Y/Z are just sh…

> Anyone who takes the stance that containers are better than X/Y/Z are just showing that they don't have the drive to get into the why of how it all works.

... or they know exactly how it all works because they've been through hell back & forth several times and are now happy to have a system available that solves many little nerve-wracking problems.

Re: Docker Considered Harmful (2016)

#109
I think that Docker became popular because of very limited functionality of distributions' package managers that doesn't match developers' expectations.

Traditionally in Linux there is no concept of "system" and "applications". There is only one large "system" and you can add parts to it. In old times, you downloaded C source code, make'd and installed it. Now you use a package manager to extend your system with new features, like playing music or editing images.

There are no "applications". If you download Firefox package from Debian repository, it is not the Firefox application; it is a version of Firefox, tuned, patched and customized for integrating into Debian. You probably won't be able to run it even in Ubuntu, let alone other distributions.

Paths are often hardcoded; you cannot install a program into your home directory or an USB drive (apt-get might let you do that but it won't fix the embedded file paths for you).

It might be good enough for a user (as we see with Google Play Store on Android), but it is very inconvenient for a developer. You often need to have several versions of a program, for example, PHP interpreter or Go compiler; no way a package manager lets you do that, compile them yourself. You might want to use an application with project-specific config rather than the one in /etc and start it on demand rather than install as a system daemon. That is not easy too. Apt-get and dpkg has literally hundreds of configuration knobs in the manual but you cannot choose installation directory.

If you want to run an old application, like Firefox 2.0, get prepared for troubles. While newer versions of libraries like gtk are supposed to be backwards compatible, it won't run with them (I tried). You will have to obtain and build old versions of gtk manually; good luck with that. On the good side, I can add that Debian maintains an archive of old packages and you need only to write a custom package manager to install them along with their dependencies.

Often official repositories have outdated versions of software; you have to add third-party repositories while giving them full root access to your machine. Want to install Sublime Text in Debian? You have to trust its authors because they can replace your sshd and you won't even notice. Also, third-party repos sometimes break or conflict with system ones.

Package managers are a pain for developers too. They have to maintain packages for all popular distributions, and even for different versions of those distribution. Because there is no "apps", you have to integrate your program into every distibution manually. Of course, you will have to do it again and again when anything changes in the distro. Distro maintainers often have to do the same thing, maintaining private patches. And on top of that, different distributions use different package format.

Maybe one of the reasons for this is a lack of a standard package manager and build system for C programs. You cannot download from Github and build a C program with dependencies with a single command. It is disappointing if you got used to languages like PHP where it has been possible for a long time.

Docker seems to solve many of these problems (and some other, like hardcoded server port numbers) by using a lightweigt virtual machine with full-blown distribution in it. Of course it looks more like a quick hack rather than reliable and well-thought solution. Also, Docker requires many resources: space on disk to store multiple images, memory and CPU time to run unnsesessary daemons inside virtual machines. I don't like it.

By the way Linux kernel has similar problem with drivers that are a part of a kernel rather than separate entities.

Re: Docker Considered Harmful (2016)

#110

I think people who don't prefer Docker find it hard to articulate what is wrong with it. To me it is really a question of, how do you vet software before you use it ? Will you take the time to understand your stack before it's deployed? When you employ certain abstractions, how much visibility do you lose ? Is it worth it ? Docker is fine as one of many alternatives, but to turn your nose up at well written, battle t…

[deleted]
Post reply on HN