DevOps: What It Is, and What It Isn’t
During the daily work of delivering valuable software to customers, too often development and operations are in conflict with each other. Development wants to see its changes, such as new features, delivered to the customer quickly, whereas operations is interested in stability, which means not changing the production systems too often. DevOps strives to improve collaboration between development and operations by aligning incentives and sharing approaches for processes and tools.
The DevOps movement is young, so many people still do not understand exactly what it is or why it’s important. At its most fundamental, DevOps is a modern way of developing software by aligning the goals, processes, and tools of development and operations with one another. Core facets of DevOps include measurement; metrics and monitoring; and a holistic approach to improve the flow of features and accelerate delivery — for example, using automation to gain fast feedback. Note that automation is an important aspect of DevOps, but first, processes need to be simplified to reduce variations that can impede successful automation.
Let’s examine some of the most common DevOps misconceptions.
Misconception #1: DevOps strives for new organizational units or teams.
When people say DevOps is about creating new organizational divisions, it’s like saying, “Another silo will solve our problems.” Obviously that’s not true; as the name DevOps already suggests, it’s all about improving the “how” — that is, how development (Dev) and operations (Ops) work with each other on a daily basis. DevOps is about accelerating the development flow by streamlining the entire development and delivery process, such as the Agile ALM approach.
A holistic, end-to-end approach is a crucial part of DevOps. Taking the whole system into account can be done — for example, by applying value-stream mapping. It’s then necessary to inject feedback loops into the system and drive a high degree of automation, so that incidents and problems can be quickly identified and corrected.
In DevOps, allowing people to experiment and learn is as important as trying to fail fast. The best strategy against major unexpected failures is to fail fast and often. Frequently causing failures actually leads to a more resilient system, as in the case of Netflix’s Chaos Monkey.
Misconception #2: DevOps holds all parties collectively responsible for the outcome.
Although shared incentives are important, clear responsibilities are still important too. Traditional IT governance remains crucial with DevOps. This includes defining roles and responsibilities, measuring and reporting, and taking actions to resolve identified issues. Sharpening processes, roles, and responsibilities is vital to DevOps, as is good IT governance.
Misconception #3: DevOps and continuous delivery (CD) are very tightly coupled.
While DevOps deals with the collaboration of development and operations, CD is built on the concept of continuously bringing changes to production, with minimal lead time, and then iterating frequently.
CD spans the software lifecycle and is based on continuous integration (frequently checking in changes to version control, sometimes multiple times a day, with the constraint that developers can check out current states of the software at any time and can’t afford to have any build errors locally afterwards), continuous deployment (frequently deploying changes to target environments), and continuous inspection (using the inspect-and-adapt pattern to keep up the internal and external quality of the software).
Continuous delivery is not necessarily part of a DevOps initiative. However, if you implement continuous delivery, you’ll most likely have to implement some sort of DevOps too.
To recap, DevOps is a modern way of maximizing collaboration between development and operations. By closing the gap between development and operations, DevOps enables you to deliver higher quality software, faster, that is more aligned with individual requirements and basic conditions.