Release It! (Book Review)

Today I finished the Book 'Release It! Design and Deploy Production-Ready Software' by Michael T. Nygard. Coincidentally it was just a few days ago when InfoQ has released an article to this book as well. But this was not preventing me from blogging my own personal two cents about the work of Nygard.

The book is the 5the title published by the pragmatic programmers in my bookshelf. All the titles were very interesting, qualitatively convincing and beautifully put together - don't underestimate the attraction of a beautiful book to a reader and aesthetically oriented guy like me. Now to this specific title.

The author brings up a series of patterns and anti-patterns for creating software. Software which not only survives development but also survives in production - the environment of the real world. It provides general guidance as well as some very specific tips and tricks for development as well as operations. Although some parts are closely related to the Java world, there is almost always a matching example in the .NET world. The writer comes up with loads of interesting examples and case studies to fortify his statements and it's apparent that he brings a lot of experience out of the field.

Generally the book is about large scale (web-)projects but there are plenty of interesting points worth to delve into, even if one's current projects are not (yet) in need of sophisticated load balancing technologies.

Some catchwords from my personal things-to-remember-list of this title:

• Circuit Breaker (together with Timeouts) is a very interesting pattern for dealing (even monitoring) with integration points of a system.


• Beware of Chain Reactions in a system. Prevent with Bulkheads if necessary.


• Communicate transparently and often. "Good marketing can kill you at any time." (Paul Lord)


• Keep your SLA in mind while dealing with dependencies.


• "Data purging never makes it into the first release, but it should."


• Conway's Law: "Organizations which design systems are constrained to produce designs whose structure are copies of the communication structures of these organizations."


• Keep the session timeouts (and the dead time before that) in mind. (Not only when speaking of 'concurrent users'). Ideally it should be set to one standard deviation past the average think time.


• Consider involved threads when using resource pools - use a resource pool size equal to the number of threads to guarantee that every thread immediately gets the resource it needs.


• AJAX should be called AJAS because the JavaScript object notation (JSON) format is much better suited (easier to parse and less chatty) to transfer data. (Yes, we knew this one before. Honestly.) However even JSON has a dark side. Its gates are eval().


• There is another reason behind using Cascading Style Sheets instead of HTML tables besides conciseness and code organization: bandwidth.


• Only starting a new thread is more expensive than creating a database connection.


• Make your application cache configurable.


• Use soft references. (Java has it. Does .NET?)


• Load-balanced clusters do not scale linear due to overhead in heartbeats and state synchronizations. Fully load-balanced farms almost do.


• The ZOI paradigm of software design should be considered in QA.


• Don't mix production configuration with basic plumbing (like DI) in the same configuration file.


• There is a project called Recovery-Oriented Computing (ROC).


• The 3 phases of Zero Downtime Deployment: Expansion, rollout and cleanup.
  
  
• The difference between white- and black-box (monitoring) technologies: The first are running within the system under observation while the second reside on the outside and are not known by the system itself. Naturally black-box technologies are lesser coupled to the system.


• Colonel John Boyd and the OODA-Loop can be mapped to an iteration in agile development.


• The author brings up a nice definition of cohesive in software design: "...In other words, if a set of methods touches only a subset of the object's state but is unaffected by other aspects of the object's state, the object is not cohesive."


• ...and many many more...
  

I have read the book cover to cover and can recommend it to anyone interested in delving a little deeper in the subject.