

A Tale of Two Onboardings: Why engineering managers should care about Docker - mwmanning
https://medium.com/@mattmanning/a-tale-of-two-onboardings-956dbdc15002

======
poulsbohemian
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.

~~~
fragmede
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.

