Author: Martin L.Abbott & Michael T. Fisher
Publisher: Addison-Wesley, 2011
Pages: 272
ISBN: 978-0321753885
Aimed at: Web developers, architects and managers
Rating: 4
Pros: Well thought-out, readable style
Cons: Format leads to repetition
Reviewed by: Alex Armstrong

This small format book is summed up in its subtitle-"50 Principles for Scaling Web Sites". How useful is it?

The preface to this book states that "it is meant as a primer, a refresher and a lightweight reference manual to help engineers, architects and managers develop and maintain scalable Internet products". It goes on to discuss its relationship to a previous book by the same authors, The Art of Scalability and explains it that while the earlier book covered the "people and process concerns" around scalability the present volume expands on its third, technical section.

Recognising the need for scalability to be treated as a discipline the authors have adopted this rules-based approach and have devised a standard format for introducing each numbered rule. Each has an imperative title. Rule 1 Don't over Engineer the Solution is an example of a negative one. The positive ones omit the "Do" so Rule 2 is Design Scale into the Solution. The summary at the start of each rule goes through What, When, How and Why. What is a restatement of the principle - so Rule 1 is reformulated as "Guard against complex solutions during design", and for Rule 2 we have "An Approach to provide JIT (Just In Time) Scalability. When gives the scope of the rule; How gives some pointers - sometimes as a bullet point list and Why is the justification for the rule in terms of its benefits or the problems it avoids. Finally each rule has Key takeaways; a short paragraph that encapsulates the reasons for adopting the rule.

The fifty rules are contained in eleven chapters all but three of which have chapter titles that express principles in their own right. Each rule, usually covering three, four or more pages, is discursive and packs in a lot of information. So as not to overwhelm readers the preface picks out which five chapters of the book have priority for managers, for software developers and for technical operations and this is indicated in the following list:

Chapter 1 Reduce the Equation (6 rules; Managers; Developers)

Chapter 2 Distribute Your Work (3 rules; Managers; Developers; Technical)

Chapter 3 Design to Scale Out Horizontally (5 rules; Technical)

Chapter 4 Use the Right Tools (2 rules; Managers)

Chapter 5 Don't Duplicate Your Work (3 rules; Developers)

Chapter 6 Use Caching Aggressively (7 rules; Technical)

Chapter 7 Learn from Your Mistakes (3 rules; Managers)

Chapter 9 Design for Fault Tolerance and Graceful Failure (4 rules; Technical)

Chapter 10 Avoid or Distribute State (3 rules; Developers)

Missing from this list is Chapter 8, where there are five database rules for Technical operations:

Rule 31 - Be Aware of Costly Relationships

Rule 32 - Use the Right Type of Database Lock

Rule 33 - Pass on Using Multiphase Commits

Rule 34 - Try Not to Use "Select for Update"

Rule 35 - Don't Select Everything

Chapter 11, where Software developers will find three rules for Asynchronous Communication and Message Buses:

Rule 43 - Communicate Asynchronously As Much As Possible

Rule 44 - Ensure Your Message Bus Can Scale

Rule 45 - Avoid Overcrowding Your Message Bus

and Chapter 12, which has five miscellaneous rules and is a priority for Managers:

Rule 46 - Be Wary of Scaling Through Third Parties

Rule 47 - Purge, Archive and Cost-Justify Storage

Rule 48 - Remove Business Intelligence from Transaction Processing

Rule 49 - Design Your Application to Be Monitored

Rule 50 - Be Competent.

The books rounds out with Chapter 13 Rule Review and Prioritization and presents a risk benefit model for evaluation scalability initiatives. It looks at the competing concerns of availability and scalability and proposes a method of risk decomposition that it then simplifies into high, medium and low risk reduction. It also divides the cost of implementing solutions into high, medium, and low and then applies a simple prioritization equation: Risk Reduction minus Cost equals Priority (R-C=P) It then gives a table that shows how the two three-category scales for R and C give a five-point scale for Priority from Very High 1 to Very Low 5.

The final 25 pages of the book then restate all the rules with their R, C and P values included in three additional lines in the record card, followed by a list that categorizes all the rules according to their priority.

In some way this final section is the most valuable of the book. As the authors point out in the concluding summary, if you are starting from scratch then trying to incorporate as many of the principles as possible is a good idea. But if you are trying to re-architect an existing web-based business then knowing how to prioritize your efforts is a good idea.

How valuable you find this book depends on your prior knowledge and skills but while each rule is stated in a simple manner there is in-depth discussion around each which will be of interest even to experienced developers.