[NOTE TO READER: Where 'Chef' is used below, you could substitute others, such as Ansible, Puppet, Salt...not that I would. We're a Chef shop, because we think it's the best in this category, by a long shot.]


A very short few years ago Chef and it's awesome community turned enterprise IT on it's head.

Configuration Management (Infrastructure as Code)

"You don't get to gum up the works, Mr Ops Engineer. You still get to do your job, but you do it as code."   
Consistent, repeatable, testable, deployment environments instantly became the norm. The enterprise will never go back. And, hopefully we don't get distracted...

Enter: Linux Containers

Oh wait, the first big distraction has emerged - the linux container. Density and scalability has never been this easy. Oh - we even have our own Chef like image creation facility!  So now you get the benefits of Chef, but also the benefits of density and easy instantaneous scaling. And no Chef!

Summarizing benefits of Docker, for emphasis:

  1. DENSITY and SCALING using linux containers
  2. Configuration management - infrastructure as code.

Docker has made it clear that it not only wants the container piece of the market, but also the configuration management piece. Visit a container meetup. "No more Chef!" is the new, loud mantra. Freedom from those Chef shackles!

Chef's Initial Reaction:

"It's no good, this container thing. People want configurable servers."  So says Chef. Or at least, that's how I parse their initial reaction.

You might point out that this is close to the truth, but not *exactly* correct. People want *configured* servers. How they got configured is the whole point - no one wants to care about that. That is Chef's entire story - to manage infrastructure. People just want servers to be properly configured from code, however accomplished.

You can't blame Chef for this initial reaction against Docker, but it won't last. Just because Docker conflates containers with infrastructure as code doesn't mean that Chef has to follow suit and conflate containers with infrastructure as code from a container vendor. And it won't - not long term.

When humans conflate multiple issues in a single message, confusion is easy to understand. Chef may be slow on the uptake, but eventually they'll still be the best game in town for infrastructure as code - even in containers.

Stay with me here...no, really.

Where will Chef go with Containers?

First, a question:

Docker creates and runs images, therefore use Docker to create images. Is that right?

Here's my prediction: Chef will not cede this territory. Chef will promote itself as the source of container images, not Docker. One tool: Chef. One license. Many deployment options.

  • Chef - to the OS
  • Chef - straight to metal
  • Chef - to the VM
  • Chef - to cloud deployments
  • Chef - container images

I'm all about Docker - great API for running containers. Not as a source for my container images. Leave that to configuration pros. You're out of your league here, Docker. My 2c. Look no further than the evidence to date.

A Better Container Image.

If it's 2015 and you just want to get a fast prototype working, nothing beats Docker. With all the simpicity of an AUTOEXEC.BAT file, you get a big fat prototype container with more junk than you'll ever be able to understand or control. But it works.

Quality? That's a completely different issue. Watch this coreOS guy show how a *real* quality container might be built - if you've got an hour to watch. You don't want this kind of job done by Docker, and you probably don't want to rely on containers in the Docker registry for your enterprise containers. Great for prototyping in this early period, not so great for a fortune 500 XYZ corporation  in it's container execution environment.

This is tailor made job for the likes of Chef. Early adopters will use Docker to create images. 2017 and 2020 enterprise deployments? Not so much.