The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois and John Willis is the product of five years of intensive research, conferences, discussion with IT professionals, including between the authors themselves.
The Handbook builds on a number of other significant works addressing the problems which DevOps seeks to fix that have been published over more than a decade, including but not limited to:
- The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps
- Gene Kim, Kevin Behr and George Spafford (2005)
- Continuous Integration: Improving Software Quality and Reducing Risk
- Paul M Duvall, Steve Matyas and Andrew Glover (2007)
- Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation
- Jez Huble and David Farley (2010)
- The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
- Gene Kim, Kevin Behr, George Spafford (20123)
It also draws heavily on the annual
Puppet Labs State of DevOps Reports which examine what contributes to the development of High-performing IT organizations.
The preface documents the Aha! moments of each of the authors that were critical in bringing them to what is now knows as DevOps. Gene Kim writes about the outsourced IT Operations of a large airline company with its "large, annual software releases: each of which would cause immense chaos and disruption" resulting in the layoffs of talented people. Kim writes:
"The sense of hopelessness and futility that resulted created for me the beginnings of a crusade. Development seemed to always be viewed as strategic, but IT Operations was viewed as tactical, often delegated away or outsourced entirely, only to return in five years in worse shape than it was first handed over."
Each of the authors tell similar stories of thinking there must be a better way. Jez Humble cites a project with ThoughtWorks where the team automated deployments. "That project inspired a lot of the ideas in both the
Continuous Integration book and this one," Humble writes. Patrick Debois writes that for him it was a "collection of moments" beginning with a data center migration project in 2007 and culminating in the 2009 Velocity Conference with the "10 Deploys Per Day"
presentation by John Allspaw and Paul Hammond. John Willis writes about when he first met Luke Kanies, the founder of Puppet Labs at an O'Reilly open source conference.
The book clearly draws upon the vast collective experience of the authors in seeking to "describe how to replicate the DevOps transformations we've been a part of or observed." The rest of the preface focuses on dispelling common myths about DevOps such as it only being for startups.
In his forward, John Allspaw, the CTO of Etsy gives his view that the handbook represents a "synthesis" of a "diverse set of perspectives" on the origins of the DevOps movement.
The introduction gives a very good overview of DevOps and the problems it is trying to solve. It also points to the rapidly acceleration trend towards "faster, cheaper, low-risk-delivery of software." It includes a table that details the declining risk from the 1970s and '80s to the 1990s and 2000 to the present pointing to the evolution of both infrastructure, from Mainframes to Client/Server and now Commoditization on the Cloud, and software development languages from COBOL to C++ to Java, Ruby on Rails, PHP etc.
In elaborating the business value of DevOps, the introduction sketches out the value of DevOps for both business as a whole and individual teams. Introducing the six parts to the book the authors write:
"The purpose of the DevOps Handbook is to give you the theory, principles, and practices you need to successfully start your DevOps initiative and achieve your desired outcomes."
In my opinion the authors have certainly succeeded in this purpose. The handbook avoids a discussion of tools or even specific technical implementations in favor of more fundamental practices such as moving from large to small batch delivery, or the importance of the Deployment Pipeline.
Part one of the handbook is titled
Agile, Continuous Delivery, and the Three Ways. Readers familiar with
The Phoenix Project will know that it presents the Three Ways as the set of principles upon which all the observed patterns and behaviors of DevOps are based and this point is reiterated by the authors of the handbook.
After introducing the Three Ways, the book gives a very thorough guide to starting a DevOps transformation in part two, appropriately titled
Where To Start. This section talks about picking the right value stream to give early successes, citing real world experiences from the retail company Nordstrom. It offers valuable tips for how to expand DevOps across the organization. The handbook gets into detail on "organizational archetypes", reviewing the pros and cons of functional versus market-oriented teams and discusses various DevOps patterns such as embedding operations engineers into the development teams and assigning an ops liaison to each service team.
The bulk of the book is taken up with an elaboration of The Three Ways from the standpoint of technical practices. In this way it elaborates technical principles that form the bedrock of a successful DevOps program. For example in part three
The Technical Practices of Flow we find a discussion of the deployment pipeline, automated testing, continuous integration, automation and continuous delivery. All of this is backed up by detailed case studies.
A similar level of detail is giving to The Second Way in
The Technical Practice of Feedback and The Third Way,
The Technical Practices of Continual Learning and Experimentation. This is followed by a discussion on integrating Information Security, Change Management and Compliance into DevOps.
I would recommend a careful reading of this valuable work for anyone involved in or thinking about a DevOps transformation. This is equally true for managers and individual contributors. DevOps is gaining more momentum in the enterprise thanks to events such as the DevOps Enterprise Summit, now in its third year as well as the numerous DevOps Days that have taken place since the first one organized by Patrick Debois in Belgium - Ghent in 2009. The case studies provide ample evidence of the benefits of DevOps as well as the consequences of ignoring it.
One minor gripe I have with an otherwise excellent book is the presentation of the Endnotes. They provide valuable sources for each chapter with page numbers referenced by a quote from the text. Here's an example from the Introduction:
xxv Dr. Eliyahu M. Goldratt... Goldrat,
Beyond the Goal.
One can find what this refers to by going to the page and looking for that reference but there is no indication of the existence of the note while reading the chapter. On discovering the Notes section, I at first thought that the superscript numbers normally indicating the presence of end notes had been accidentally eliminated in production but it seems this was a design decision, a bad one in my opinion, but don't let that stop you from buying the book.
