Book Review: The DevOps Handbook

Book Review: The DevOps Handbook

For the first two hours I was reading this book, I was convinced that I was going to gain nothing from it.  Convinced that all it was going to do was say “There need not be a line between Dev and Operations” 432 different ways.  Don’t get me wrong, I know a lot of people who need to hear that 432 ways before they will get it.  I just don’t want to read a book that does it, because that’s essentially what I do 9am-5pm every day.  Once I reached Part 3, this became a bit of a page turner.

From there forward, the book is full of useful tools and use cases for actually achieving DevOps integration and for focusing on lean models.  While I already knew many of these tools and use cases… did you know Netflix has a Chaos Monkey that sometimes randomly kills servers in production with no warning!?  You probably did, and so did anyone who tries to keep up to speed on the next generation of development.    However, in addition to the classics like Netflix, there are less pervasive ideas and examples in this book and ones that have to do with the less sexy parts of DevOps.  I suggest reading the book through the whole way once, but also making yourself a little toolbox of notes so that you can go back and find them when/if your team does/might face the problems they solve.

Here are some examples of things that I learned about (or learned more about) from this book:

  1. There was a great reminder about the concept of the Andon chord… Usually the factory worker has a period of time to try to fix the problem after the initial pull of the chord before the whole line is stopped.  Once that time has past though it must stop and anyone/everyone that might be valuable in resolving the problem is sent to resolve it.  This may sound impossible now, but it also forces smaller checkins so that problems are smaller.
  2. Figure 12 in the book is a great example of how a team organized to solve a problem, puts the problem at the center of the organization.  This seems like a great tool in explaining the “Why” of DevOps.
  3. There was a suggested practice I liked that was to force all developers to merge to trunk daily.  Even if it means adding feature flags to their code it avoids the drift of a short story turning in to a long one unexpectedly.
  4. The discussion in chapter 12 of environment based deployment patterns gets to the very essence of DevOps and the elimination of the “Throw it over the wall” technique.  Many of these will only work in certain types of applications, so I encourage you to read this part especially.  If you’re like me, you hadn’t spent much time thinking about the ones that couldn’t be leveraged for YOUR application.
  5. The idea of using a strangler application to turn a monolith in to Microservices was explained in chapter 13 and was something I had not considered before.  It allows you to be iterative in a place where I thought only a major replatforming project might have been the only option.
  6. The options for telemetry discussed in Part IV are definitely worth the read.