DevOps is not easy to define. This is true for a couple of reasons. First, because what it looks like and how it works look different from the different perspectives of the various roles in IT. DevOps affects everyone in IT, but it affects each role in different ways producing different descriptions.
It is also difficult to define because there are so many misperceptions about it. So before we try to define DevOps, let’s take a few minutes to shoot down the most common misperceptions.
The DevOps Handbook by Gene Kim et al. says, “DevOps and its resulting technical, architectural, and cultural practices represent a convergence of many philosophical and management movements.” The list of contributing philosophies includes:
In other words, DevOps is a matter of drawing great practices from many different domains and implementing them in an IT organization in order to elevate IT’s performance.
Although DevOps draws from some very well established disciplines, the DevOps movement itself is quite recent. The term “DevOps” was coined late in 2009, marking the beginning of this fast-growing movement. Compare this with the term “Agile” which was coined in early 2001, making the Agile movement more than twice as old.
The youth of this movement is another reason why DevOps is so hard to define. The DevOps community has been growing and learning quickly. The practices are evolving, the tools are maturing, and every organization that has joined in has contributed to our knowledge about DevOps.
Gene Kim has been a clear voice describing DevOps through the short history of this movement. His 2013 novelette The Phoenix Project describes a fictitious IT organization and its use of DevOps principles to solve some serious problems. And the 2016 DevOps Handbook provides detailed guidance for any organization embarking on a DevOps journey, based on the experiences of hundreds of other organizations that have gone down that road before.
Both of these books are based on and structured around his “Three Ways.” Kim’s Three Ways are the main components of a DevOps journey, and provide a sort of roadmap to understanding and implementing DevOps:
The First Way involves focusing on the flow of activity in your IT organization and optimizing to make that flow smooth and fast. One of the key flows that we need to address is the flow of value (in the form of software) from our development teams into operational use in production. This involves concepts like continuous delivery and optimizing your deployment pipeline.
To put it in lean terms, the First Way involves understanding your value stream, identifying and removing impediments to smooth flow, and automating to increase the velocity of that flow.
The Second Way builds upon the first by optimizing the right-to-left flow of feedback. This includes the ultimate feedback — development teams having keen insight into how their software performs in production and how it is used by the actual end users. But it also includes any and all types of feedback to all people in all roles along the way.
The intent of the Second Way is to provide clear visibility by the people who do any tasks into the quality of their work and the impacts it has on others, both within IT and on customers, users, and the organization at large. This includes not just ensuring that feedback is provided, but also shortening and optimizing feedback loops so people receive that feedback as quickly and as automatically as possible.
With flow and feedback well established, the Third Way capitalizes on them to establish the patterns of continue learning and continual improvement.
This is accomplished by asking, “What can we learn from what we have done and the feedback we received?” and, “How can we use that knowledge to improve the IT organization’s performance?”
Ultimately, this learning goes beyond the basics of our jobs and includes experimentation to find new and innovative ways to better meet the needs of our customers, our users, and the organization. For example, in “Hypothesis-Driven Development,” we hypothesize about what software capabilities our users and customers might need, then build software experiments to test those hypotheses, discarding the experiments that fail and building on those that work.
The Third Way involves a cultural transformation in our approach to failure — a willingness to embrace failure as a learning opportunity! Whether it is an unexpected operational failure or one we bring on ourselves thru experimentation, we see failure as being good because we learn from it and it makes us better.
A key DevOps principle is “automate everything you can.” This principle is important because automation is so central to an IT shop’s ability to achieve flow (The First Way), fast feedback loops (The Second Way), and high performance (as the continual learning and continual improvement of the Third Way bear fruit). Automation undergirds DevOps performance in a number of ways:
Increased Velocity. Automated activities are faster than manual ones. If an activity can be automated, then there is no way a person can do it more quickly.
Reduced Human Error. Tools don’t make mistakes as people do. Once a tool has been configured and verified to be correct, it will do the task correctly every time.
Consistency. Anything a tool does will be consistent by definition. And tools can be used to check and enforce consistency in activities that are not automated.
Mitigated Risk. Because tools don’t make mistakes and can be used to check manual activities, they can be deployed to mitigate risks that cannot be avoided.
High-performance organizations automate everything they can. That is how they become “high performance.”
Every IT organization has two simultaneous priorities:
These two priorities are in essential conflict with each other because deploying changes into the production environment is the single most common cause of outages and other operational problems. Worse, these conflicting priorities cause friction and other dysfunctions within IT shops because development usually owns the innovation priority, while operations owns the stability one.
DevOps doesn’t just say that Dev and Ops (and QA and Security) must collaborate. It also resolves the core chronic conflict by enabling both innovation and stability at the same time. DevOps practices and tools ensure the stability and predictability of the entire IT operation, with a special focus on stability during the innovation and deployment process. This accelerates innovation by allowing IT teams to move quickly and deploy often, without endangering security and stability.
Win, Win, Win, Win!
Your IT shop is already on the first step (at least) of the DevOps journey, because DevOps doesn’t mean throwing everything away and re-doing it. Rather it means looking at how you do what you do, and using specific tools and techniques to make work flow, improve feedback, and begin to continually learn and improve.
Identify what hurts, learn about how others have fixed that problem, and make an improvement. There! You are on your DevOps journey.