5 DevOps Books You Should Read

“DevOps” the buzzword has been zipping around enterprise IT over the last few years. But for those who have only heard about it or the benefits it promises, it can be difficult to find any concentrated resources where one can do a deep-dive to gain a deeper understanding about the concepts. To this end, George Hulme recently wrote an article listing 5 books you should read if you’d like to gain a deeper understanding about DevOps and its practices (see article here). In no particular order, they are:

The Phoenix Project

This one is kind of like the IT equivalent of a DC/Marvel crossover. It’s written as a business novel from the perspective of a character who has been thrust into the role of overseeing IT Operations at a failing company. The crossover part comes from the novel’s relationship to another book on this list, The Goal. Concepts from The Goal, originally applied in the manufacturing realm, are borrowed by author Gene Kim and applied to IT. Additionally, there’s actually a character in The Phoenix Project from The Goal, who in the interim graduates to a Yoda-like level of understanding of how to maximize flow through a system, and subsequently coaches the management team in The Phoenix Project towards achieving DevOps and turning the flagging business around.

The business novel format makes it a very quick read, and the concepts easy to grasp as you learn about how the characters struggle through various challenges in their effort to transform IT. One drawback to the novel format is that it makes it hard to reference specific concepts later on, but it’s a great introduction to DevOps. I’ve read this one, and as geeky as it sounds, I honestly couldn’t put it down.

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

This one is a textbook written by Jez Humble and David Farley. The first four chapters lay out the rationale behind the concept of Continuous Delivery – the business need, the challenges within IT today, and the benefits of automating the delivery process. The last 11 chapters dive into the nitty-gritty on how to do Continuous Delivery. It’s an invaluable reference to keep in your office as you begin building out your delivery pipeline.

The Visible Ops Handbook

This book was a precursor to DevOps, written in 2005 by Gene Kim, Kevin Behr, and George Spafford. It presents a framework on how to effectively implement ITIL, focused on reducing the amount of unplanned work, number of incidents and MTTR while increasing uptime. The lessons taught in the book were culled from interviews with “hundreds of IT organizations” and presented around case studies on those organizations which were the highest performing. More importantly, it is organized as a “how-to,” providing first steps and concrete examples for those who wish to affect change within their IT organization. It is considered a must-read by many IT professionals.

DevOps for Developers

This book is aimed at developers, but also for QA, sysadmins, and DBAs looking for concrete examples on how to improve the software delivery process. It offers advice on choosing a toolchain, which covers both open source as well as proprietary tools. “The value in this book is its real-life examples, and explanations as to how different roles on teams in Dev and Ops can work together more collaboratively,” writes Hulme, who adds, “It also dives into common pitfalls organizations hit in their journeys of operationalizing DevOps.”

The Goal

I had to read this business novel for an operations class in grad school, and I loved it. It was written back in the 1980’s by Eliyahu M. Goldratt to explain a concept he named the Theory of Constraints, focused on how to maximize the output of a manufacturing system through a process of continuous improvement. It is simple, elegant, and profound, and considered to be a seminal work in the area of operations research.

Gene Kim took concepts from The Goal and applied them to IT in The Phoenix Project. The rationale behind doing so lies in the idea that if you mapped out the processes in delivering software, they would resemble the flow of work through a manufacturing plant very closely. Once you have that process mapped out and the appropriate measurements taken, you can apply the Theory of Constraints towards identifying areas of inefficiency, or bottlenecks, in the SDLC. The biggest hurdle to overcome in reaping the benefits of this book is the idea that the output of any given system is constrained by, and equal to, the output of the largest bottleneck in that system.