Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers)

I wish that life of a programmer would only be a about writing clean, and well-tested code. "Clean Code" would be my bible. My code would've then somehow be deployed somewhere and run flawlessly. Unfortunately, life isn't that simple. There is much more in being a real-world programmer. The code actually needs to run in the production environment and must be used by a bunch of users. And they tend to break it :)Finishing the code is just a beginning of a system's life. It goes to the production and all sorts of things tend to happen. Guy who wrote this book had an incredible knowledge and experience with dealing with the production environments and he's sharing his experience with us. This book is well structured and grouped by related topics, but essentially it is just a set of stories and advices on operating production systems, and creating code that is supposed to run in the production. I'd like to name two "main" topics that you're going to read about: common programming practices and non-programming part - dealing with the live production systems.Common programming practices include a rich variety of things like: Dealing with timeouts, capturing and understanding thread dumps, working with networks, understanding and tuning garbage collection, configuring proper logging, or understanding ORMs and related issues.Dealing with the live production systems will discuss topics like: Embracing "fail fast" approach, understanding and dealing with SLAs, scaling of systems, performance monitoring, load balancing, designing configurable systems and so on.Even though that "Release It!" is ~8 years old (as of this review), time didn't hurt it much. Yes, yes - we don't need to deal with RMIs and CORBas and old EJBs and manual synchronisation so often in "enterprise programming" today (thanks to the rich variety of mature enterprise frameworks) - but it's a no big deal. I still felt that this book was very relevant even today in the world of clouds, and MEANs and microservices and other buzzwords. I'm pretty sure that its message is going to last here for quite a while."Release It!" is the "Clean Code" of production systems. Somebody's already been there. Take this shortcut and learn how to make your life after the release easier. Avoid mistakes, learn from the best. It's been a wonderful read.

I found this book to be very well-written, informative, and practical. If you're working on relatively large scale web applications (large enough to merit multiple application servers and a load-balancer), then there is some very beneficial information in this book for you. I'll definitely be adding it to my "reference shelf" (not deleting it from my Kindle).My only "issues" with the content are the following:1) The book deals largely with good practices, but provides very few code examples.2) The author's frame of reference is primarily JAVA development, so most of the few code references in the book are only applicable to that language. If you're using a different set of development tools (.Net for example), it will be up to you to locate libraries to provide equivalent functionality.On the whole the content of this book was excellent; but, if you're looking for a "how-to" with specific code examples, you'll be disappointed.

There are a lot of worthwhile nuggets to gather here.The main takeaway is to be paranoid, watchful and cautious. There a number of spots where a system can come to grief. For example, resource pools, threads and integration points where external services are being called. The code will never be 100% error-proof, there will unexpected errors - the question is how to deal with them. How do you learn what to expect from your system? What proven "design patterns" help in reducing system fragility?Now, the book quotes a lot of Java stuff. And it is an older book.Despite not being a Java dev, I deeply believe that, in this context, a lot of the same pitfalls that apply to Java apply to other languages. These are integration issues, not development/unitary issues. Sure, if you are a seasoned pro in system management, some of this may be familiar. Which is a good sign, if you think about it. Neither the exact age of the book or the exact technologies being used matter all that much - what matters is knowing which parts of the system(s) are more likely to fail. The exact tech doesn't matter if you're calling a dead server, what matters is that you anticipate that it could fail and build tolerance around that.If like me, you are approaching system deployment and maintenance from the dev/devops side of things, then there are some very good ideas to take away. Probably ideas that you would have had on your own, once you had hit some of the same issues.Point in case: the debrief that followed Amazon's Sept 20, 2015 outage ended up being precisely the kind of stuff that this book cautions about. An overloaded service bogs all the other ones down. Not to say that Joe Blow, or me, after reading this book, would have avoided what Amazon's very clever folks didn't. But the type of error that happened is precisely of the typology addressed here.