During my studies for a Master's degree I read a lot of books. Sometimes good books and sometimes books that seem to be written entirely for academia. One of the good books that I recently read was the book called "Release It" by Michael T. Nygard. It is also on my must read list for software architects. This review is on the second edition which came out in 2018.
The book
The book is all about architecture design and decisions in regards to stability. It contains a lot of war stories from Michael's career. Many of the stories are relatable, as most seasoned developers have been in a situation where something went horribly wrong. Michael describes these situations in a way that you can almost feel that you are there - giving the book a great narrative. The book is now in it's second edition and can be found here:
Stability patterns and antipatterns
The first few chapters of the book are the best in my opinion. These pages contain definitions of stability patterns and stability antipatterns. Stability Patterns are patterns that improve the stability of your architecture and are suitable to deter one or more stability antipatterns. An antipattern (a simple one) may be "slow responses". A stability pattern to fix this may be to use timeouts, which stops errors from propagating throughout your system.
These are the most simple patterns and antipatterns used in the book. I used the timeout and slow responses example as everyone can relate to them and understand them without reading the book. However many of the patterns are a lot more challenging to understand. But they will help you understand and identify the weak points in your system. By reading the chapters you may easily think of a way to improve your current project.
Nygard also states that most systems communicate with others in some way or another these days (try to think of one that doesn't?). Even your filesystem or database may fail, and should be seen as an integration point. These integration points will fail on you at some point.
As mentioned I think these are the greatest chapters in the book. They give you some great pointers to improvements on your architecture's stability.
The rest of the book - design for production
The second part of the book looks at what it takes to go into production. Many feel that their program/system is ready to go into production when they have written the code. However this is far from the truth. There has to be a good foundation for bringing your code into production. Such as somewhere to deploy it (hardware/VMs/containers), Monitoring of your applications, loadbalancing and the list goes on.
These are the not-so-programming oriented architectural decisions you need to have in place. The chapters cover continuous delivery in the form of deployment pipelines. When you do automatic deployment you also need to have automated tests in various forms. Nygard describes different test approaches and what you need to know on this. He also takes this a bit further than usually with his chapter on "Disaster Simulations".
The chapter is of course not complete without a couple of personal war stories from Michael. Overall as the title states, this chapter is about designing your system so it can gracefully go to production - and stay up.
This part of the book reminds me a lot of Building Microservices by Sam Newman. As he also covers the topics of devops, continuous delivery, monitoring, logging, testability and configuration.
That's it
I hope you liked my review of this book. I do enjoy writing these as I like to share what I enjoy reading. As this is on my must-read list I believe I don't have to say that it is good.
Below you can find the newest version of the book:
If you are interested in the old version it can be found here:
Let me know in the comments down below if you disagree or agree with my review!