There’s a discussion on the devops Google group about how people are increasingly defining DevOps as “chef and/or puppet users” and that all DevOps is, is using one of these tools. This is both incorrect and ignorant.

Chef and puppet are individual tools that you can use to implement specific parts of an overall DevOps strategy if you want to use them – but that’s it. They are fine tools, but do not “solve DevOps” for you, nor are they even the only correct thing to do within their provisioning niche. (One recent poster got raked over the coals for insisting that he wanted to do things a different way than use these tools…)

This confusion isn’t unexpected, people often don’t want to think too deeply about a new idea and just want the silver bullet. Let’s take a relevant analogy.

Agile. I see a lot of people implement Scrum blindly with no real understanding of anything in the Agile Manifesto, and then religiously defend every one of Scrum’s default implementation details regardless of its suitability to their environment. Although that’s better than those that even half ass it more and just say “we’ve gone to our devs coding in sprints now, we must be agile, woot!” Of course they didn’t set up any of the guard rails, and use it as an exclude to eliminate architecture, design, and project planning, and are confused when colossal failure results.

DevOps. “You must use chef or puppet, that is DevOps, now let’s spend the rest of our time fighting over which is better!” That’s really equivalent to the lowest level of sophistication there in Agile. It’s human nature, there are people that can’t/don’t want to engage in higher order thought about problems, they want to grab and go. I kinda wish we could come up with a little bit more of a playbook, like Scrum is for Agile, where at least someone who doesn’t like to think will have a little more guidance about what a bundle of best practices *might* look like, at least it gives hints about what to do outside the world of yum repos. Maybe Gene Kim/John Willis/etc’s new DevOps Cookbook coming out soon(?) will help with that.

My own personal stab at “What is DevOps” tries to divide up principles, methods, and practices and uses agile as the analogy to show how you have to treat it. Understand the principles, establish a method, choose practices. If you start by grabbing a single practice, it might make something better – but it also might make something worse.

Back at NI, the UNIX group established cfengine management of our Web boxes. But they didn’t want us, the Web Ops group, to use it, on the grounds that it would be work and a hassle. But then if we installed software that needed, say, an init script (or really anything outside of /opt) they would freak out because their lovely configurations were out of sync and yell at us. Our response was of course “these servers are here to, you know, run software, not just happily hum along in silence.” Automation tools can make things much worse, not just better.

At this week’s Agile Austin DevOps SIG, we had ~30 folks doing openspaces, and I saw some of this. “I have this problem.” “You can do that in chef or puppet!” “Really?” “Well… I mean, you could implement it yourself… Kinda using data bags or something…” “So when you say I can implement it in chef, you’re saying that in the same sense as ‘I could implement it in Java?'” “Uh… yeah.” “Thanks kid, you’ve been a big help.”

If someone has a systems problem, and you say that the answer to that problem is “chef” or “puppet,” you understand neither the problem nor the tools. It’s “when you have a hammer, everything looks like a nail – and beyond that, every part of a construction job should be solved by nailing shit together.”

We also do need to circle back up and do a better job of defining DevOps. We backed off that early on, and as a result we have people as notable as Adrian Cockroft saying “What’s DevOps? I see a bunch of conflicting blog posts, whatever, I’ll coin my own *Ops term.” That’s on us for not getting our act together. I have yet to see a good concise DevOps definition that is unique if you remove the word DevOps and insert something else (“DevOps helps you bring value to software! DevOps is about delivering a service to a customer!” s/DevOps/100 other things/).

At DevOpsDays, some folks contended that some folks “get” DevOps and others don’t and we should leave them to their shame and just do our work. But I feel like we have some responsibility to the industry in general, so it’s not just “the elite people doing the elite things.” But everyone agreed the tool focus is getting too much – John Willis even proposed a moratorium on chef/puppet/tooling talks at DevOpsDays Mountain View because people are deviating from the real point of DevOps in favor of the knickknacks too much.

7 responses to “DevOps: It’s Not Chef And Puppet”

You make too much sense sometimes 😉 It’s funny that when I talked about the monitoring landscape being so shitty, I used the same language:

“You can just combine Nagios + collectd + graphite + cacti + pnp4nagios and you have everything you need!”

I shouted that down as an anti-pattern but I think it’s a bit different in the CM space right now. I said this on the tweets just the other day:

“You know why people suggest chef, puppet or cfengine? Because outside of bespoke CM they’re the only tools with appreciable user bases.”

I stand by that statement. Monitoring is an easier nut to crack than CM. I agree that the current crop of tools don’t meet all the needs but they’re a damn site better than trying to roll your own at this point UNLESS you have expertise to do so. Netflix, NI, Google – they can afford (for multiple values of afford) to build it. Most other people can’t.

Most shops do not have the same needs and the existing tools CAN do the job with very little friction. You’ll also be able to get some actual HELP with it because they have large user communities.

People (me included) like to present their problems as something unique when, in fact, they’re pretty common needs. They’re mostly the same problems viewed through different glasses. If you step back you can see the pattern and you’ll realize that, yes, I *COULD* do this in Puppet or Chef or CFEngine and I *DON’T* need to go hand-roll an artisan loaf of bread to solve it.

The discussion on tooling right now does frequently lend itself to Puppet/Chef (with a side of CFEngine) because right now most people are in an immature place in the lifecycle. When you don’t have ANY tooling in place, those are better places to start.

Long story short, telling people to roll their own or cobble together something with a bunch of shell scripts gets them no closer to a workable solution than if they had just given an existing tool a shot.

Also, you need to make a call to the old NI crew and tell them to open up PIE 😉

Not knocking chef and puppet, just saying that they only solve part of the CM puzzle, CM is only 1/10 of the overall ops/devops picture, and implementing any tooling without understanding the larger culture, collaboration, and design issues can be a waste of time.

And we (quietly) announced the open sourcing of PIE at DevOpsDays Austin; Bill is still getting stuff up onto github (NI legal is making us tear out anything GPL) but put a watch on https://github.com/PIEFramework/PIE.

With the caveat that PIE also doesn’t help you if you don’t know what you’re doing or need to do.

Completely agree. I’m a big puppet fan, but DevOps is about sysadmins working hand-in-hand with developers. Sitting across the desk from each other, yelling at each other, and finally understanding each other. When that *clicks*, you’ve got the first ingredient for success.

Cfengine, capistrano, puppet or chef are tools that muddy up the DevOps waters. DevOps is about trust and communication first and foremost.

I’m a bit late to the party here but thought I’d add my 2c. Despite being a vendor myself claiming that a tool is a “DevOps” tool is pretty dangerous. I wrote about it here when I asked if they even exist: