I was interviewed recently at DevOps.com talking about the database as a part of DevOps. As part of the interview, Alan Shimel asked me for a book recommendation. After that, I decided I should recommend a few books that I’ve read and think have helped me to understand DevOps.
The Phoenix Project
I actually read The Goal first, which applies the principles of DevOps, grown out of the lean movement, to manufacturing. The Phoenix Project is based on the Goal, but looks at Information Technology.
The book is a good, light read. It felt like a repeat of The Goal, but it cemented some ideas, and I enjoyed it. The guru character is a little overdone, but certainly the “Brent”, jack of all trades, the one everyone depends on rings a bell. I’ve been Brent in a few places, where I had to be involved in everything. While flattering, it’s tiring and annoying.
This is a good, semi-satirical look at IT projects that helps you to realize the somewhat silly ways we build and deploy software sometimes. A nice overview for DevOps.
The DevOps Handbook
I read The DevOps Handbook the most recently of these three. After looking for more information on how DevOps is evolving, and following the research of Gene Kim in talks and articles, I decided to give this a try.
The book is long, though if you read on the Kindle, you’re at the end around 70%. The rest of more details and additional material. It was interesting, using case studies and information from a variety of companies to explain the three ways that Gene Kim has postulated as the principles of DevOps. They are:
- Systems Thinking
- Amplify Feedback Loops
- A Culture of Experimentation and Learning
Those are discussed in chapters with examples of how companies implement these, along with the shift left and shift right concepts. I’d definitely recommend this one.
I actually read this book first. Continuous Delivery was recommended to me when Redgate got serious about DevOps and DLM (Database Lifecycle Management). I was reading this as I attended FlowCon and had the chance to meet Jez Humble. That was a great conference, and I’d like to go back to another (or similar) one.
This book talks mostly about how CI, automated testing, CD, automated deployments, and other specific parts of good software development and deployment practices that come under the umbrella of DevOps. When you look for specific things to implement as you adopt DevOps, this is a good book to give you ideas.
Remember, DevOps isn’t a tool. It isn’t a think you buy or a specific way you do something. DevOps is an idea, a set of principles, by which you get better. If you have a way of doing that, no matter what you call it, others might call this DevOps.
Conversely, if you aren’t getting better, if you struggle to get software changes to customer, have quality issues, or stressed staff that don’t collaborate, it’s not DevOps, no matter how much “stuff” you do.