This weekend, I was chatting with my mother. She’s glad that I have been getting into tech the past few years and told me that she was always surprised that I hadn’t gone into IT when I was younger as it seemed like such a natural career path for me. She did ask me one question though. She had been in IT before, but for as long as I can remember she had always been in management, which is why I was pretty surprised when she asked me “What is DevOps, anyway?”
Insert me taking a long breath and trying to sort out several different lines of thought (Multi-processing aspie brains are fun, but can sometimes make collecting thoughts difficult). There are plenty of books out about it, and many of them will expand on “Ask 100 DevOps engineers what it is and you’ll get 100 different answers”, so for answer 101:
From my experience, DevOps is a philosophy; one of the efficient development, deployment and operation of the highest quality software possible.
I personally like thinking about DevOps in terms of ‘the three ways’ – A set of concepts that is referenced in books by Gene Kim, Kevin Behr, and George Spafford.
This is definitely the one that drew me to DevOps initially: I had spent my life as a project manager, consultant, business analyst, etc etc etc and I was always looking at the systems that the businesses I was working with were employing and the flow of their work. The first way looks at the process and efficiency of the entire system as a whole, whether the scope encompasses a single system, such as a paid membership system with the need to record who has paid, who is eligible for discounts, etc etc etc, or could be as large as a multinational company needing to know likelihood of being able to fulfil orders over xmas 2021 taking into account… *waves at the entire world*.
The point of the first way is to focus on business value streams that are enabled by IT, and ensure that no known defects pass downstream. It ensures that local optimisation doesn’t lead to wider system degradation, and looks to achieve profound understanding of the system, while increasing flow from development to operations.
Easy, right? There are a million different ways to do this and a million different tools that can be utilised, but the important part is that the goal is to maximise the flow of work through the system. Reduce waste (Muda), reduce work in progress (Muri) and reduce uneven system flow (Mura).
Have you ever been in a company where they have hired someone to create a system, such as a finance system, and when you ask them to make a change (for example; asking for a feature that will automatically email anyone who hasn’t input a timesheet at 9AM on a Monday morning), they give you a 9 month estimated turnaround? That’s an example of a weak feedback loop.
The goal of the second way (and any process improvement initiative) is to strengthen and shorten the feedback loops so that required corrections, edits and updates can be made, as well as embedding knowledge where it is needed.
“If failure is not an option, then neither is success.” was something that was parroted to me a while ago, and when I first heard it, I didn’t really understand it. I may still not really understand but I hope I am getting better.
The third way should be about empowering your people to try new things, take risks and be willing to fuck up. Only by doing that is there a potential to learn, to grow. You should be looking to test your systems to see how you can break them so that you can strengthen that part that broke.
The goal of the third way is to develop mastery of the the work, and the only way to do that is through both repetition and learning from failure.
So what did I tell my mother?
DevOps is a philosophy for improving systems based on everyone understanding those systems inside and out.