[ Content | View menu ]

DevOps is an Answer to Changing Times

Mark Mzyk August 11, 2014

 You get rid of the artificial barriers, and in operations you get rid of the stove-piped fiefdoms of the storage guys and network guys and the database guys and sysadmins. So you have to kind of mash this stuff back together again to make it efficient, and that’s to make the speed of delivery efficient. They got siloed for optimizing for cost rather than for speed. So this is kind of a cost-versus-speed thing. And the pendulum is swinging back away from cost to speed. Because the cost of infrastructure is so low that now the time it takes to develop something is the biggest problem, so you’ve got to speed things up. So that is causing people to think about things in different ways, and different products are appearing, and the scale that people are dealing with things, and the “software eating the world” kind of ideas where every company now has to be a software company.

— Adrian Cockcroft, in an interview with The New Stack

Optimizing for speed vs. cost, a perfect distillation of DevOps. As hardware has become cheaper, building org structure around it no longer makes sense. The optimizations should no longer be around hardware, but around people.

Organizing people by expertise was the right idea when hardware was expensive. Conditions change, so it’s time for a new way of organizing, which focuses on new costs and new efficiencies. It’s a parallel situation to waterfall vs agile development. Waterfall isn’t wrong. It made great sense when computers were expensive and difficult to procure. Once computers became ubiquitous and cheap waterfall no longer made sense. Agile development was an answer to a changing landscape. So too DevOps is an answer to a changing landscape.

Don’t tell someone who isn’t convinced that they are wrong for not choosing DevOps. Instead show them how things have changed and why the proper response is a new method of organizing and working.

Why Hiring a DevOps Engineer is Okay

Mark Mzyk July 6, 2013

DevOps engineer is shorthand. It signals that a company is looking for an engineer who understands DevOps practices, such as continuous delivery and configuration management. It says that the company is looking for someone who has knowledge about development and operations. The company is looking for someone who can bring the two sides together. It’s a convenient way of saying all of this in two words.

It’s no different than when companies look for a full stack engineer. We ridicule the notion because we know the stack is so large that no one can know it all, but we’re missing the point. Companies aren’t looking for someone who knows every detail of the stack. They are signaling that they are looking for a generalist. Someone who understands how all the pieces of the stack fit together and has the knowledge to know when they should ask a specialist. A full stack engineer doesn’t know the full stack, but they know enough to recognize potential problems across boundaries and to seek help if needed.

Is every company that is seeking a DevOps or full stack engineer using these words in this way? No. Some companies probably really do believe that all they need to do is hire a DevOps engineer and then the magic of DevOps will descend upon them. It’s your responsibility as a job applicant to screen those companies out. DevOps Engineer is a convenient shorthand that is here to stay. It would be nice if companies said what they meant and didn’t use shorthand, but that’s an even harder change than spreading DevOps.

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.