I came across "The DevOps Handbook" because the company I work for decided to recruit a guy with the title "DevOps" - Half developer, half operations. He was going to help the company to become more agile and he recommended we all read this book.
So I did. I figured I wanted to share some personal from my perspective as a fellow backend developer with this blog post.
The basic premise of the book
"The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations" is a practical roadmap for building high performing IT organizations. It’s written by Gene Kim, Jez Humble, John Willis, and Patrick Debois who are are recognized as some of original adopters of what is now considered DevOps. The book itself is summarizing and structuring the concepts behind DevOps. While it has a practical twist, it's not focusing on the concrete technological tools to do so. It puts into writing how to break down barriers and how to enhance processes, people and culture. Therefore the books is not only aimed at developers and operations people, but also IT management to gain a common understanding of challenges and solutions.
The authors split the DevOps process into three ways:
The principles of Flow – Deployment pipeline, Continuous delivery, Automated testing, etc.
The principles of Feedback – Telemetry, Business monitoring, Enable review processes. etc.
The principles of Continual learning & experimentation – Culture of learning and sharing, Blameless post/pre-mortems, etc.
The book is divided into parts based on the ways. Each part explains the relevant technical practices with supporting case studies and experiences sourced from industry professionals. Companies and case studies from Google, Netflix, Amazon, Facebook and Etsy are included often.
Thoughts on some of the key points
The DevOps Handbook has a lot of good points and many noteworthy passages. While a lot of the points are to be expected if you've heard about DevOps, Continuous Integration and so on, there were also some points which I hadn't heard before.
A point I took to heart was when a significant problem occurs it should be swarmed in order to optimize learning and to solve the problem right away. I think this goes hands in hand with what the book refers to as Post-Mortem meetings. Post-Mortem meetings are blameless meetings after a significant incident like a production breakdown or a security issue has been resolved, where knowledge and learnings are shared. I believe attacking problems head on and not waiting while sharing the learnings from the problems ensures that the same mistakes are not made and that information is made transparent to everyone. It also encourages a culture where morale and teamwork can be improved through mistakes and learning. Mistakes and failure a huge part of IT and therefore it should be embraced and not hidden. The only real mistake is sweeping failure under the rug and not learning from them.
Another point which I found interesting is that The DevOps handbooks talks about a single repository and a trunk based development approach, where code is checked in to the same trunk branch. This is an approach I have never seen in practice, only read about. In our organization we use "git flow" with its respectable feature, release and hotfix branches. This approach sometimes gives us long lived ("project") feature branches which results in merge conflicts and pain. If our team had been even bigger, this approach could give us some real issues down the line.
Trunk based development tries to solve this by reducing batch size, which can be easily tested and integrated into the central repository. After reading the chapter on trunk based development I am less skeptical of the approach, but I do realize that switching to this requires a drastic change in how we do our development and our release cycles. This approach also requires tests to be run on every commit to ensure the trunk is in a buildable and deployable state. The setup to accomplish this is an organization with a non trivial amount of developers producing code should not be underestimated.
The last point I want to is the part where the book mentions smoke testing during a release. The book mentions a couple of strategies for deployment but the one I was most keen on was the canary release pattern. I think that being able to deploy new code and features to a subset of users before going out to everyone sounds ideal. With a setup like that one could see the code running in an actual live environment but with the risk associated with deploying a huge feature reduced. One could of course argue, that huge features should be incrementally deployed and switched on using something like feature toggles, but as with many things, sometimes the ideal situation is just not possible with the current setup and the canary release pattern could solve this.
Developers should be DevOps
In my humble opinion, all developers should be DevOps in some form of way. I realize that while it feels "safe" to write code and then pass the responsibility on to another team when it needs to be deployed and supported in production is wrong.
The person/team with the most knowledge of the code should be the one deploying it to production, testing the code, looking at metrics and logs and do the potential fixing when in production.
It's all about taking responsibility of the work you do and follow all the way into production, actively looking at metrics and supporting it.
Of course this requires tools, a different mindset and a setup which allows the developers to easily deploy changes and see the current status of the system they support. If a developer is afraid of deploying and supporting their own code it's a sign of something missing in the setup. Missing production like testing environment, testing pipeline, automated deploy / rollback, real time available logs and telemetry and so forth.
These are tools absolutely required for giving the developers the confidence to succeed as DevOps.
I didn't expect I would like this book so much, but I really enjoyed reading it. The points are very well articulated and written in a language easily digestible. I was surprised by how many useful points the book had that I could directly relate to the challenges I face everyday as a backend developer.
However, don't read this book expecting a detailed guide on how to use concrete DevOps tools. This book is all about creating a general overview and a roadmap for developers and managers alike. If you've heard about DevOps before, a lot of the points might seem very familiar. Nonetheless, the books summarizes challenges and countermeasures very well.
I really think this book is a must read as a developer or manager in an IT organization not already adhering to the DevOps principles. When everyone can speak and understand the basic problems, we can solve them, and this book gives a very good roadmap on how to so.