This is a book of advices on how to make the system running. Not just to write and release it (no pun intended), but to keep it running after the release.

The book is about prior planning for capacity and stability, designing systems capable of handling the load while being resilient and fault-tolerant, build it in a maintainable and adaptable way, so that it lives through the years. A great deal of information in it too.

Overall, it was a pleasant reading, because in most parts it matches precisely what I'm doing on my job and what I've learned to be the right way of doing through hard experience. As always, such practical convergence with published material is very comforting.

Why did I give it 4 stars then ?

Because the book itself needs more work.

It is poorly structured and is stylistically informal. It doesn't have a plot, but it is also not a collection of independent essays or articles. Near the end it feels like the author just gave up the structure and stuffed the book with random thoughts.

Despite the author's promise for each part of the book to have a case study, only 3 out of the 4 unconnected book parts are opened with one, and the studies are of anecdotal nature. A few pages of horror in everybody's eyes to find out that a janitor had accidentally pulled the plug, something like that.

As the few architectural patterns suggested by the author reside near the middle of the book, the first half is full of forward references, like "but wait till you see the MagicPattern !". The patterns when you encounter them are useful but are explained shortly and in informal manner again.

A lot of assorted hints, ranging from TCP handshaking to stripping whitespace off web pages and wrapping a web service around a database. Interesting, but inconsistent.

It is difficult for me to be unbiased about a book like that, because, like I said, it correctly describes many of the practical considerations that I already knew in the first place.

I'd say it is the kind of book for the architects with development past. It will be useless for you unless you have a lot of practical experience as a developer. On the other hand, if you are a beginning developer, it won't help much either because it doesn't offer any analysis or any kind of formal textbook kind of information.

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

This book offers very sound advice, based upon Author's years of experience. Every serious developer/architect should own it. The only reason why I gave it 4 stars is that the book is devoid of code; it would have been % star plus, book had Author put some code samples there (even pseudo code or more diagrams).

Unlike many books (such as those with animal kingdom on their cover or photos of several programmers) this book is by/for a real software engineer with real life production ailments and antidotes for them. Even if all the use cases discussed here may not be applicable, if people follow at least 50% of those that apply I think there will less business outages, better user experience and a happier IT department.

On top of all the good technical stuff, this book also happens to be well written - enough to be just enjoyed for the anecdotes and such.

A must read for any software engineer of web applications!

I just completed reading Release It! by Michael T. Nyggard (Pragmatic Bookshelf 2007). It is part of The Pragmatic Programmers series. I have read the book cover to cover twice. At first, I thought that the book was just another book on how to manage projects. So What! The ideas presented in the book were common sense. I have been doing these same things for many years.

Then one day I was working on a project, and was trying to figure out how to handle a problem. I remembered what I read in Release It! about the topic. I grabbed the book off the bookshelf and looked it up; logging. The ideas presented are common sense, but how often have we missed to boat. The ideas presented in the book I implemented much to my own joy. The result was a customized deployment of the Java Logging system which is simple to maintain and does not require external libraries.

It was at that point I realized the brilliance of the book and the pragmatic side of things. I re-read the book. As an architect, project manager, developer, and maintainer of complex software ecosystems, the ideas in the book provide a "pragmatic" common sense approach to handling situations. The book is a learning tool, one person's personal perspective on software design and deployment, and a reference. It is an all-in-one book.

This book provides a great tutorial on how to manage complex projects for the novice, and a gentle practical reminder to the seasoned architect/project manager.

The book is divided into 4 major sections: Stability, Capacity, General Design Issues, and Operations. The first two sections provide the basis for the remainder of the book. The Stability and Capacity sections have divided the topic into an explanation, followed by general design patterns and anti-patterns. It explains in enough detail how to implement good patterns and recognize bad ones.

The section on General Design covers items like Administration and Security. There is nothing earth shattering in these sections, but they do provide a basis for a "check list" of items to make sure you consider in your designs.

The final section on Operations is the one where you will make friends with your administrators and keep your sanity. The portions on designing for monitoring including logging will be your savior at 2:00 AM in the middle of a blizzard. The discussion on designing for the future does not get enough attention in our modern get it out the door now world. This may be the push you need to think about it.

This is a book to have on your bookshelf. Mine is full of tabs and post-it notes.

There are dozens of technical books on my bookshelf, most of them quite good... but none as relevant and valuable an addition as Release It! If you are a professional involved in the development, deployment, and production support of modern information systems it is in your interest to get a copy of this book and (unlike many a technical manual) *actually read it*

If you are looking for a low level book that gives you code examples and helps you implement things then you are looking in the wrong place. This book is an excellent book at high level help. The reader will have to do their own homework in the sense of application. However, I think that most programmers should read this to make themselves aware of these things. I got sick of hearing things that were unique to Java as well. But if you can get over these things then you'll like the book.

What a great book!

Thirteen years ago, when I changed careers from manufacturing engineering to software engineering, my mentors started me on my way by having me read 'Writing Solid Code' and 'Death March' and something very confusing at the time, 'A Pattern Language: Towns, buildings, and construction' by Christopher Alexander, an architect in the original sense; a designer of buildings. (At the time, there were no design patterns in software per se and no software design pattern books.)

This book is what I would give to anyone starting out in programming today. Programming languages are only tools; this book explains why we have them and how to use them.

Brilliant!

Nicely done, Mr. Nygard.

Wayne Martin

The first few chapters of this book were very impressive. Unfortunately, my 2IC stole it from me several weeks ago, and has thus far resisted all entreaties (and threats) to return it!

I'm expecting it again in a week or so, whereupon I should be able to complete it, and this review.

From what I read so far, it's a 4.5-star effort (so it's getting 5. )

Required reading for anyone who develops non-trivial applications for use in the real world (TM). The author appears to have considerable experience, if the war stories that can be found throughout the book are anything to go by... The book focuses a lot on what to do (in order to avoid specific catastrophes), but sometimes has to skip over the details of how to do it -- which of course wouldn't be possible without going into details about specific products. I'd love to see a companion book along the lines of "Release It (with Open Source)!" :-)

This book helps you to understand why creating production ready code requires work at many levels: creating the deployment architecture, operations scenarios, and just plain writing code and testing. The book covers issues that every architect, developer and release engineer should know. The book has principles, patterns, and resources to help you identify production problems, prevent them, and survive them when all else fails.

One of the better features of the book is the stories that help you to understand issues and demonstrate that Nygard's lessons are based in experience. The lessons are (as the name of the series suggests) pragmatic, and each chapter leaves you with enough information to make changes to improve your application.

In books of this sort there is a balance between "principles" that are timeless and "how to" techniques that you can use immediately. This book is biased slightly towards Java, and contains a few references to current tools, there are enough general principles that there is little in the book that will date it.

As I read the book I found information about many topics that arose in each project that I have worked on, as well as things that I felt that I needed to learn more about.

After I finished the book I felt energized to do things better. If you build enterprise applications buy this book to learn how to build more production-ready applications. If you already know the lessons in the book, buy a copy or two for your colleagues who may not so that your life will be easier and you can get fewer late-night phone calls about a system you helped build.

Once in a year, I tag a book as "book of the year", the best book I read during the year. 2007 is not over, but this my "2007 book of the year", I know that.
Frankly, I just bough this book because it's published by the "pragmatic programmers" and I trust these guys. The title is not even appealing. I knew quickly that I will discover many things.
For a long time, I wonder what to do to build up a system which is fine in production, but I didn't understand quite right what was needed (I know now that I really misunderstood the problem). The first thing that came to my mind was to make the software strong (a good thing to do by the way) ; the second thing that came to my mind was to make it really, really strong (which starts to be stupid).
Michael helps us to understand that systems fail anyway. But it should fail fast (and can often fail only partially), it must facilitate diagnosis and quick restart. And design must deal with that. But the author doesn't stay in general considerations, he points out specific patterns and antipatterns for the systems design, by means of stability and capacity. The vast majority of article tend to exposes how new technologies make the life so easy. The author revisit technologies and technical choices throught the production glasses: why AJAX should be considered with care, why we must think about pre-computed pages instead of ynamic composition in some cases, why caches is not a one-size-fits-all answer and so on. Another important point well illustrated: a system is software + hardware and the architecture must be though with physical deployment and hardware architecture in mind. Promotion of full independance of the architecture over the deployment is plain wrong. There are so many subjects tackled her, I can't speak about them all, sorry.
Michael knows his stuff, because he worked on very big e-commerce sites and his horror stories (they are numerous) are quite impressive. Maybe you don't work for a huge e-commrce site ? I don't. Believe me, the lessons learned here are still valuable, because they are emphasized by the size of the system.
This is a 334pages long book, with not so many pictures. I tend to prefer short books, simply because it takes time to read books. Here, each word count, it's not too long, for sure.
Oh, one last thing. I hate to give 5 stars. To deserve 5 stars, it must be hell of a book ! It is !!
Great job Micheal, please notify me for the next one.

The subtitle of this book might as well be Architecture and Design for the Paranoiac. The book lays out some critical aspects to creating and rolling out stable software systems. It's directed to those working in the enterprise arena and need the utmost from stability, capacity, and overall design. Nygard's definition of "enterprise" is somewhat broad in that he considers "enterprise" to be any system providing mission-critical support to a business. Regardless of how you define your particular software, I'm sure you'll find something useful in this book.

Nygard presents the book from an anti-pattern/pattern approach: he uses case studies to illustrate how critical errors in design or implementation (anti-patterns) have caused disasterous outages. He then moves on to show how application of solid design patterns could have avoided the problems. He also spends some time going in to detail on how some of the outages have happened, including brief discussions on network packet captures and decompiling third party drivers.

There are a lot of solid fundamentals in the book: dealing with exceptions at system integration points, thread synchronization, avoid rolling your own primative feature libraries such as connection pools, and make sure to test third-party libraries which play critical roles. The general approach of discussing anti-patterns followed by patterns is also a nice way of putting forth the material.

There are a lot of more complex bits covered as well, such as thinking ahead on how you'll deal with bots and crawlers, avoiding AJAX overkill, designing ahead for and using session. I also liked that Nygard talks about the importance of involving the customer in decisions on thresholds and other critical boundaries.

Despite the great content, there is a blistering flaw, IMO: A complete lack of solid implementation specifics. Nygard doesn't provide much detail at all on actual implementation of the critical patterns he espouses, nor does he point you in the direction of other sources of information. For example, the Timeout pattern is held up as a vital aspect in many parts of the book; however, there's no practical detail on actual code to implement a Timeout, and there's only one reference to a practical implementation. The Circuit Breaker pattern, central to many of Nygard's architecture assertions, doesn't have any code or a single reference to other material where you can find implementation details.

While I find that a major gap in the book, otherwise I think it's a solid addition to one's bookshelf. The writing style's very nice, his writing voice is light and concise, and the summary bullets in each section ("Remember This") are of great value. Additionally, there are plenty of references to other useful works. (Just not for the patterns I complained about above.)

Many of the texts on software engineering discuss following some methodology to produce an ideal design. Working developers quickly learn that the ideal is rarely reality and things happen once we release software out into the wild. Michael Nygard's "Release It!" picks up where these other books leave off.

Nygard talks about all the things that can and will go wrong in the finely crafted software we were sure was ready for production. A full two-thirds of the book is focused on capacity and stability issues including patterns and anti-patterns for both. The remainder of the book deals with general design issues as well as maintaining health and status in an operational system. "Release It!" provides many first hand accounts to illustrate his points, beginning with the Exception that grounded an airline, and these stories serve as excellent motivators. It's better to learn from the mistakes of others, and I really appreciated the detail Nygard went into addressing some of these horror stories.

The Pragmatic Programmers have a few "must read" books and "Release It!" is another one. After reading it and heeding its advice, you'll feel a bit better knowing that your software is better prepared for the rigors of production.

This book is intended for architects, designers, and developers of software on which a business depends and whose failure costs money. The tone is informal and the style is easily read. Some architects may wish for more rigor and consider it too easily read but they might still benefit because it contains quite a bit of wisdom earned by experience.

The book discusses issues of uptime, failure, and maintainability with examples drawn from the author's experience and from other industries. Making the point from more than one point of view serves to drive it home.

This is not a programming book but the illumination of a problem is often improved by a snippet of code. The code is Java and is easily read by anyone familiar with programming. Having some familiarity with multi-threaded programming in following the explanations and their examples will make them a little easier to read but is not necessary to get the point. (Even if you truly have no knowledge of Java, looking up JDBC, JVM, EJB, JSP, J2EE, log4j, and servelet will not be much effort because not much knowledge of them is required.) The examples emphasize web applications because, I suppose, that's the environment most vulnerable to huge capacity requirements, more complex environments, more numerous causes of failure, and failures that are more visible.

The author's analysis of the problem space has two dimensions --- stability and capacity --- in which a given enterprise system can be located. The analysis also has two categories: general design and operations.

Stability and Capacity
A given coordinate, on the stability axis, for example, implies the presence and absence of features that improve and diminish stability. A feature that contributes to stability is the use of timeouts and one that detracts is the presence of many interfaces to other systems. The author identifies 8 such stability patterns that contribute to stability and 11 antipatterns that detract from it. Capacity has 4 patterns and 10 antipatterns.

General design and Operations
These two categories are less structured than those of stability and capacity.
"General design" contains advice about networking (integration with local and remote servers), security (principle of least privilege and managing passwords), availability (load balancing and clustering), and administration (QA vs production environments, configuration files, anticipating failure in start-up and shut-down, and an administrative interface).
"Operations" contains advice about recovery-oriented computing (surviving failure by restarting components, et al.), transparency (allowing a view of the system's internals), and adaptation (managing change).

The idea of patterns from software development is raised from the level of programming to the level of systems. I might have called them, for example, stability patterns and anti-stability patterns but the author's meaning is clear enough.

At the end of each pattern and antipattern section is a short and effective summary that begins with "Remember this". The design chapter has a summary and the operations chapter has two section summaries. The author clearly has in mind the reader's take-home lesson and the possibility that the book may be skimmed to reread a section. The book is cross-referenced, forward and back -- if an idea of current relevance is explained elsewhere in more detail, the page number is noted. For example, if an antipattern has a countermeasure identified by a pattern, then the relationship is noted with a page number.

Implementing some suggestions may make the QA phase of testing easier by making diagnosis and (white box) testing itself easier. If you want to design your software to be more reliable and easier to maintain after the QA phase of testing, then this book is for you.

The book has a good tone. It's as if the author is giving an informal tutorial on different problems and their possible solutions. Although many times glossing over details I would recommend this book for any average developer. The book at the very least gets you thinking about a lot of different topics. The author explains some patterns & anti-patterns in sufficient detail. Some tech errors and typos but the scope of the book is awesome and very enlightening. As a developer this book gives me insight into the problems architects and Sr. level developers deal with. A very good read @ 333 pages

The book has a good tone. It's as if the author is giving an informal tutorial on different problems and their possible solutions. Although many times glossing over details I would recommend this book for any average developer. The book at least gets you thinking. The author explains some patterns & anti-patterns but I wish he would have done so in a more traditional way and in more detail.
Unfortunately, as with most 1st edition tech books, this book lacks good editing. Tech errors, wrong word choice, and referencing future chapters are some signs.

§
Going through the book, I kept flashing on a "Simpsons" episode where Homer is convinced he is going to die before morning and imparts words of advice to Bart. Bart, uncharacteristically, is all ears and remarks in surprise "This is good stuff!" Developers of enterprise-level software will certainly repeat the same words while studying this book.

A key element of interest for those same people, often too busy to read books, is that "Release It!" is organized around case studies that the author says are "taken from real events and real system failures that I have personally observed. These failures were very costly --and embarrassing-- for those involved."

Pragmatic life experience sets the tone for the book. For starters, follow the dramatic story of the failure of a software system at a major airline, then follow the analysis of what went wrong at a very concrete level. Further, abstract it to get the full value: "How do we prevent bugs in one system from affecting everything else?" That is the cycle of the book.

I don't quite see things at the higher level of the author. I work the HTML/CSS/JavaScript front ends of Java and Ruby on Rails browser-based application development. Still, my years of experience at this level affirm the statement of the author when it comes to enterprise integration: "Despite lip service, companies didn't really get off the starting line for enterprise integration until they needed to create dynamic websites. Those projects were the impetus that finally forced many companies to integrate systems that have never played well together." Amen brother.

Michael Nygard's "Release It!" is a valuable transfer of knowledge which will be appreciated by a broad layer of people in our field. As an advanced practitioner and advocate of modern W3C coding practices and Cascading Style Sheets, it was personally very gratifying to see someone with Nygard's level of view so clearly state the value of CSS and my own small part in this complex process. Thank you.
§

It is the decisions that you make during development that will affect the quality of your release. Release It!: Design And Deploy Production-Ready Software was written to help you understand what causes good software to go bad, and to show you how to take control of the situation when it happens.

Release It! was written for architects, designers, and developers of enterprise class software systems. This includes applications, websites, web services, and EAI projects. According to the author, "enterprise class" means if the software stops, the company loses money.

All in all I found Release It! a very easy read. While the author comes from a Java and Unix perspective, the book's focus is generally neutral and grounded toward concepts and techniques that are portable across all platforms and technologies. Each of these case studies is based on real events, only the names (of people, companies, methods, and classes) have been change to protect the innocent. The detail of the information is very helpful, giving insight into the problems and their solutions.

My full review can be found over at Blogcritcs, but if you are looking for a better way to deliver your product, a way to avoid the traps and pitfalls, then Release It! is a good place to begin.