A Tale of Two Onboardings: Why engineering managers should care about Docker | Hacker News Reader

A Tale of Two Onboardings: Why engineering managers should care about Docker

medium.com

7 pointsmwmanning3 comments

Remember the old joke about how everything in software can be fixed by another layer of abstraction, except too many layers of abstraction? Docker in a dev setting is just adding another layer of abstraction without solving the underlying problems.

We recently experienced exactly the scenario described in the article when on boarding our team with a customer. At first it looks slick to be up and running so fast. The problem is, you still have to keep that Dockerfile updated correctly so you'd better understand your dependencies. You still have to have redis, postgresql, and whatever other system dependencies installed. The moment you need to update your application that causes a need to update your docker images means that a 30 second fix just turned into a bigger administrative deal.

Want to use containers in production? Go for it, have fun. Do I think you need better dependency management and a clear way to keep developer environments in sync? Absolutely. I'm just not yet convinced Docker itself is adding anything to that problem.

The linked article reads like the first draft of Docker marketing copy, but Docker introduces Dockerfiles which shift your thinking in a way that Puppet or Chef failed to do. Of course, Docker, and thus Dockerfiles are still in their infancy, and don't magically maintain themselves but they're still enough of a step forwards to drive adoption.

Docker's currently burning resources trying to force Docker into production before it's ready, because that's where they see a market, and thus where they can make money. It's really not that hard to take a docker container/image and turn it into a bootable disk image to be used on your VM host though.

I'd prefer they spend their time making Dockerfiles more useful, but Dockerfiles are a win where Puppet and Chef failed me.

It's not necessary to have redis, postgresql, and other system dependencies installed for local development. Thats the whole point of the post and of containerization.

Yes, it is another layer of abstraction, but all of that stuff (OS, language dependencies, etc) needs to be maintained anyway, so you might as well have a single file to describe it all. Even better if there are automation tools like Docker to automate all of the infrastructure for you.

Reply on news.ycombinator.com