Docker is a dangerous gamble which we will regret (2018)

by maple3142 • 6 years ago

132 125 6 years ago

jiofih• 6 years ago

We should all move to Krubnernetes

bilekas• 6 years ago

I have to agree a little bit.. One other thing that bothers me is when I don't WANT to run docker. Some packages/services actually make it tricky to achieve this. With some time being spent reversen engineering.

Docker is cool don't get me wrong, but it might be a bit over used sometimes. And I really don't think it needs to be this 1 way solution to everything.

collyw2• 6 years ago

The youngsters in my work keep sticking everything on docker to avoid packaging problems. I just makes running coed in a stepthrough debugger impossible so far (I know its possible but I haven't had the time to make it work yet).

One step forward two steps back.

EamonnMR2• 6 years ago

I had this problem too when my team first adopted docker, but you can use a conventional debugger if you run your container interactively (with -i.)

Frost1x• 6 years ago

Recently started working with other younger devs and I feel like every single application they write starts with a docker compose scaffolding.

Containers have uses but they're being treated like silver bullets and building new levels of unnecessary complexity in many cases.

smoe3• 6 years ago

I know of a team that spent significant time getting their front-end to run in docker. Because they were having regular problems getting the app to run on the developers machines due to extremely outdated versions it depended on.

Oh no, we have a problem! Lets put the problem in a neat container. Now we have a problem with a layer of abstraction on top, soon to be two problems. Rinse and repeat ...

viklove2• 6 years ago

You can just... not run the application in docker, can't you? Check out the repo on your local machine and install all the dependencies yourself -- problem solved.

steeve2• 6 years ago

The archive link is down and the original article is dead, so I can't read it...

The comments on the article are not kind, however [1][2].

1. https://www.reddit.com/r/devops/comments/8j9yrn/docker_is_th...

2. https://www.reddit.com/r/docker/comments/8jk22u/docker_is_a_...

maple3142• 6 years ago

Maybe you are using CloudFlare dns? It seems like 1.1.1.1 can't correctly resolve archive.is [1]

[1] https://news.ycombinator.com/item?id=19828317

steeve2• 6 years ago

Thank you!

zeveb• 6 years ago

I completely agree. My team has spent the last several years building software we then deploy with Docker and Kubernetes, and looking back I think that our software would have been much better deployed as statically-linked binaries on simple Linux servers.

We're writing in Go, which means we already have the statically-linked binaries, which means we have a single file which needs to get deployed. What does Docker buy us? … a single file which gets deployed. We could get the same effect of Docker Hub by just scping versioned binaries.

Kubernetes is far worse, of course. It is an amazing ramshackle collection of disparate, ill-fitting parts which make everything 'easy' but nothing simple. It does buy us some useful things, but I don't think they are worth the cost.

A bunch of EC2 nodes running Debian, with a few dozen-line shell scripts to copy binaries around, would completely replace our usage of Docker and Kubernetes and drastically reduce the complexity of our system. We just don't need a lot of what Kubernetes does (no doubt others do), but we have to pay for it in complexity anyway.

I really do believe that in the future we will see a few companies be very successful by foregoing Docker + Kubernetes + Helm (yo dude, I heard your YAML was giving you problems so here's some more YAML to YAML your YAML into YAMLy submission!), and then a few years later we will all look back at this mess a little bit like people look at the Pet Rock craze.

ex_amazon_sde2• 6 years ago

Amazon (and other FAANGs) use OS packages and do not use Docker nor Kubernetes or anything with all that complexity.

This is a deliberate choice, at least in Amazon.

busterarm8• 6 years ago

Fire and Motion.[1]

[1] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

notacoward2• 6 years ago

Maybe you know how it is at Amazon, but your statement is definitely not true for two other FAANGs. It's well known that Kubernetes is the open-source version of tools that already existed within Google, and Kubernetes itself is part of some public-facing products. I work at Facebook, and we most definitely do have our own equivalent of Kubernetes. It's awful in all of the same ways IMO. We also build fat binaries (and I believe the same is true at Google) but that's orthogonal. So one point for your claim, two against. Maybe someone else can fill in the blanks for Apple and Netflix.

shadowgovt7• 6 years ago

If you can keep the use-case constrained to that, I agree. If you ever find yourself having to couple those Go binaries with someone else's Python or node code, Docker making it simple to bundle all those binaries into a standard packing infrastructure will be nice-to-have.

mristin• 6 years ago

You can use PEX for Python.

At my previous job, we used a python script to rsync files -- very, very simple. I think it would have been much more difficult and error-prone with Dockers.

mixmastamyk• 6 years ago

with a few dozen-line shell scripts to copy binaries around,

Sounds like you're looking for Ansible.

vorpalhex2• 6 years ago

Oh geez, having a team of 24 engineers across multiple countries trying to maintain a common set of bash scripts that work for 12+ unique services sounds like a disaster.

Instead we have a single workflow for docker, whether it's going out to AWS or Kubernetes and all the services use an identical flow. Integration testing is a cinch since it's running actual, version matched postgres/redis/etc on the CI nodes which get spun up on demand and against the same docker image that'll get pushed out to production.

We haven't had a case of "Well it works on my machine why doesn't it work on yours!?" in a really long time since if it works in docker.. well it works in docker.

leecarraher2• 6 years ago

Exactly, docker standardizes something that was an otherwise nightmare to maintain across platforms and organizations. Next we need to standardize the orchestrator, my money is on kubernetes, but I wouldn't say it has won over everyone just yet.

SaasDeveloper12• 6 years ago

The industry has standardized on Kubernetes for the orchestrator. If anything we are starting to see other container runtimes other than Docker as K8s added the CRI (Container Runtime Interface).

user5994461• 6 years ago

Kubernetes has won already and Docker went bankrupt. It might take a bit of time for everybody to realize but the dice have rolled some time ago.

the company was sold for scrap shortly after this article https://thehftguy.com/2019/10/22/the-demise-of-docker-and-th...

matteuan3• 6 years ago

The author addressed exactly this type of comment. I don't see the real difference in complexity of maintaining 12+ bash scripts instead of the same number of Docker files. And for the deployment, the alternative given by the author is using fat binary.

shadowgovt7• 6 years ago

I don't see the real difference in complexity of maintaining 12+ bash scripts instead of the same number of Docker files.

With respect, I have to assume your experience is either in an ecosystem with really strongly-established best practices for bash (and someone with the job of enforcing said practices) or your organization has no more than two or three people maintaining those dozen-plus bash scripts (and is on its way to a headache when two of those people retire at the same time and your org tries to on-board someone new to read those scripts).

jskrablin• 6 years ago

Docker file produces what basically is a software package with all the required dependencies. Deploy it to some Docker host and it will most likely run. It will run on a developer laptop, a VM or in K8s/Mesos/Nomad cluster. Add some docker compose files and you'll be able to run your whole service locally with all the external dependencies if you think that's a good idea. Extra bonus is... target system requires Docker daemon only. So no extra work to support Ruby/Java/Go/Python runtimes.

Alternatively you can go and package tar files. Or create Debian/Red Hat/Nix/whatnot compatible packages and manage dependencies via a package manager. You can go with Snap or Flatpak to achieve ~ the same. However Docker images produced by the said Docker files will most likely just run on any of the said OSes with no or little additional work and probably on the OSX and Windows too. And people will be pretty happy that running docker build $some_opts will (likely) give them a working app/(micro)service and that they don't have to mess with $some_packaging_system to rebuild and test stuff locally. So I guess Docker files provide some extra flexibility even if the maintenance burden is matched to the one required for maintaining bash scripts.

jasonlotito• 6 years ago

Fewer than half the number of engineers with hundreds of unique services. We aren't "just" using a common set of bash scripts, but we do have few. It's not a disaster, and it just works. What we deploy to a testing environment is what we deploy to production. Not a disaster. Deployments are a single button push.

Building the framework for a new services is filling out a form, and everything needed gets generated, including automated documentation, life cycle jobs, repos in github, properly configured security groups, etc.

We are exploring Docker, and while Docker offers some nice advantages, the added complexity and additional points of failure needs to bring some major benefits, and need to solve real problems we have. Not imagined problems.

alxlaz2• 6 years ago

That hasn't been my experience with docker at all. Except for pretty simple projects, I can't remember a single project I've worked on where I could just follow the README/"Here's how to set it up" email/whatever and have it work the first time. Every time a new developer came in, we'd find out that some implicit assumption was baked in somewhere, and finding out where took hours or days because debugging the damn thing is almost impossible. Everyone eventually syncs their environment but that just conveniently provides the illusion of standardization and repeatability. It's the same kind of "standardization" and "repeatability" we used to get twenty years ago -- all standard and repeatable, as long as no one touches the Solaris box that hosts the production deployments and no one updates their workstations.

And that's just the "legitimate" stuff. The amount of hours that we've wasted on things like "X runs docker 1.9 but Y runs docker 1.10", or overlay bugs, or image pruning failures, is insane. Breaking things is an inevitable side effect of progress but maybe infrastructure software shouldn't break this much...

Far from me to say that 20+ engineers across the world maintaining bash scripts for a dozen services is better. I used to do that and it was extremely terrible. Even when everyone involved had years of experience and the mundane task of updating deployment scripts wasn't delegated to interns, the way it is today (for reasons that I am entirely unable to comprehend). Definitely far more terrible than Docker. Docker is not as terrible, but still pretty terrible.

I'm open to the possibility that I've been doing it wrong, and that every team I've worked in/every customer I've worked for has been doing it wrong. But this has been going on for like four years now and enlightenment doesn't seem to be any closer to hitting me...

pm905• 6 years ago

I don’t wanna gaslight you but this doesn’t match my experience at all. I’ve literally never run into issues with something compiling info one version of docker but not another. Image pulling has been a problem sometimes on Kubernetes but you just need to configure the creds correctly and boom it works.

mumblemumble4• 6 years ago

having a team of 24 engineers across multiple countries trying to maintain a common set of bash scripts that work for 12+ unique services

At the last place I worked that had a truly tight devops operation, it was 3 DevOps people maintaining infrastructure for 200+ unique services. And most that infrastructure was building really useful junk that I've never seen available elsewhere, like daily email reports telling me about every error that was logged on any services that my team maintained, and a cool little web UI that monitored our message bus and generated a visualization of which services (and instances) were listening to what.

The actual deployment and process management infrastructure wasn't very complicated, either, based on what I saw from poking around in their source control. They were able to shave a whole lot of unnecessary complexity by enforcing rigid standards about how each process would be packaged and configured and whatnot, regardless of implementation language. It was up to the developers who wanted to take on $hot_new_langauge to figure out how make it behave right.

And that gets to my real worry about Docker. It's a way of dealing with messes, not by cleaning them up, but by sweepi^H^H^H^H^H^H hiding it behind an abstraction. It's like that meme image that floated around a while back - "But it works on my machine." "Then we'll ship your machine." And that's how Docker was born.

Which isn't to say that this is useless - I use Docker all the time, chiefly to do things like making sure I'll never have to manually futz around with managing multiple concurrent PostgreSQL installs ever again - but, at least in production, it still feels to me like high tech duct tape and chewing gum.

dariusj18• 6 years ago

I think docker/containers are the opposite of abstraction. It's a reduction of variables and creates true predictability across very disparate systems.

leecarraher2• 6 years ago

I would like to see more vetting in dockerhub and security in general, yes it's based on cgroups which are specifically security minded, but not all docker users are aware of this. A novice user pulling a random docker image, and running default as root is bound to cause some issues.

shadowgovt7• 6 years ago

Docker itself is a good idea; a standard repository of other people's opaque binaries and an ecosystem discipline of "Just pull in whatever you need; who cares why it works or who maintains it?" probably less so.

freeone30003• 6 years ago

The author's approach presupposes a devops "person" (side note: if you have a person in charge of ops, that person is an ops person, not a "devops" person, as devops is a process; either your org is on it or they aren't). If you want developers to launch to production with any degree of reliability, you're going to need either a lot of tooling support for your specific workflow, or you're going to use docker and a significant degree of creative blindness. The fat binary approach works great if you can build a fat binary - python and node are nearly diametrically opposed to compiled binaries in general, much less ones that include a list of dependencies. The docker image is the fat binary that our toolchain is set up to build and run.

matteuan3• 6 years ago

You are assuming that developers have enough knowledge of Docker to deploy in production confidently. Why is it different for other ops skills? What "degree of reliability" does Docker adds over bash, for example?

freeone30003• 6 years ago

It adds full environment reproducability. Essentially, "it works on my machine" -- "then we'll ship your machine". Nothing about docker in particular is meaningful, if they shipped VM images this would be identical, but docker streamlines creation and management of the entire OS image. It eliminates all differences between the developer's laptop and the production server.

forgottenpass2• 6 years ago

that person is an ops person, not a "devops" person, as devops is a process; either your org is on it or they aren't

"devops" has made the same slide to meaninglessness as "agile." At one point they might have meant something about the philosophy of getting a job done. They don't anymore. They're buzzwords for a bunch of mutually-incomparable ideas, and as long as we pretend there is still meat in the concepts we're just lending buzzwords credibility.

"devops" is a verbal pyrbar for whatever change management already wanted to make, and shouldn't be seen as much more than a string of characters to get a resume through a regular expression.

judge2020• 6 years ago

side note

I imagine a devops person as someone who manages IDE licenses and possibly the company's docker registry and SCM server.

rossdavidh2• 6 years ago

If I use Docker, I get to put "Docker" on my resume for the next job; if I use bash scripts I don't. If I use React, I get to put "React" on my resume; if I use vanilla JS I don't. If I use Kubernetes, I get to put "Kubernetes" on my resume. If I use AWS, I get to put that on my resume, if I just spin up a Linux instance using Linode or etc, I don't Of course, I would have to convince my boss to let me do all of these. But, he also wants to be able to put on his resume that he managed developers who used these things, so that's an easy task. Many of these made perfect sense for the FAANG company they were developed for, but they are used at companies with 0.01% of the number of servers of those companies, and the basic reason is that both devs and managers want to pretend they are working at FAANG, so that someday they will work there.

Again, there are valid use cases for all of these, but there are also valid use cases for semi tractor trailers. It doesn't mean I should use one to get my groceries.

k__2• 6 years ago

The problem is, as so often, the system.

If HR goes as low-level in hiring as "React Developer" then people have to play this game.

If HR would hire on something more substantial, it wouldn't matter if you did Linode or AWS, React or Angular, Docker or Bash scripts.

pc862• 6 years ago

HR having any role more substantial than confirming that an applicant can legally work in the US and isn't lying on their resume is the problem.

mywittyname3• 6 years ago

Hiring people is difficult, exhausting, time-consuming, and largely a crap shoot, since hiring consists of deducing a person's technical abilities with around 1-2 hours of interaction in a very limited scope.

If we could find a better way, we'd be using it. But, as it stands, recruiters and HR have only a few minutes per potential candidate to determine whether or not they meet the hiring manager's criteria. It's unreasonable to expect HR/recruiters to keep abreast of an ever expanding list of technologies and their analogs because that's not their core competency. Unless they are repeatedly told that GCP experience is worth like 70% of AWS experience (replace the values and technologies as you see fit), they aren't going to know that.

shadowgovt7• 6 years ago

It's a bit more than that; there's a reason the next job cares that Docker, React, or Kubernetes are on your résumé.

If you use Docker, you get to claim that you're familiar with a framework atop a lower-level abstraction, and the lower-level abstraction is flexible to the point of incomprehensibility; few people enjoy maintaining someone else's bespoke shell script environment, and there's not much of a forcing function to cause standards to exist in that abstraction layer for doing a specific task (creating and managing deployable artifacts).

React vs. JS and Kubernetes vs. "Our previous sysadmin's solution built with hair-pulling and rage before they quit to embrace the life of the humble riverboat captain" follow the same pattern. The frameworks and toolchains listed are standards that allow someone who has solved that common business use-case at one organization to solve that use-case at another org with minimal spin-up time (vs. the time to learn bespoke solutions to do the same thing). Many people having the same problem domain to solve is how standards come to exist.

busterarm8• 6 years ago

Do you actually think Kubernetes infrastructure is built without hair-pulling and rage?

If so, I've got some stories for you.

nick_• 6 years ago

https://rdd.io/

djohnston• 6 years ago

and the basic reason is that both devs and managers want to pretend they are working at FAANG, so that someday they will work there.

Strongly disagree. The reason they prefer Docker is that nobody wants to read your bash script. They want a standardized set of tools they can familiarize themselves with using curated examples and a large community.

raghava• 6 years ago

> resume building

Exactly. Every developer is always running a build-resume thread in his mind at the background, which drives choices many a times.

But why does it happen?

May be, there's no way for the developer to claim the value driven, and thus these skills end up being the proxy to be showcased!

If a developer's resume mentioned "got a 40% reduction in total operating cost of the supply-management-pipeline by enabling automated operations and reduced errors by 20% over a year, and helped drive sales up by about 30% over two years", this would NEVER get picked up by a recruiter - who would just be skimming the resumes for specific keywords. Worse, it could be an automated tool scanning the resume.

Also, in the general scheme of things, developers are kept off the real value outcomes for a reason - to prevent them from understanding their true value. Cause, it is good for business! :P

All of these combine to cause developers from not understanding the quantum of value being driven by their efforts, and thus to compensate for the lack of this important info - and to compensate for the shortcomings of the industry standard "job-description" templates that bother only about skills-and-number-of-years (as opposed to value-outcomes-driven-over-unit-time) make it harder for developers to really understand (and then showcase these in their resumes).

Also, an old classic on these lines - http://www.bruceblinn.com/parable.html - The parable of two programmers.

"I don't want to seem like a hack, so I'll do enterprisey things, so that nobody can call me a dumb guy" is another thing running in the background.

vonseel• 6 years ago

I’m actually looking for a job and this has come up more than once.

I agree with you for the most part.

Docker isn’t all that difficult to use and I don’t even see why they bother asking. I just laugh and tell them, yeah, I know docker, along with being quite proficient in Linux in general and other deployment technologies. I don’t see the point of asking developers if they know docker. If you can learn to code, you can learn the basics of docker in 15 minutes.

React and frameworks are more specific and I can see why asking about those for developer roles is more appropriate.

AWS is so damn big at this point that I don’t know what they are really asking by just saying “AWS”. Sure, I know about the core AWS stuff, but I’m not proficient in really specific AWS CloudFormation templates or AWS IAM policies and stuff. And I’m not sure most developers outside of devops should be responsible for such a thing. For day-to-day software engineering, I shouldn’t need to touch the servers - that should be handled by a CI process and/or devops persons.

somurzakov• 6 years ago

don't gitlab/azure devops pipelines make docker irrelevant?

oblio• 6 years ago

Aren't those orthogonal (i.e. have little to do with each other)? Why would Gitlab/Azure DevOps Pipelines (CI/CD tools) make Docker (a container engine) irrelevant?

drchaos• 6 years ago

Gitlab CI can build a docker image whenever you push code to your repo, and host said image in the builtin docker registry.

It's not a replacement for Docker, but a very useful companion.

mattxxx• 6 years ago

Docker may be over-used, but, when managing hundreds of instances of machines, it's really useful to have deploys/redeploys/updates: - Immutable (the instance is effectively frozen as an image) - Has dependencies baked in (don't have to worry about whether the app was run on xenial/bionic,etc.) - Identical (people are disincentivized to make ad-hoc modifications to instances)

pc862• 6 years ago

when managing hundreds of instances of machines

Well there's the rub. Most developers aren't going to manage hundreds of machines. My current company has thousands of customers, over a hundred employees, and makes tens of millions in profit. We've got two dozen servers (VMs) and obviously less than that in actual machines.

The scale at which you need hundreds of instances is probably when it does make sense to use something like Docker.

rjkennedy982• 6 years ago

A lot of developers work in big companies.

My last company had 2400 OpenShift cpu cores assigned just to unused OpenShift projects. I'm sure the number of used OpenShift cores was in the tens of thousands.

For instance just a Kafka consumer that needs to sync a few billion records to cassandra and ElasticSearch by itself may use 50 cores.

marcinzm• 6 years ago

Docker lets you have a standard easy to run reproducible description of a system (service + all dependencies) as code for any service. It's a fat-binary for anything that is also the build env for that binary. Not all languages support native fat-binaries and even those that do you still need a way to reproducibly build that binary (CI doesn't count because local testing builds can't reproduce it).

rjkennedy982• 6 years ago

Plenty of companies:

a) do not want to give people/scripts access to the machine.

b) do not want to employ a bunch of people whose sole purpose is to manage these machines.

Being able to provision (for instance) an Openshift project in a click to deploy docker containers solves those problems.

Yes, those are not problems that a startup or a small business has, but these are problems that all large enterprises with sensitive data have.

Docker is a standard that anyone knows. Is it the best standard? Who knows, but it is a platform and a standard that has built an ecosystem. That fact alone will make it better than any product or custom-built deployment solution that has to be maintained by a team of engineers.

sh87• 6 years ago

I notice that once you're invested, time and effort wise, in doing something one way, and it works, the general unwillingness to learn different or newer ways of doing the same things increases rapidly. Overcoming such prejudice requires understanding and accepting the incentives for further investing time and effort to accustom with newer technology.

Use-case driven technology fit is just one incentive. There are other incentives like resume enhancement, participation in communities where there is rapid development, FOMO / fear of being a dinosaur, the reputation of being known as someone well versed with the latest technologies, monetization via online courses/tutorials. These are just a few I could think of, I'm sure there are more.

In my relatively short career, I saw this playing out with NoSql databases, microservices architecture, SPA (AngularJS), NodeJS, responsive websites, blockchain and more recently, ReactJS, data-science (AI/ML) and containerization.

Each one of these, at some point or the other, have been used in cases where the problem space was completely solvable without using said technology but was introduced for some other incentive.

Say what you will but this rapid change is what makes and keeps this space moving, interesting, inspiring and well-paying.

darkwater• 6 years ago

The author has the boldness of saying that anything that does not produce a single artifact (golang binary or fatjar) is a language that should not be used an that they were errors of the past and we should get rid of them (citing explicitly PHP, Ruby and Python).

Now, if we want to think that languages and whole ecosystems (libraries, bugs and edge cases fixed, developers and companies whose code base is written in such language) can be changed easily, then the author take on Docker is right. In such a world Docker doesn't add anything useful. But the real world is quite different and it's not going to change for the author, so Docker (or "containers") is still adding something valuable and it's not a "bet" to me, at all.

jpochtar• 6 years ago

By expecting Docker users to know more than they do, the author thinks they're dumber than they are.

Docker users are mostly folks who specialize in other areas of programming, to whom Docker popularized affecting "fat binaries" out of PHP/Ruby/Python/node apps via chroot. Chroot was already well known to ops folks, but was arcane to most webapp devs.

We're not ops experts who have been confounded by marketing, we're ops amateurs for whom Docker cracked the nut of chroot legibility.

The author hates on Docker in comparison to other fat binary techniques; he ignores that pro-Docker advocates are comparing it to not using fat binaries at all.

forgottenpass2• 6 years ago

I don't trust people who like their software tools. I can trust some of the people who believe that their usecase justifies the cost of a tool, as long as they can also articulate it's limitations. If someone doesn't understand the environment and problem a tool solves well enough to rattle off a laundry list of good, bad and ugly design decisions, then their baseline analysis doesn't have any utility.

It's a subtle distinction, because once someone is primed that these are the two options, everyone thinks they're in the second category. You have to give someone enough rope and hope they offer up how much they "love" their toys.

I like this article because the container toolset ecosystem needs criticism to evolve. And we don't see enough of it.

cbushko2• 6 years ago

Docker is the fatbinary that he is talking about. It supports all-the-languages and runs just about everywhere.

The article ignores the fact that companies do not have the time, money, expertise, and desire to re-write their apps in a language that will compile down into a binary. There is a reason so many successful companies use PHP and Ruby. They work and make those businesses money. Taking a golang binary and building it into a tiny scratch docker image would be fantastic too.

In a previous job we ran hundreds of bare metal machines that were built up using puppet. It was amazing in the sense that it was somewhat standardized and could scale well. I still wish every service was using docker. We had php, ruby and golang services and getting all of those dependencies running was a pain. Not only did you have specific machine images to support each language, you had to support each service type too. If they were in docker containers we could have had one machine time and moved the docker images around.

magware• 6 years ago

Docker (and docker-compose) is super useful for local development environments. Sure, there are problems with docker on windows and with non-root containers. But docker is way better then most of the other tools I used for this (vagrant and whatnot).

A main problem in my opinion is, that old images are no longer published (or removed from dockerhub). I doubt very much, that you can build docker images that are written now in 2030.

But I assume the same happens with Packer + Terraform. In both cases you need to make sure the image is saved and accessible at a place you control, because the build will stop working at some point in time. Also the nice thing about docker is, it runs local (developer machine) and in production. I am not sure how you archive that with AMIs.

Building fat binaries is only easy for some specific languages and tools. In docker, it is easy for everything. At the end docker gives you a standardized way to deploy (image, environment variables, network, volumes and off you go!).

Now about docker in production. I had lots of problems with that. But if you use docker for local and don't have a ops department, it is the natural way to go. You run your integration tests with the same image that later runs on prod, so you don't need to worry, what stack is running on in a different environment. As a developer with a fully automated CI chain, I can control the entire deployment from my IDE (Dockerfile, Jenkinsfile, ...). My college can review the entire deployment in the PR (code-changes and infrastructure changes). And also docker has for most external software a ready to use image. Those are big benefits for small dev teams in small companies.

Also cloud providers offer docker tooling like a private image repository and docker support in most CI tools. I mention all of this, because the tooling around a container solution is important. You may dislike docker, but it integrates in most cloud providers and has images for almost everything.

The argument about complexity is true. If something doesn't work and you have no idea about the parts under the docker layer then its game over. But this is a very general argument against complexity. Complexity in software makes everything easy until you need to go down an abstraction layer. Nobody forces you to run your MySQL or Elasticsearch in docker container. This is definitely an unnecessary (and potentially dangerous) layer of complexity.

But to run the 10 years old PHP 5 application that needs memcached version 0.1.5, docker is very very useful: you spend a week to put all that legacy stuff in an docker image, push the image and all the team members can run it locally. Even the designer that knows a bit of jquery can run "docker-compose up" on his windows machine.

nsfyn55• 6 years ago

This might be the most short sighted article I have ever read. One of humanity's greatest achievements was the creation of the intermodel shipping container(https://en.wikipedia.org/wiki/Intermodal_container). We literally would not live in the world of convenience we have today without it.

But imagine what the curmudgeon of the day had to say about this. "Why do I need to use this specific container? This container has all these problems... and on and on"

redis_mlc• 6 years ago

The shipping container was a solution to a problem.

Kubernetes? The jury's still out on that.

dang• 6 years ago

Discussed at the time: https://news.ycombinator.com/item?id=17062288

birdyrooster• 6 years ago

Oof, this didn’t age well. Sounds like the OP didn’t want to understand the benefits of Docker at scale in a large, heterogenous corporation and has stuck their head in the sand because their uses cases didn’t need it.

hacym• 6 years ago

I have a nagging feeling THIS comment won't age well.

nojvek• 6 years ago

His arguments seem week. I’ve used both docker and k8s for couple of years now. Sure there is a learning curve but because shit is consistent and sane we’ve been able to have better uptimes, and our pages went significantly down(self healing and auto-scaling properties of k8s are a god send).

Before we used to fab-ssh into the servers, manually ask some human at softlayer to provision new servers, bash script install things, and use native package managers like pip install. Fun fact. Pip is not deterministic. Until package-lock came, npm wasn’t deterministic. Things that worked in dev and staging would end up borking prod and we’d be serving 500s. Other language package managers had similar issues.

I see docker as just a glorified package manager. Make a docker file, build an image, run the same image in prod/dev/stage for consistency.

That is a huge timesaver.

phendrenad22• 6 years ago

From what I've seen, Docker usually gets used when someone has a difficult-to-run app, usually due to many dependencies or a cryptic barely-documented jump-through-hoops-of-fire setup. So they dockerize it. Instead of trying to improve the app, they've essentially thrown up their hands in defeat and dockerized it. Which is a legitimate strategy in many cases, but too often it's the lazy way out.

phendrenad22• 6 years ago

5 years ago I dreamed that IT teams would be empowered to offer us developers a heroku-like experience. (Or JVM application server for those of you who remember those). But it seems like Kubernetes, the "new shiny", has distracted them from that goal, so now they're off in Kubernetes land reconfiguring and reconfiguring, never increasing the productivity or security of what they deliver to the rest of the company. Basically, Kubernetes has nerdsniped IT.

RandyRanderson• 6 years ago

I'm on a project that only needs a single server, and storage. Yet we have k8s, docker, 3 other needless technologies with all their ancillary requirements,Microservices and about 5 more git repos than the entirety of Google needs. Development of simple features take 5-10x of what it should be. But then I understand the developers too: recruiters and team leads urged by their developers to "work on the latest tech or we'll leave" have to adopt and so ask for ppl with those skills.

Docker is a dangerous gamble which we will regret (2018)

Related Stories