Introduction
It’s been a while since I read The DevOps Handbook 2nd Edition. It’ll be my source for this short article. Yeah sure you can ask an LLM, but this is a pure good old flesh and bones human take.
Normally when people hear about DevOps, many people think of tooling, but it’s more than that. At its core, DevOps is a set of principles and practices which can be achieved through the use of various DevOps tools. In the book I found one perfect definition that sums it up really well:
…[DevOps] is everything you do to overcome the friction between silos. All the rest is plain engineering.
So, that is why you must remember DevOps is more than about tools.
Silos are barriers that prevent teams from working collaboratively to get stuff done. In the book they’re the enemy and much of the book is dedicated to removing these silos.
So seat back, relax and let’s dive into the world of DevOps.
What is DevOps anyway?
First get rid of the various CLI tools, CI/CD tools and various other tools that it conjures up when you’re asked what DevOps is about. It’s more than those things.
From my gut reading the book, the problem DevOps is trying to achieve is very ambitious but important. namely, “How do we get this bloody software written and deliver value to our customers and make sure it continues working for eternity (nothing works for eternity, but you get the gist)?”. The key is software is never done, once you write it, it’s automatically now legacy, and you must keep it on life support forever (or until decommissioned).
Before the holy grail of DevOps, devs and ops were two separate distinct teams. Devs wrote the software and ops deployed it and setup environments for it. If devs wanted something done they basically asked ops to do it and most likely had to get approval from a manager or two. All this created friction and slowed down the process of getting software out to customers.
Very well then, so most of DevOps focuses really on reducing this friction and making feedback loops shorter. Continuos integration, for instance allows developers to get quick feedback on their code when they merge, tells them if they’re breaking tests allowing them to quickly make adjustments. This same philosophy of feedback permeates much of the principles and practices as we’ll see. Moreover, by creating fast feedback loops at every step of the process we can all immediately see the effects of our action.
DevOps principles and practices are compatible with those introduced by the Agile movement. As a result it’s looked at as a continuation of the Agile movement. It borrows heavily from principles applied in Lean, a type of manufacturing practice with roots in Toyota, so you know it’s good. It applies these practices to what in the book they call The Technology Value stream. WTF is the technology value stream? It’s essentially the process required to convert a business hypothesis into a technology-enabled service or feature that delivers value to the customer. Basically all the shit that must be done to get some shit out to the customer to use. Two of Lean’s core principles are the deeply held belief that manufacturing lead time (basically the amount of time it takes from conception to finish to make something) is the best predictor of quality, customer satisfaction, employee happiness. Consequently, one of the best predictors of short lead times is small batch sizes of work.
Are you getting the picture now? Sounds very much like iterative-incremental delivery in Agile right. Small incremental releases instead of large, big-bang releases. The section below will delve into what is known as the three-ways of DevOps to really help drive this home.
Let’s explain the three-ways of DevOps
No it’s not some sort of kinky thing, but it’s perhaps one of the best ways to understand how the DevOps principles work at a high level.
The First Way
This enables fast left-to-right flow. From Development to Operations to the customer. In this stage, in order to maximise flow, we must make work visible, reduce our batch sizes. Moreover, it’s our duty to prevent defects from being passed to downstream work centers. We must constantly optimise for global goals.
In layman terms, this is essentially your Jira board and one person doing a set number of tickets but not going overboard. The goal here is to give them task they can iterate on fast and get feedback on. We will usually integrate continuous integration tools here so tests run to validate devs work and to be sure existing stuff doesn’t break due to their code. Everything that needs to be done should be visible in this board and someone owns it. At the end we should have ready shippable software to the end user (our customer).
The Second Way
This part enables us to receive a constant flow of feedback from right to left at all the stages of our value stream. It basically requires that we amplify feedback to prevent problems from happening again, or that we allow faster detection and recovery.
Think monitoring, metrics and alerts that go back to the devs or ops to help them troubleshoot or improve the product or their process.
The Third Way
The last way enables the creation of generative, high-trust culture that encourages a dynamic, disciplined, and scientific approach to experimentation with a high risk-appetite, facilitating the realisation of an learning organisation, learning both from our success and failures.
Here you can think Facebook Hackathons, AWS GameDay, and Netflix Chaos Monkey (where they literally cause trouble to learn from).
These three ways when combined afford us better outcomes and capabilities through practices such as continuous integration,test, deployment and working in small batches (the first Way), fast feedback and monitoring (the Second Way), and a generative culture (the Third Way).
A key part of DevOps that I didn’t touch on much here is the idea of self-service. Remember the first way is about reducing handoffs and increasing flow of work, so if you can automate various tasks such as the creation of environments then you reduce friction. This is an idea that is now being exemplified by Platform Engineering. Where tools help developers unblock themselves. This shift reduces dependency on others and allows teams to iterate and deliver faster.
Summary
So there you have it folks. I hope I have done my best in those last few minutes to explain what DevOps is about. Let’s sum it up:
- It’s not just about CI/CD tools although they’re a part of achieving its goals
- It’s an extension of the Agile philosophy
- Is influenced by Lean manufacturing practices
- Is a set of principles and practices (the tools help us realise these)
- Focuses on reducing friction and creating fast feedback loops in teams
- First way deals with flow from left to right, devs, ops to customers (rolling features out)
- Second way deals with feedback from right to left, essentially from customer, ops to dev (Usually in the form of alerts and metrics)
- Third way aims to create a learning organisation with high-trust where people can experiment and learn from mistakes. So-called continuous improvement.
- Emphasises the idea of self-service to further unblock developers and unlock flow, fast feedback loops and delivery.