This book is a mixed bag. It’s one of the most comprehensive books on DevOps out there, but it’s not well written. It covers just about every important DevOps practice, but you walk away without any clear idea of how to implement those practices. It presents a number of case studies of the successful DevOps transformations at famous companies, but it’s not clear how to transform your own company. In other words, instead of a tutorial that teaches you how to become great at DevOps, you merely get a description of the DevOps world.
In many ways, the book feels like a dissertation: a wonderful collection of research, but not necessarily pleasant reading. It feels like academic writing, always using the royal “we”, and relying heavily on citations, references, and quotes, not just as evidence of research (which is great!), but as a replacement for much of the prose (which is annoying to read). It is overflowing with jargon and buzzwords (“kingdom of nouns”) to the point of sounding like a marketing brochure, especially in the very first and very last parts. It contains a ton of repetition; in particular, the intro and conclusion sections of each of the 23 chapters, and each of the 6 parts, are 100% skippable summaries that don’t do a good job of setting context and don’t offer new insights.
Of course, I don’t want to imply it’s all bad. The book covers the full gamut of DevOps topics, including planning, security, deployment, monitoring, team organization, and more. There are lots of wonderful case studies of Etsy, Facebook, HP, LinkedIn, Twitter, and many other companies. And even if you have lots of experience in DevOps practices, the book is thorough enough that you are guaranteed to find at least a few insightful gems in every chapter. In short, it’s a flawed, valuable book that could have been so much more.
As always, here are a few of my favorite quotes:
“Teams are often not able or not willing to improve the processes they operate within. The result is not only that they continue to suffer from their current problems, but their suffering also grows worse over time. Mike Rother observed in Toyota Kata that in the absence of improvements, processes don’t stay the same—due to chaos and entropy, processes actually degrade over time.”
“The analogy I use now is that Ops are the offensive linemen, and Dev are the ‘skill’ positions (like the quarterback and wide receivers) whose job it is to move the ball down the field—the job of Ops is to help make sure Dev has enough time to properly execute the plays.”
“Bill Baker, a distinguished engineer at Microsoft, quipped that we used to treat servers like pets: “You name them and when they get sick, you nurse them back to health. [Now] servers are [treated] like cattle. You number them and when they get sick, you shoot them.””
“Gary Gruver observes that “without automated testing, the more code we write, the more time and money is required to test our code—in most cases, this is a totally unscalable business model for any technology organization.”
“The outcomes of A/B tests are often startling. Ronny Kohavi, Distinguished Engineer and General Manager of the Analysis and Experimentation group at Microsoft, observed that after “evaluating well-designed and executed experiments that were designed to improve a key metric, only about one-third were successful at improving the key metric!” In other words, two-thirds of features either have a negligible impact or actually make things worse. Kohavi goes on to note that all these features were originally thought to be reasonable, good ideas, further elevating the need for user testing over intuition and expert opinions.
The implications of the Kohavi data are staggering. If we are not performing user research, the odds are that two-thirds of the features we are building deliver zero or negative value to our organization, even as they make our codebase ever more complex, thus increasing our maintenance costs over time and making our software more difficult to change. Furthermore, the effort to build these features is often made at the expense of delivering features that would deliver value (i.e., opportunity cost). Jez Humble joked, “Taken to an extreme, the organization and customers would have been better off giving the entire team a vacation, instead of building one of these non–value-adding features.””
“Dan Milstein, one of the principal engineers at Hubspot, writes that he begins all blameless post-mortem meetings “by saying, ‘We’re trying to prepare for a future where we’re as stupid as we are today.’””
“As Galbreath observed, “Nothing helps developers understand how hostile the operating environment is than seeing their code being attacked in real-time.””
“We assert that DevOps is transformational to how we perform technology work, just as Lean forever transformed how manufacturing work was performed in the 1980s. Those that adopt DevOps will win in the marketplace, at the expense of those that do not.”
Rating: 3 stars
Yevgeniy Brikman
If you enjoyed this post, you may also like my books. If you need help with DevOps, reach out to me at Gruntwork.