2011: Time to Escape the DevOps Echo Chamber

This is a guest post by Damon Edwards (@damonedwards)

DevOps is a hit! Everyone is talking about it! Everyone is doing it! Everyone is going to meetups and conferences! Everyone…. oh wait, EVERYONE isn’t. It just feels likes it is everyone.

Why? Because we live in the DevOps echo chamber.

Now, I’ll admit that I’m a full fledged citizen of the DevOps echo chamber. I was immediately drawn to the lightening rod that the term “DevOps” has come to represent.

I watched the early crowd gather around that DevOps lightening rod and quickly coalesce into a full-fledged movement complete with hyper-active blogging, conferences, meetups, mailing lists, rivers of tweets, and a feverent throng of self-identifying DevOps believers. Life is happy for us DevOps enthusiasts.

However, we do need to acknowledge that we are living inside an echo chamber of our own making. Most of the conversation and high-fiving is between already converted DevOps enthusiasts. Even the arguments amongst ourselves contain more agreement than disagreement.

Here at the beginning of 2011, the DevOps movement is at a crossroads. In order for any movement to flourish it needs an influx of new blood and fresh ideas. DevOps is no different.

There are far more people outside the DevOps echo chamber than there are here on the inside. There are those who have never heard of DevOps. There are those who have heard of DevOps but don’t think DevOps is relevant to them. There are those who have heard of DevOps and think it is all a terrible waste of time or just won’t work.

Crossing the Chasm

Since we are in the technology business, let’s put this in the terms of Geoffrey Moore’s “Crossing the Chasm”. The DevOps movement has done a great job attracting enthusiasts and visionaries. Now it’s time to reach out to the pragmatists, conservatives. and skeptics. It’s time for DevOps to break out of that echo chamber and cross the chasm to the mainstream.

Getting DevOps to cross the chasm won’t be easy. But just like with any product or service, the motivation for attempting to reach the other side is clear. Not making it across the chasm means either failure or a slow drift into irrelevance.

So what do we do? I don’t pretend to have all of the answers but I’ve got a few ideas that I think are in the right direction.

Step 1: Focus on the business problem

I’ve written and spoken quite a bit about this already, so I’ll be brief. Business problems are the great clarifier in IT. Our jobs exist to enable and improve some specific business.

All too often, DevOps conversations focus on our personal complaints rather than actual business problems. Just because we find something a headache or unpleasant doesn’t necessarily mean that our perceived problem matters to the business. To put it bluntly, we are paid to have those headaches. Happiness would be nice, but it’s not much of a business justification. DevOps needs a different argument if we want to be heard.

My favorite DevOps-related business problems to focus on are the inefficiencies and bottlenecks standing in the way of getting an idea from inception to where it is making the company money. If you can tell a CEO that you have a way to make their business more agile and more responsive to market conditions, you are going to have that CEO’s ear. If DevOps isn’t able to catch the CEO’s attention, it is likely going to be relegated to “something you can explore on your free time” (translation: not with our money).

Step 2: Give people a DevOps playbook to follow

People who spend their working hours in roles somewhere across the development-to-operations lifecycle tend to be extremely busy. It’s just the nature of the job. Good intentions and ephemeral ideals don’t tend to carry a lot of weight with the rank and file engineers who are just trying to keep their heads above water and the proverbial lights on. They want a methodology that gives them concrete steps and repeatable how-tos.

On our DevOps Cafe podcast, John Willis and I often discuss what we call the CAMS framework. It is by no means a comprehensive methodology, but we’ve found it to be a solid foundation for both assessing DevOps problems and classifying DevOps solutions.

CAMS stands for:

• Culture
  Always worry about the people and the process first. Culture is the root of almost all DevOps problems. If left unchecked, Culture problems will knock the legs out from under any other attempts at solving your DevOps problems. Unfortunately, culture is also one of the most difficult things to fix. You can’t change culture directly (you can only influence and incentivize behavior and hope it has the desired effect on your culture). It’s difficult to get quantitatively driven engineers to put much effort behind what they perceive to be “soft” sciences of interpersonal and group dynamics. “Kumbaya is nice and all, but I’ve got real problems to solve” is an attitude that is all too common. Unfortunately, what is usually not realized until it is too late is that those “kumbaya” cultural issues they dismissed are the root cause of those “real” problems they are suffering under.
• Automation
  Most of the DevOps conversations to date have focused on automation, so this is an area that is well covered. This isn’t that surprising considering that the automaton part of the conversation is where we get to talk about tools… and oh how technologists do love talking about tools! That being said, the most important part about the automation conversation isn’t the tools themselves, but the ideas that come with an “automation-first” DevOps outlook. Automation (from release, to testing, to deployment, to ongoing operations) isn’t something you do as an after thought to gain efficiency. Automation must be a fundamental design principle that is a first class citizen along with other requirements.
• Measurement
  Metrics, KPIs, and other forms of measurement are another topic that I rant about quite a bit. For as much DevOps talk as there is, there is surprising little on how to measure the impact of DevOps problems or their solutions. To make matters worse, there are a lot of organizations who claim to be measurement driven and hold up hundreds, if not thousands, of metrics as their proof. But when you dig a bit deeper, you’ll find that all of those metrics are about things (severs, routers, applications, etc.) and none are about the people or processes that actually are the organization.
• Sharing
  An active DevOps feedback loop provides value at multiple levels. Within an organization it can promote a culture that values sharing and learning. Between organizations it can lead to an influx of fresh ideas (not to mention raise your company’s recruiting profile). On a global level, sharing and peer review will facilitate the elevation of DevOps to a discipline worthy of study and investment. Unfortunately, it seems like too many companies who read Tim O’Reilly’s seminal “Operations: The New Secret Sauce” article took it a bit too literally. They think their operational strategies and practices are trade secrets to be closely guarded. Oddly enough, it’s the biggest companies who act this way (think: Google, Amazon, Facebook, Yahoo, etc.). Yet, as someone at DevOps Day US pointed out to the crowd, it’s ludicrous to think that executives at any of those companies don’t already know exactly what, how, and why their competitors run their operations the way they do. Fake secrecy helps no one, especially the party that couldn’t keep the secret in the first place.

Step 3: Adopt the right footwear

I’m having fun with this one. Have you noticed that Vibram Five Fingers are taking over for the once venerable Birkenstocks as the footwear of choice when you want to flex your tech street cred (especially your cloudy, ruby, node.js, nosql street cred)? Time for DevOps to make it’s own fashion statement? Ok, maybe not. Bad idea. Carry on.

About the author

Damon Edwards is a co-founder of the DTO Solutions consulting group. Damon is also a frequent contributor to the dev2ops.org blog and co-hosts the DevOps Cafe podcast.