1. What’s In a Name? DevOps…er…Continuous Delivery

    © 2013 Jeff Sussna, Ingineering.IT

    I am a strong proponent of DevOps. I like to think I’ve at least been doing proto-DevOps since 2003. I still, however, struggle with the DevOps name. I observe others doing so too. On the one hand, DevOps is moving into the enterprise IT mainstream. On the other hand, I question how many of its adopters could give a concise answer when asked to articulate what DevOps is, how to do it, or why it’s beneficial.

    In the process of contemplating this problem, I found myself comparing the word “DevOps” to the word “Agile”. Admittedly, there is still plenty of confusion about what constitutes proper Agile practice. Just yesterday I saw a tweet to the effect that “just because you hold standups doesn’t mean you practice Scrum”. Ultimately, though, the answer to the question “do you do Agile?” is straightforward. If you can rapidly, accurately, and efficiently respond to constantly changing business needs, then you do Agile. In other words, if you are agile, you do Agile. If by some strange miracle, you’re accomplishing agility using waterfall, then you shouldn’t change a thing. The point is that the name describes the value. In the case of DevOps, the name describes the implementation, not the desired outcome.

    I found a clue to a possible resolution in the fact that I approach DevOps slightly differently from most people. I define it, not in terms of how IT structures itself, but rather in terms of what customers expect. Delivering software as service makes operations an explicit part of the customer value proposition. Customers view functionality and operability as inseparable aspects of service. Imagine I tell you about a new restaurant I tried. When you ask me how it was, I say “the food was great but the service was terrible”. I’ve answered a single question with two statements. You’ll use both statements to decide whether to try the restaurant for yourself.

    People often talk about DevOps and Continuous Delivery in the same breath. By refining our understanding of “delivery”, I believe we can dispense with the need to differentiate between them. Continuous Delivery typically refers to continually delivering functionality through small, frequent application releases. What the customer expects, however, is the continual delivery of functionality + operability. We implicitly acknowledge this fact by integrating security, resilience, and performance-related user stories, spikes, and tests into the continuous application deployment pipeline.

    Cutting-edge operations practices enable more continuous delivery of operability. Auto-scaling, for example, makes application performance continuously consistent as user traffic ebbs and flows. This example may seem trite, until you compare it to pre-cloud IT environments that required manual acquisition, provisioning, and configuration of physical hardware to respond to increased traffic. Automated failover architectures, circuit-breaker RPC patterns, and other resilience engineering practices make availability more continuous, both by preventing failures and by enabling faster healing. Chaos Monkeys and blameless post-mortems are about discovering and learning from failures more quickly and proactively. The “monitor all the things” meme enables continuous visibility into functional and operational behavior. That visibility feeds user stories back into the front of the Continuous Delivery pipeline.

    Even the most basic and central DevOps tenet, dissolving cultural silos between development and operations, speaks to Continuous Delivery. What is the negative impact of dev/ops silos? They degrade quality, slow down progress, and generate waste. In other words, they increase delivery time and cost, while decreasing value. If I were asked “why should we dissolve development/operations silos?”, I would answer “because it lets us deliver software service (aka functionality + operability) more continuously”. In other words, DevOps IS Continuous Delivery.

    I have found Continuous Delivery to be easy to communicate. People across the spectrum, from InfoSec engineers to Agile product owners, seem to intuitively grasp both its value and more or less what it looks like. When I talk about using Continuous Delivery to address functional and non-functional requirements, no one bats an eye. Like Agile, the Continuous Delivery moniker describes its own value. How do you know if you’re doing Continuous Delivery? If you’re delivering functionality + operability continuously, then you’re doing it. ‘nuff said.

Notes

  1. ingineering posted this