The Meaning Of DevOps

Click to share! ⬇️

The DevOps Buzz

You can’t go anywhere in technology these days without hearing about DevOps. Companies from Google to Microsoft to HP talk about DevOps, but there’s no agreed-upon definition. So it can be a little challenging to figure out. Two related ideas can explain DevOps. First, DevOps is the practice of operations and development engineers participating together through the complete service lifecycle, from the innovation and development process to production support. DevOps replaces the model, where you have a team that writes the code, another group to test it, yet another team to deploy it, and even another team yet to operate it. Second, DevOps is described by operations staff using many of the same methods as developers for their systems work. DevOps systems engineering operates just like a development workflow. All the assets are checked in the source control and have tests associated with them. DevOps, like Agile or Lean, is a broad enough concept that just a high-level definition doesn’t tell you much about what it is. Some say to break it down into five levels: Values, Principles, Methods, Practices, and Tools.

The DevOps Buzz
Culture Automation Measurement Sharing
DevOps Culture
DevOps Automation
DevOps Measurement
DevOps Sharing
DevOps Principles
Systems Thinking In DevOps
DevOps Feedback Loops
Continuous Experimentation And Learning

DevOps has been shown to improve business outcomes effectively. The Puppet Labs State of DevOps survey indicated the teams using DevOps practices deployed changes 30 times more frequently, with 200 times shorter lead times. This led to 60 times fewer failures and recovery from problems 168 times faster than other organizations. Those are enormous benefits. The survey also showed that these results help across different sizes and types of businesses.

The second reason is that it makes your daily life easier. High Tech is a very interrupt-driven high-pressure exercise in firefighting that can often lead to personal and professional burnout. Many folks have found that the DevOps approach reduces unplanned work. It increases friendly relationships between coworkers, and it reduces stress on the job. While DevOps combines the development and operations of the world, it isn’t meant to leave out other teams. Dev is traditionally understood to represent everyone, usually on the code side, from developers to front-end designers to QA. Ops are generally understood to include everyone traditionally on the system side, whether Linux administrators or network admins. Collaboration among everyone participating and delivering software is a crucial DevOps tenant. Also, when we talk about IT organizations, we include product development organizations, which we often call engineering, and traditional IT shops. Some specific techniques will work better for one kind of organization or the other, but DevOps addresses improving them both. DevOps is not a new name for an operations team, job title, or tool category.

The CAMS model was created by DevOps pioneers John Willis and Damon Edwards. It stands for Culture, Automation, Measurement, and Sharing. CAMS became the model set of values used by many DevOps practitioners. Patrick Debois is sometimes referred to as the godfather of DevOps since he coined the term. But he likes to say that DevOps is a human problem. Well, DevOps is often thought of as a technology problem. In reality, it’s a cultural and business problem.

DevOps Culture

Culture is more than ping pong tables in the office or free food in the company cafeteria. Culture is driven by behavior. Culture exists among people with a mutual understanding and where they’re coming from. Early on in IT organizations, teams were divided into two significant groups. Development was tasked with creating features. Operations were assigned to maintain stability. Walls formed around these silos due to their different goals. Today, after this pattern has long been entrenched, these groups don’t speak the same language and don’t have a mutual understanding. Changing these underlying behaviors and assumptions is how you can drive change in your company’s culture.

DevOps Automation

The first thing people think about when they think of DevOps is Automation. In the early days of DevOps, some people equated the term to anyone using Chef, Puppet, or Vagrant. DevOps is not just about automated tooling, people, and process. Damon Edwards expressed this as people over process over tools. Automation is a critical part of our DevOps journey. Once you understand your culture, you can create a fabric of Automation that allows you to control your systems and applications. Automation is that accelerator that will get you all the other benefits of DevOps. You want to prioritize Automation as your primary approach to the problem.

DevOps Measurement

One of the keys to a sound approach to our systems is our ability to measure them. Sometimes we choose the wrong metrics to watch. Other times we might fail to incentivize them correctly. Because of this, DevOps strongly advises you to measure key metrics across the organization. Look for things like MTTR, the Mean Time to Recovery, or cycle time, and look for costs, revenue, and even employee satisfaction. All of these are part of generating holistic insight across your system. These metrics help engage the team and the overall goal. It’s common to see them shared internally or exposed externally to customers.

Sharing ideas and problems is the heart of collaboration. And it’s also really the heart of DevOps. And DevOps expect to see a high premium placed on openness and transparency. This drives Kaizen, a Japanese word that means discreet continuous improvement. Sharing is the feedback loop that helps continuous improvement. We can see how CAMS – Culture, Automation, Measurement, and Sharing, is the foundation of DevOps. They’re the four fundamental and mutually reinforcing values to bring to a DevOps implementation. You want to take these values to heart because the rest of your DevOps journey will be about realizing them in your organization.

DevOps Principles

Let’s talk about principles you can use to guide you in taking the core DevOps values and bringing them to life. The most respected set of principles is called The Three Ways. This model was developed by Gene Kim, author of “Visible Ops” and “The Phoenix Project,” and Mike Orzen, author of “Lean IT.” The three ways they propose are systems thinking, amplifying feedback loops, and a culture of continuous experimentation and learning.

Systems Thinking In DevOps

The first way, systems thinking, tells us that we should focus on the overall outcome of the entire pipeline or value chain. It’s easy to make the mistake of optimizing one part of that chain at the expense of overall results. When you’re trying to maximize performance in an application, for example, increasing performance or system resources in one area causes the bottleneck to move, sometimes to an unexpected place. Adding more application servers, for example, can overwhelm a database server with connections and bring it down. You have to understand the whole system to optimize it well. The same principle applies to IT organizations. A deployment team might establish processes to make their work go smoothly, and their productivity numbers look good. Still, those changes could compromise the development process and reduce the organization’s ability to deliver software. This overall flow is often called From Concept to Cash. You lose if you write all the software in the world but can’t give it to a customer so they can use it. The split between development and operations has often been where the flow from concept to cash goes wrong. Use systems thinking as guidance when defining success metrics and evaluating the outcome of changes.

DevOps Feedback Loops

The second way, amplifying feedback loops, is all about creating, shortening, and amplifying feedback loops between the parts of the organization in the flow of that value chain. A feedback loop is a process that considers its output when deciding what to do next. The term originally comes from engineering control systems. Effective feedback loops are the key to productive product development, software development, and operations. Take the story of a simple bug. If the developer finds that bug before they check it into source control because tests on their desktop catch it, you’ve eliminated a problem with very little time wasted. If that bug gets past that point, is found by a QA team, documented in a ticketing system, and then pushed back to a developer to fix, it’s still resolved, but with more time wasted. If it gets into a customer release and is encountered by end users, logged with a support organization, churned over in support, escalated back to development, reprioritized by a product manager, and then fixed, it wastes even more time and money for the same or worse outcome. Effective feedback is what drives any control loop designed to improve a system. Use amplifying feedback loops to help you when you’re creating multi-team processes, visualizing metrics, and designing delivery flows.

Continuous Experimentation And Learning

The third way reminds us to create a work culture that allows continuous experimentation and learning. You and your team should be open to learning new things, and the best route is actively trying them out to see what works and what doesn’t instead of falling into analysis paralysis. But it’s not just about learning new things. It also means engaging in the continuous practice required to master the skills and tools already part of your portfolio. The focus here is on doing. You master your skills by repeating patterns and finding new skills by picking them up and trying them. You may have heard other technologists say that working code wins. If it hurts, do it more, and fail fast. These all speak to the DevOps culture, which focuses practically on doing instead of just talking about doing. Use the third way, a culture of continuous experimentation and learning, when creating team processes and standards and as part of your leadership style. Encourage sharing and trying new ideas. Engineers are problem-finders and problem-solvers by nature. And that can often turn into negativity about new technologies or avoiding attempts to try new things, from not-invented-here syndrome to deliberate attempts at niche protection. Acknowledge and overcome these temptations on your path to excellence.

No technology, not even awesome technologies like Docker or Amazon Web Services, is a silver bullet that solves all your problems. It’s how you use them that matters most. As you continue your DevOps journey, staying grounded in understanding what exact problem a given practice or tool solves for you is essential. The Three Ways provide a practical framework to take the core DevOps values and effectively implement specific processes and tools in alignment with them. Keep thinking about the whole system as you progress in your DevOps implementation. Ask yourself, how can I build in more feedback loops? And see how you can contribute to creating an environment of experimentation and learning.