It seems that everyone in IT these days is talking about DevOps. From conferences, to articles and books, the term has taken the IT world by storm. The buzz is understandable, as many IT groups are looking for a way out of the morass of delayed projects, questionable quality and missed deliveries in which they often find themselves.
It’s clear that DevOps has the potential to address the many challenges that IT faces. Organizations that have embraced it – including companies such as Etsy, Netflix, Target, Walmart, Amazon and Facebook1 -- have shown that DevOps principles can lead to competitive differentiation by enabling teams to deliver higher quality software, faster. As a result, it’s not a stretch to say that it is becoming the industry standard for software development.
With all this excitement, though, comes a sneaking suspicion that not everyone is talking about the same thing when they talk about DevOps. This suspicion is reinforced by CTOs who claim they are “doing” DevOps or vendors selling tools that magically enable you to “do” DevOps. It can be helpful to reconcile the many interpretations of it that muddy the water and potentially inhibit adoption.
Since the earliest days of DevOps, debates about what it is have existed. Fortunately, over the past few years there appears to be a growing consensus.
So What is DevOps, Really?
To clearly understand what it is, it helps to understand what it is not. It is not a methodology or process, nor is it a single tool or technology. In fact, it cannot even be tightly defined as being strictly about development and operations, though its foundations are clearly there. And, although many of the organizations well-known for their success with DevOps are Software as a Service (SaaS) companies, it is certainly not only for SaaS applications. Lastly, it is most definitely not something you “do.”
Recent consensus on what DevOps is centers on the idea that it is primarily about culture. The DevOps culture is based on a set of principles an organization initially aspires and ultimately adheres to. Organizations that have adopted this culture value collaboration, experimentation and learning. In a DevOps culture, all participants in the software delivery lifecycle (not just development and operations) align around a shared goal: the rapid delivery of stable, high-quality software from concept to customer. Since it is a cultural thing, technically it does not require automation. However, automation of software development, testing and deployment through continuous delivery is widely recognized as a key enabler. Automation enables organizations to deliver software more quickly while ensuring operations can have confidence in what is being deployed, and customers get the quality, security and stability they require.
The DevOps Trinity
A lens for viewing DevOps culture in a simplified form focuses on it as being about gaining alignment between all software development lifecycle participants on three planes – people, process, and tools – or what we can think of as the DevOps trinity.
In practice, misunderstandings on what DevOps is or shortcuts taken in a rush to implement it often result in an organization attempting a DevOps transformation without considering all three components of the trinity. Failure to respect all components almost always leads to failure and unmet expectations.
For example, consider an organization that dismisses cultural change as a requirement. Seeking to accelerate the delivery of higher quality software, this team approaches DevOps as a tools and technology challenge. The organization makes a significant investment in automated tools for testing, but neglects to institute a cultural focus on quality first. Without the cultural focus on quality, teams go through the motions, but don’t actively take steps to ensure quality constantly and consistently. Important aspects of quality include setting effective quality goals, implementing the appropriate levels of automation or collaborating across silos to correct problems early and quickly. Without a focus on these aspects of quality, an organization is unlikely to see improvements in quality or reductions in defects. Instead, they find they can deliver more quickly, but at the cost of decreased quality and more firefighting when defects inevitably arise.
Conversely, an organization fully committed to cultural change but unwilling or unable to adopt agile methods and automated tools will find that the cultural change is simply too difficult to sustain in practice; with manual steps, a heavyweight process, and ill-fitting, cumbersome legacy tools still in place, the expectations for faster delivery go unmet and the transformation is eventually abandoned as a failed initiative.
Framing DevOps
So far we’ve talked about DevOps in terms of a culture based on certain principles and in terms of the trinity of people, process and tools. The truth is that there are several models for defining and describing it, and all of them can lead to a deeper, fuller understanding as well as a smoother implementation. One good example is the Three Ways of DevOps described by Gene Kim and his co-authors in their insightful book The Phoenix Project . Of course, these ways – systems thinking, amplification of feedback loops and a culture of continual experimentation and learning – overlap significantly with the principles outlined earlier. Another good example is the CAMS model , which overlaps similarly with its focus on culture, automation, management and sharing.
Returning to the idea of the trinity, there is one more way to frame DevOps that resonates with many in IT. In this framework, the software development lifecycle is viewed as having upstream (development) and downstream (operations) halves. The two halves are part of the same software delivery process but in many non-DevOps IT organizations these halves are highly disconnected (Figure 1).
Figure 1. The disconnect between upstream and downstream people, process and tools.
Upstream, the development culture usually prioritizes speed and innovation, whereas downstream the operations culture is tasked with a focus on maintaining quality, stability and uptime. Upstream, development uses point tools to define and build software using agile methods. Downstream, enterprise class tools are the norm for managing the test, release, deployment and operation of the software. Downstream meetings are much more likely to be filled with talk of Information Technology Infrastructure Library (ITIL) and Project Management Body of Knowledge (PMBOK) than Kanban and the latest scrum. DevOps is about connecting these worlds and eliminating the chasm that exists between the upstream and the downstream.
A Look at the "How" of DevOps
With a better understanding of what the DevOps state looks like, the next question for an organization is, “How do we get there?” It’s a deep question about which numerous full-length articles and entire books have been written. The steps needed to change a culture are not easily summarized and much depends on the organization making the transition. There are however, a few steps any organization can take to begin paving the way. You cannot “do” DevOps, but you can, to start with, do agile development with continuous integration (CI) upstream. Similarly, you can do continuous delivery (CD) downstream. Success with CI and CD depends heavily on automation, because automation not only saves time but it also reduces defects, increases consistency and enables self-service. By automating CI and CD and encouraging open communication and collaboration, organizations begin to span the chasm that separates the upstream from the downstream and establish the foundation for a DevOps transformation.
Figure 2. Agile methods, CI and CD provide the foundation for a DevOps transformation.
Often, discussions on the how of DevOps are too narrowly focused on the technical core of what happens from the time developers commit code to the time software is deployed to a server. But in reality, it’s just as important to ensure the customer’s needs are understood. And from there, to have a plan to define a solution, a plan to deliver it and a plan to support it once it moves into operation. The entire feedback loop spans more than just Dev and Ops, and that is why it’s important to recognize that DevOps extends from concept to customer.
Keep in mind that the benefits of a DevOps transition do not suddenly appear one day, once an organization has achieved a particular state. Rather the benefits accumulate as the transition gathers momentum. As it grows stronger and more consistent, an organization’s ability to deliver better software faster becomes a competitive differentiator, enabling the organization to innovate, eliminate waste and respond rapidly to market needs.
Brian Dawson
Evangelist
CloudBees
1 10 companies killing it at DevOps, September 25, 2015, TechBeacon, http://techbeacon.com/10-companies-killing-it-devops
Learn More
It seems that everyone in IT these days is talking about DevOps. From conferences to articles and books, the term has taken the IT world by storm. The buzz is understandable, as many IT groups are looking for a way out of the morass of delayed projects, questionable quality and missed deliveries in which they often find themselves.
In this whitepaper , we take a look at:
- What DevOps is
- Why you must care about it (hint: your business depends on it)
- Whether it’s a passing fad or here to stay