[ Content | View menu ]

What is a DevOp?

Mark Mzyk | June 22, 2013

What is a grit, anyways?

Vinny, My Cousin Vinny

More and more there are job posting that are looking for a DevOps engineer. In response to this a series of blog posts have appeared bemoaning the fact that there should be no such thing as a DevOps engineer because DevOps is a cultural movement. It’s a movement about cooperation between development, operations, and the rest of the business. So how did seemingly smart people decide they need to hire a DevOps engineer?

When the agile movement started there wasn’t a corresponding spike in job postings looking for agile engineers. It was understood that agile was a cultural movement. It wasn’t until later that systems came along that tried to codify practices that good agile shops did (Scrum, etc) and then we started seeing job postings for scrum masters and other related positions. Perhaps it was clear that the agile movement was a cultural movement because it started with a manifesto. DevOps has no corresponding manifesto.

It’s worthwhile to consider where DevOps started. While DevOps doesn’t have a single genesis, it seems widely agreed upon that it really came to light with John Allspaw’s and Paul Hammond’s 2009 presentation on developer and operations cooperation. The presentation is clearly a cultural presentation, at least when viewed in hindsight. While I wasn’t paying attention to the presentation when it came out, based on what I’ve heard the main take away was Flickr doing ten deploys a day. At the time that was amazing. And while it was a culture that enabled this, the was also a lot of technical practices in the presentation. Perhaps highlighting ten deploys a day in the title was a mistake. It made it easy to focus on the technical and miss how important the cultural aspect was.

Further confounding the problem is that good DevOp shops are most easily recognized by the tools and technical practices they follow. They use configuration management (Chef, Puppet, etc), they do continuous deployment, etc. While these tools are part of a larger culture they are the easiest thing to recognize about DevOps. Therefore, if you want to implement DevOps it’s easy to make the mistake of thinking that you need a DevOps engineer to implement these tools and miss the larger cultural shift that is also needed.

Going back to the comparison with the agile movement, when trying to find a good agile shop one is looking for the culture. Do they use short iterations, do they avoid heavy documentation unless necessary, etc. I’m not saying there isn’t plenty of argument over what makes a place agile, but we can agree that the argument is over cultural practices. Now look at DevOps. We say DevOps is a cultural movement, but then we look at the practices that define a good DevOps shop and we largely talk about the tools, software, and technical implementations that are used.

Is this a perfect break down? No. Certainly there is a conversation going on about the cultural side of DevOps. See Allspaw’s continued conversation around blameless post mortems, as well as Gene Kim’s book (along with co-authors Kevin Behr and George Spafford) The Phoenix Project which links DevOps to the work of Goldratt and shows how DevOps fits into the wider business culture. However, cultural change is hard. If given a choice between changing culture and changing some technical practices, it’s easier to change the technical practices.

Hence the rise of the DevOps engineer job posting. It’s a sign that the wider and more important cultural aspects of DevOps are being missed. It’s also a sign that those of us who are on the front lines of the DevOps movement are doing a poor job communicating it. We’ve muddled the message. Can we change this now? No, but neither should we try. Both the cultural and technical aspects of DevOps are important and we should be glad that businesses are trying to implement them, even if they don’t fully understand the entire picture. We can see from how the agile movement has developed that change like this is messy. As much as we as engineers would like it to be bug free, that simply isn’t going to happen.

What we can do is continue to preach the virtues of DevOps, both the cultural and the technical aspects of it, but we should highlight how the technical aspects fit within the larger culture. Highlight that while continuous delivery is good, it can’t reach it’s full potentially without the cooperation that DevOps advocates.

I am sure the day is coming when DevOps will get its first set of defined practices similar to how Scrum defined a set of practices for being agile. It’s inevitable, it will happen. Please write blog posts and bitch about it when it does. But also rejoice, because it will mean the flag has been raised and DevOps will have won the battle for minds, even if means the battle of how to implement it will continue. Then we can turn our attention to the next movement and start this same argument all over again, because culture never ends.