What DevOps Is and Is Not
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.
DevOps Is Not
- DevOps is not a new tool. While the DevOps community has created a lot of cool new tools, and many of the things DevOps recommends cannot be done without tools, using Puppet or Docker or Jenkins or other tools does not mean you are “doing DevOps.” The tools are not DevOps, they merely enable it.
- DevOps is not a new team. The name “DevOps” infers connecting the Dev part of IT with the Ops part of IT. Adding another group between Dev and Ops would be counterproductive to achieving that end. (Creating a DevOps team to experiment with the processes and tools and recommend how Dev and Ops should work together is a great way to get started – as long as that team is Dev and Ops, and does not stand between them.)
- DevOps is not a new role. Many companies are advertising online for “DevOps Engineers,” demonstrating that they don’t understand what they are asking for. DevOps comprises everything that goes on in an IT organization. So a DevOps Engineer would be an IT-one-man-band doing everything. Everything!
- DevOps is not a Body of Knowledge. There is no central authority and no DevOps standard. There is no single “right way” to go down the DevOps road.
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:
- Theory of Constraints
- Toyota Production System
- Resilience engineering
- Learning organizations
- Safety culture
- Human factors
- High-trust management cultures
- Servant leadership
- Organizational change management
- Agile Methods
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’s Three Ways
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: Flow
- The Second Way: Feedback
- The Third Way: Continual Learning
The First Way: Flow
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: Feedback
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.
The Third Way: Continual Learning
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.
Automate Everything You Can
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.”
DevOps Resolves the Core Chronic Conflict
Every IT organization has two simultaneous priorities:
- Innovation: Keep up with our customers’ and users’ changing needs by developing and deploying new and enhanced IT Services and applications.
- Stability: Ensure that our customers and users can use those IT Services and applications and that their data and information is kept safe.
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!
Using What We Know
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.