DevOps: An Idea of Change for the Future

Originally written for peakhosting, located here:

What is DevOps? you Ask...

DevOps is an idea, a culture and catalyst for change and not a set of tools or a magical product to purchase. Some might say it is an operational approach to handling business. By uniting development techniques with operational tactics and practices, you can create an environment within your business that will continually improve and create adaptability. This, in turn, allows faster innovation, accelerated improvements, and improved quality and better flow and efficiency, freeing you to focus on your core competencies and business goals.

The things most important in DevOps are the same as in other ideas, such as the Agile Manifesto. By following similar principles we can uncover better ways of running systems, through doing it and helping others do it. Through this work, we have come to value the following:

Individuals and interactions over processes over tools

Working systems over comprehensive documentation

Customer and developer collaboration over contract negotiation

Responding to change over following a plan

While there is value in the items on the right, we value the items on the left more.

In DevOps, there are certain things that come to light that are needed first before all others, a ladder if you will.

The first stage is always definition of the system as a whole, at the highest level you need to define when the value starts or is created, and then define where it ends up (hint: customer).

To quote an amazing book on the information, The Phoenix Project

The Three Ways describe values that define process and procedures as well as interactions. From learning  The Three Ways we can adjust our interactions and our philosophies to help the entire organization win.

The First Way is the Way of Flow

The Way of Flow places Development as the business agent and Ops as the customer agent. In this arrangement, value flows in one direction, from the business to the customer. When we think as a system, we can focus clearly on the value that flows between Business, Development, Operations and the end users. We can see each piece as it fits into the whole and can identify its constraints, but we also work to become greater than the sum of the parts. It allows us to properly define our work, and when we can see and think in terms of the Flow of our system, we see the following benefits:

• Increased value flow due to the visibility into what it takes to produce our end product
• Our downstream step always gets what they need, how they need it, when they need it
• Faster time to market
• We bring Operations in earlier in the development process, letting them plan appropriately for the changes that Development will be making (because we know that all changes can affect how our product is delivered). Result: less unplanned work or rushed changes
• Because work is visible, Ops can see the work coming and better prepare for it
• We can identify and address constraints or bottlenecks in our system
• We don’t let a defect get past discovery, we ‘stop the line’ and do not push that problem forward

Given these benefits, it would seem obvious that the Way of Flow has real value to an organization.

The Second Way is the Way of Feedback

The Second Way adds a backward-facing channel of communications between Operations and Development. It enforces the idea that we always need to communicate to improve the product. Development continually improves as an organization when it better sees the outcomes of its work. This can be small (inviting the other groups to our meetings, for example) or it can be larger (including Development in the on-call rotation, tools development, architecture planning and/or incident management process). But to truly increase our Flow and improve the business value being delivered to the customer, our groups need to know “what happens, when it happens.” When we increase our Feedback and create a stable Feedback loop, we see the following benefits:

• Tribal knowledge grows and we foster a community of sharing
• With sharing comes trust, and with trust comes greater levels of collaboration, which leads to more stability and better Flow
• We gain a better understanding of all of our customers, such as Operations as a customer, Development as a Business, but especially our end users, to whom we deliver value
• We fix our defects faster and are more aware of what is needed to ensure we do not repeat the same problem again
• We adapt our processes as we learn more about the inner workings of other teams, which increases efficiency, flow and communication
• We increase our delivery speeds and decrease unplanned work

We can see that increased feedback is not only critical to improving communications in the organization, but also for increasing trust and collaboration.

The Third Way is the Way of Continual Experimentation and Learning

When we have achieved the first Two Ways, we can feel comfortable knowing that we can push the boundaries. We can experiment and fail fast, to achieve greatness. We have a constant feedback loop for each small experiment that allows us to validate our theories quickly. When we increase our Experimentation and Learning we see the following:

• We fail often, sometimes intentionally, to learn how to respond properly and discover where our limits are
• We detect faults in the production system as early as possible in the delivery pipeline
• We practice for outages and learn innovative ways to deal with them
• We push ourselves into the unknown more frequently, becoming comfortable in the uncomfortable
• We innovate and iterate in a “controlled” manner, knowing when we should keep pushing and when we should stop
• Our code commits are more reliable and production ready
• We test our business hypotheses at the beginning of the product pipeline, and measure the business results
• We constantly put pressure into the system, striving to decrease cycle times and improve flow
• We value resiliency over stability, since both external environments and internal structures for accomplishing things are complex and ever shifting, failure is “always around the corner”
• It should be treated as just another expected event rather than as an exception
• We value minimizing Mean Time To Repair (MTTR) over maximizing Mean Time Between Failures (MTBF): the inevitability of failure makes trying to maximize MTBF a futile exercise. Instead the focus should be on maximizing one’s ability to repair failures. The dynamic nature of the market means that even working applications quickly fail to match shifting requirements. Not only operations but also development becomes an exercise in minimizing MTTR.

The most important takeaway here is actually that DevOps is not a toolset or a product, but a culture change to iterative, fast-quality improvements, where you smooth the flow through the company and each iteration. The result is that development gets faster and more efficient, until you have the best possible solution to provide your business deliverables to the customer in the most efficient and cost effective way possible.

Although failure is inevitable, it is better to speed the recovery time than trying to accomplish 9 9’s uptime.

Flow will only improve if you define the value flow first, then look for improvements once you understand the reason the flow moves the way it does currently.

Small but exponential changes are how the most value it achieved.