If you ever "go live" and start getting the "oh sh#$" queasy feeling, you need to read this book.
To be perfectly clear, this is not a software design patterns book in the mold of GOF, POEAA, POSA etc, though it is chock full of failure scenarios and how to handle it. This book is not about how to pass QA(zero high priority bugs & deliver all functionality), but how to design your system for the real world. When your user base multiplies by a factor of 10 and you still need to handle the 5 9s; when an external dependency fails or responds sloooooowly; when you run out of threads etc.
Buy it, read it and become a better engineer.
-Venu
Helped me fix broken software.
As a project manager working on enterprise systems in a Fortune 500 company, I find myself coming back to this resource frequently -- maybe too frequently, as software has an amazing ability to fail in ways I don't expect. My development team has gained much from stability patterns outlined in this book, such as circuit breaker and bulkhead. I highly recommend this book as a guide to working in the real world of releasing software. -Greg
Enjoyed it
I am halfway done through it. I have worked on e-commerce product for about 2 years. Didn't realize before reading this book the horrors a production system goes through. Definitely it is going to motivate me to work for a production ready software for my next projects.
Application Architecture and Integration in the Real World
I've recommended this book to many colleagues of mine and haven't heard a disappointing review to date. I've heard the terms `pessimistic' and `realistic' used with equal frequency to describe this book. Having just completed my second reading, I can affirm that these terms are both representative take-aways. Nygard openly admits to being more than a bit paranoid about the way he approaches enterprise application architecture. Although this may seem alarming to many new to the IT field, those of us who have been around for a while recognize this as a necessary, at times life saving, defense mechanism.
Despite the presence of patterns, this is not really a pattern book that can be read piecemeal. It's best read and enjoyed end-to-end. The books serves to teach us old dogs some new tricks as well as serving as a way to say "welcome to the field of enterprise application architecture" to team members new to this role.
Book Strengths
--------------
* Real world production incidents, just in case you think: (a) you're the only one who ever gets into such situations; or (b) such things don't happen in the real world with large enterprise applications (where do you work?)
* The patterns. Even though there's no sample code, the real value is in describing and cataloging these patterns.
Book Weaknesses
---------------
* Organizational inconsistency. Two sections of the book (Stability and Capacity) follow the anti-pattern / pattern approach while the other sections of the book (General System Design and Operations) follow more of a narrative approach.
Yeah, the book focuses almost entirely on Java-based systems but almost all of the book has direct applicability to other enterprise technologies. In the last chapter of the book, Adaptation, Nygard's writing style tends to wander a bit and deviate towards a rant. However, it's hard to fault him for this, especially when he states things so eloquently:
"Real enterprises are always messier than the enterprise architecture would ever admit. New technologies never quite fully supplant old ones. A mishmash of integration technologies will be found, from flat-file transfer with batch processing to publish/subscribe messaging. Any strategy formulated predicated on creating a monoculture--whether it is a single integration technology or a single programming language--is doomed to be a costly failure."
Practical Stuff
This book contains practical knowledge which I had to learn through hard knocks and falls. If I have this book 7 years ago, a lot of bloody-nose and and late nights would have been prevented.
This book contains valuable architecture stuff from both software development and infrastructure know-how (E.g. clustering, availability) which many architect lacks in today's (silo-based) IT industry.
It also speaks about the conflict of interest between users, developers & operators & administrators.
I would have given it 5 stars if the writting style is more consistent and the flow of thoughts is more structured.
Nonetheless, this is the best architecture book I have read.
