Docker Considered Harmful (2016)

> The author misses that completely.

That's inconsistent with what the article says right in the introductory paragraph:

> Docker is genuinely more complex and harder to use than the alternatives.

> I'm recommending them because they are simpler to learn and use.

You may disagree with their relative ease, but it's disingenuous to say that the author misses that.

> You'll come up with your own unique solution to most problems addressed by docker.

"Unique" is a pretty extraordinary claim, considering the author is advocating using pre-existing tools and facilities. Replacing AUFS with Btrfs is a far cry from writing ones own filesystem entirely.

> I login into a server managed by this author, curse him for using all those "standard" techniques in his own unique way. Spend hours figuring out the details.

They're not "standard" (with quotes). They're standard (without quotes). They have man pages. They're well-documented and (one would hope, if Docker makes heavy use of some of them) well-understood. Again, just because he didn't use them in the Docker way, doesn't make that way unique. Chances are, if it takes you hours to figure it out, especially if you already know what and how Docker does it, you're doing something woefully wrong.

> I login into a server running things with docker: I already know all I need

I could make exactly the same statement with the situations reversed, except with the addition that I now have to learn this "docker" tool with its added complexity and new syntax to make sure I don't break anything in case I have to make a change.

Already knowing a tool fails to address the author's point.

And in your example they’d both be wrong. Such folks shouldn’t spend as much time worrying about their job description as about what will make the company successful?.

Companies don’t become great by everyone waiting around for only managers to decide when new roles or practices should come online. Employees at any level are allowed to consider the big picture. Why do they sometimes feel they’re not allowed to or would be discouraged from doing so?

If you carefully and thoughtfully put some time into slowly baking your opinions in a way you best guess helps your company end to end to achieve its most strategic goals with dev/ops as one part of that, your opinion will be more respected and influential.

It’s also a management test. Walk into your VP’s office, dispassionately and without self emphasis, make your case about how you should be doing xyz because it makes sense within the big picture.

Most times you can’t lose, even if the plan isn’t rolled out you’ll gain credibility. If you get your hand slapped, it’s a clear signal to switch departments or companies because leaders like that have low success rates, as well as usually not being much fun to work for.

Having tried (and succeed) many times in making Debian packages, I can attest to the value of these "hassles" and ones like them.

Much of the value is just in making sure one thinks about that whole breadth of issues and how they'll affect your environment. You may decide that a particular hassle actually is too much effort for not enough benefit, but at least the decision is conscious and, if it "bites" you later, you know where/how to go back and change things.

Additional value can come from all the taken-for-granted work that's been done over those past 20 years. Need multiple versions of something installed at the same time? Maybe the distro people already have a standard way to do that.

Of course, all of this value can only be obtained after a remarkably huge up-front investment of learning, and, from what I recall, already knowing RPM didn't substantially lessen that load when learning debianization. It's tough to fault the attitude of "fuck it, use Docker for packaging" (for any value of "Docker", including "tarball", "pip", "npm", etc) for anyone whose career isn't Ops.