The DevOps identity crisis

Why DevOps needs a manifesto after all, but may never get one.

Image: CC BY-SA 2.0 Libby Levi for

DevOps is everywhere! The growth and mindshare of the movement is remarkable. But if you care deeply about DevOps, you might agree with me when I say that although its moment has “arrived,” DevOps is in serious trouble. The movement is fragmented and weakly defined, and is being usurped by those who care more about short-term opportunities than the long-term viability of DevOps.

They are the ninety-nine percent, and nobody cares

How bad could it be? Travel back in time. It is mid-November 2011, and Occupy Wall Street is occupying the headlines. One of the major reasons is that the protestors are targeting shipping ports on the West Coast, causing shutdowns and even violence. As things are getting out of hand, parts of the movement start condemning these actions as counter-productive, hurting the 99% instead of the intended 1%. Spokespeople for the movement are quoted in the media as saying the instigators “don’t represent the movement.”

Why did the Occupy movement become a footnote in history so fast? There were several reasons: there was no cohesive agreement on its identity, values, goals, and mission; in an effort to be unlike “them,” the OWS proponents avoided anything that looked like centralized leadership; and it seemed to be entirely negative, advocating nothing to replace what it wanted to remove.

I believe a similar thing is happening to DevOps right now, for many of the same reasons. Let’s talk about some of these problems.

Messaging and positioning

Messaging and positioning are vital when you’re trying to promote something, because without them, nobody will understand what you’re doing, why, and why they should care. DevOps has a messaging and positioning problem, and it hurts the movement. Positioning a product or service can be done several ways, but a standard one that’s worked well for me on several occasions is filling in the blanks of the following template:

For (target customer)
Who (statement of need or opportunity)
The (product) is a (product category)
That (statement of benefit or compelling reason to buy)
Unlike (primary competitive alternative)
It is (statement of differentiation)

This is not a statement of facts, it’s a statement of how you want a target audience to perceive you. You can probably fill in the template quickly for any number of products, trends, and audiences: the iPad, texting, Breaking Bad, Spotify. Now try replacing the parenthesized phrases for DevOps. If you are like me, you’ll find it difficult, especially when you get to the last line.

DevOps can be forgotten as quickly as it arose

What’s unique about DevOps?

The last line of the positioning statement is about differentiation, and it’s foundational. Messaging and positioning isn’t enough. You also need something unique and compelling to message and position — something others can’t say.

What does DevOps offer that’s unique? This is likely to be a real struggle, no matter what you think of DevOps.

  • Breaking down silos? Read some of Patrick Lencioni’s books.
  • Continuous learning, creating learning organizations? Pick up a copy of Peter Senge’s The Fifth Discipline.
  • Aligning IT with business objectives? This is covered by a lot of management gurus, like Peter Drucker.
  • Reducing variability in processes? Read The Goal, or learn about Six Sigma.

And on and on it goes. This is a vitally important question: is DevOps just old wine in a new skin? What, exactly, does it advance over previous practices? I am unable to find anything in anyone’s definition of DevOps that isn’t a restatement of an established idea or practice. I think this is a serious challenge. It means that DevOps can be forgotten as quickly as it arose — perhaps replaced by another movement that’s similar but has stronger messaging, positioning, and unique value propositions.

The echo chambers

For a movement that talks about breaking down silos, DevOps can be pretty cliquey.

If you’re selling a “DevOps tool,” for example, there’s a passionate community of people who object that DevOps isn’t tools, isn’t purchasable, isn’t something you can take off the shelf and unwrap. Of course, there are companies who are looking for just that, others who are selling it to them, and the results are quite good by some accounts. But sometimes people seem unwilling to listen to DevOps success stories when they disagree with how DevOps is presented in the story.

Similarly, those who say that enterprises need to do DevOps differently from smaller organizations might be trying to sell an exclusive “enterprise” flavor of DevOps. This is an old trick for management consultants — brand your process/framework/methodology. Boy, does this get some hackles up fast! But why should it? It’s just using messaging and positioning to create a unique value proposition, or the perception of one — something the objectors have not succeeded in doing themselves.

Of course, those who care most are often those with the most at stake. For example, if DevOps is defined as “developers understanding and caring about the impact of their code in production,” it isn’t surprising that the people who are responsible for production systems are happy with the outcome, and sometimes the developers are not as interested. It makes a difference for the sysadmin’s life, but not necessarily for the developer’s. When a sysadmin rails against a developer’s “wrong” ideas about DevOps, therefore, it can be a turn-off. Likewise, a very senior person with lots of experience in formal practices can get irritated when they’re criticized by a younger person who’s never even heard of those disciplines.

My experience is that this all adds up to create echo chambers — groups of people who insist on particular meanings for DevOps, and get strident when others hold different views.

I can understand why people fear the reversal of a cultural shift that’s benefited them. But I think it’s important to understand that the rise of factions was predictable and unavoidable, due to the lack of definition and agreement about what that change was in the first place, and why it was a good thing. This might be a good thing, because it might show how to solve these problems.

Where to go from here

Hopefully I’ve convinced you there’s a problem. Nobody agrees on what DevOps means — except within its echo chambers. The name is vague. The tenets are unoriginal. There’s no cohesive leadership or central personality who can address these problems, so it’s a free-for-all, with companies and individuals using it in obviously self-serving ways. That’s why I say DevOps has an identity crisis.

I’d suggest that, as contrary to DevOps as this might sound, we really need messaging and positioning that we can stand behind. And then we need to be public about it. As one of the characters in the popular DevOps book The Phoenix Project said, “messiahs are good, but scripture is better.” This means that some people need to assert themselves: “We are the ones who created DevOps, our definition is authoritative, and we’ve signed our names to the manifesto. If you want it to be something else, call it by a different name.”

The problem, though, is that DevOps’s only manifesto is “no manifestos.” But nature abhors a vacuum, and without a manifesto, everyone’s going to supply their own. This is clearly what has happened: the Four Pillars, the Three Ways, and so on. There are literally dozens of definitions of DevOps, depending on whom you ask. In The Phoenix Project, there are even references to The DevOps Cookbook, a definition in the form of a book that doesn’t exist!

What can it hurt to create at least a simple website that we all agree represents the core of the DevOps philosophy?

Is it time to rethink the “no manifestos” mandate? What can it hurt to create at least a simple website that we all agree represents the core of the DevOps philosophy? Something worthy of being the first reference from the Wikipedia article, in place of the hodgepodge of bits and pieces referenced there today? You have to start somewhere.

For my part, although I have expressed some concerns and reservations here, I enjoy the conversations and company of people who are interested in DevOps of many flavors. I try to adhere to the philosophy of “take what you like and leave the rest.” This works for me, but I do wish for a more tangible wheel to which I can put my shoulder. I hope that this article is a step toward that in some way, and I look forward to many more conversations online, in-person, and at events such as DevOpsDays, Velocity, and O’Reilly’s upcoming Software Architecture Conference.

Many thanks to various people at O’Reilly, Dave Zwieback, Nathen Harvey, Bridget Kromhout, Mandi Walls, and Anna Navatsyk for helping with this article directly, and numerous others for helping indirectly.

Editor’s note: This is part of our ongoing exploration of the meaning of DevOps and how community plays a crucial role in its definition.

Cropped R + L illustration CC BY-SA 2.0 Libby Levi for

tags: , , , , , , ,

Get the O’Reilly Web Ops and Performance Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • supert0nes

    Total opinion from an administrator/java developer.

    The entire stack seems to be moving to a higher level. With http and web pages acting as the glue.

    The developer will build the entire Docker style image. It will turn into code in a repository. Devops will be a small sliver to help the developer code the image. Then the only thing left is security and networking. Probably better handled by a security person and network engineer. So we’re back to managers, developers and system administrators.

    Chef and its weird terms never seemed very appealing to me, and it’s the most popular of the devops tools.

    • Gggeek

      And I thought devops was all about NOT delegating to security and networking engineers….

      Four comments in, and the op proved his point :-)

      As for the chefocker/puppagrant thing: i am not sure if this fixation with tools comes more naturally from the devs or the ops side of the fence. Maybe all geeks have a natural love for toys and dislike for broad-spectrum thinking. But I was revently in a huge devops meetup, where i met dozens of ops, a few devs and not one pm or analyst.
      And I was a bit underwhelmed at observing how the sysadmins only thought of devops as tools to solve their current problems, and not about looling at th problems fom a different angle or altogether diffetent problem set.

  • Is this trolling? On O’Reilly? Certainly reads like a troll. Effectively: “Let’s centralise and monopolise the understanding and definition of DevOps”. Poorly conceived ‘solution’ to what is arguably not really a problem.

    • JP Morgenthal

      Matthew, I find your response unprofessional and appalling. Here an individual has put forth their opinion in a well thought-out treatise and your response is to belittle it? You represent what is wrong with this DevOps movement and why executives don’t take it seriously but simply the pandering and whining of sysadmins and developers. Has the author been derogatory to you or anyone? Where is he attempting to be inflammatory? How about looking up the meaning of trolling? You would find that its an abuse to use it against people with who you disagree versus those actually attempting to derail and intelligent discussion.

      • “You represent what is wrong with this DevOps movement” – really? Perhaps you’d care to look at what I have contributed the movement since 2010 before deciding to “belittle” my comment. The idea that the definition of DevOps needs to be centralised and monopolised is what I’d call “what is wrong with DevOps” – a desire for it to be owned by a few.

        • As corny as something like the The Reactive Manifesto is, it’s a least clear what the communities criteria is for something to be considered “reactive.” DevOps is rapidly falling into the Agile camp where companies and managers think they can buy something like JIRA with GreenHopper and, huzzah, they’re Agile. The big thing that everyone misses is that Agile is a culture, not a thing you can buy.

          CA is practically trying to make similar moves with their products. This is effectively making Ops teams think that they’ve achieved DevOps, but it’s really just enhanced ClickOps. From where I’m sitting, I’m watching the vendors take DevOps by the horns and defining it to suite their needs, and it’s working to various degrees. I find it troubling since I’m not super excited about more centralized tools being brought in under the banner of DevOps.

  • Jelmer Kuperus

    Devops for many people has become synonymous with this puppet / chef nonsense and that stuff desperately needs to die.

    Docker I kind of dig

  • SilentLennie

    If you want to write something: try writing down best practices instead of a manifesto.

  • JP Morgenthal

    Fundamentally, I agree with your article. But, this discussion has been played out multiple times over the course of the past few years. Here’s a blog I wrote on it back in Oct: There was even some agreement among myself, Jeff Sussna and Mike Kavis that putting down some definitive best practices might help alleviate some of the argument. Frankly, one of the more concerning aspects of your article is the reality that it can dissipate as quickly as it has arisen if it does not tie itself to anchor that everyone can align behind.

    That said, one thing DevOps has accomplished in spite of all the ambiguity is getting people in IT to realize “we ain’t doing it as good as we could be” and that all those standards and processes and politics have done nothing but slow down our ability to deliver what the business wants as quickly as it can be delivered given the technical challenges to doing so.

    So, if DevOps does morph into other activities or groups, I believe that this understanding will follow. And, hopefully, that will become the beacon that finally drives the very needed transformation that has been 50 years in the making.

    • Well said. Another way to perhaps get rid of the ambiguity problem is to truly treat DevOps as an IT initiative and not just an initiative to more effectively deliver code.

      Operations, infrastructure and solution design teams need to be introduced to the same culture and tool sets that development teams are adopting. They need to be able to think about creating products and delivering services that can be delivered on demand to developers, application owners and business units.

      If managers and executives are treating DevOps purely as a methodology and a toolkit to deliver code, there is a great chance that they will overlook all of the groundwork that needs to be done within the infrastructure teams. Especially if application development and infrastructure operations departments governed by different executives.

      • sophia

        Hi. I am on an infrastructure team, and we all operate in silos. This silo approach worked very well many, many years ago but it has not been adaptive enough to change with the course of time. I feel as though I am working in the dark ages where my coworkers stance is one of ” IT drives business; i.e. don’t tell me what you need. I will tell you what you can have.”. Unfortunately this is not a page from a DevOps story book, this is what exists in my world today, right now. If there is a support group out there, please let me know because I am close to needing one :). And yes, IT group is split between different executives.

        I struggle a lot in my day to day because I am often faced with many obstacles when I am tasked with an IT service that has a requirement to provide additional functionality. I do get frustrated on occasions when various silos ties everything up with their “processes”. To these silos, I refer to them as GODS .. and there are alot of GODS within this infrastructure team; DBA, Unix, Network, Security. Yes we spend a lot of time arguing.. it takes an average of 3 meetings to sort of agree on something. Yes I have been yelled at and I don’t think it is fair because I am doing my best as an IT professional to enable my customer with an IT service I support. I do wake up feeling as though I don’t belong in this infrastructure group because it is pretty clear we are not on the same wave lengths or is operating at the same speed.

        Operationally, I am tired of being blind sided by work from various teams and being the one blamed for outages that my team had nothing to do with – incident reports only have one sentence in the resolution field. Web server restarted. I have tolerated enough production promotions where things have gone far south and being asked what did you guys elevate?

        I do embrace the vision where we are all on the same page; operations, infrastructure, app dev, and solutions architects. I want us to all understand each other and to have a common goal as a ‘united’ team. Our “manifesto” will be unique to us and it will and may not be the right one for the IT company at the opposite end of the street.

        To try and figure out what this IT initiative will mean to us, I want to hear what everyone thinks. I am not going to give up and jump ship. There is hope and I do not want to give up. I think that we can embrace DevOps however will all the silos want it? We can not change if we do not recognize that we need to change.

        • Your comment made tears come to my eyes as I recognized similarities to what I’ve lived myself. Thank you for sharing your experiences.

  • devops_gal
  • david morris

    Same happened to agile. 4 bullet points in the beginning, then the manifesto with 12 points. Somehow this became Scrum and all the backlog and velocity crap got introduced in order to 1) make it enterprise friendly 2) allow them to reduce people and their output to a number in a spreadsheet. Do you work in a big organisation doing “Agile”? There’s very little talked about:

    Build projects around motivated individuals.
    Give them the environment and support they need,
    and trust them to get the job done.

    in those orgs in my experience.

    Kind of reminds me of the Cathars in medieval times. They were a reaction to the organised and firmly rooted establishment of the day. Catharism meant different things in different areas. Not heavy on doctrine and so on. I Get the impression that life was good if you were a cathar (think small startup) or a least better than if you weren’t (think global consultancy). Then the Pope found out about their outrageous ideas (crazy stuff like women priests!) and exterminated them pretty much to a man woman and child.

    • David, I think the agile comparison is a really good one. Regardless of the label (or the positioning), the DevOps genie has been let out of the bottle. The agile movement “fractured” for many of the same reasons outlined in this article. Seems to me the early agilists where every bit as determined to protect the agile brand and we see where that got them.

      While emotionally threatening to the earliest DevOps advocates, these inevitable factions will only increase the overall adoption and momentum (as with agile). What matters is the fundamental principles and their ability to generate tangible results, not the nuanced characteristics promoted by any individual DevOps clique.

      Way to much progress has been made…DevOps extends the power of agile and is here to stay. As with agile, fragmentation will not kill DevOps – it will ensure it’s evolution.

  • Morgan Adams

    I guarantee the existence of DevOps is not dependent on a manifesto, small website, or other means of stating clearly what DevOps is. The movement is already engraved in the technology sector. There are multiple conferences, stockpiles of tools, business, and leaders who are breaking down the wall between development and operations and streamlining development. It seems to me that the tech world has heard the rallying cry to fix things and they didn’t need a manifesto to tell them what to do.