Scalability Rules for managers and startups
Abbott and Fisher’s previous book, The Art of Scalability received good reviews for shifting the way we think about scalability from merely splitting databases and adding servers, to include the human factors that weigh heavily on its success. Together with the authors’ distinguished pedigree (PayPal, Amazon, and eBay between them), I picked up a copy of their second book, Scalability Rules – 50 Principles for Scaling Web Sites without a second thought.
If Art was about laying a strong foundation for a scalable organization then Rules is the reference point for when you actually tackle the growth challenges. It acts as a reminder when you come to a crossroad of decision-taking, to keep with the principles of scaling. Each guiding principle is clearly explained and illustrated with examples. It also prescribes how and when to apply the rules.
For example I found many rules focused around people and processes such as #27 “Learn Aggressively” and #30 “Discuss and Learn From Failures”. Then there were many rules centered on application design and developement such as #17 “Don’t Check Your Work” and #35 “Don’t Select Everything”. I found myself agreeing with rules for architectural decisions directed to the operations team such as #11 “Use Commodity Systems” and #12 “Scale Out Your Datacenters”.
With my tendency to categorize things, (or in this case recategorize the chapters) I tried to fit the rules into their respective pigeon holes, although I did struggle with that. While they didn’t all fit neatly, the groupings I could come up with were:
- Application Design Rules
- Architecture Design & Implementation Rules
- People and Process Rules
- Network Related Rules
- Caching Rules
- Availability Rules
Who needs Scalability Rules?
Looking at the fifty rules divided up this way, summarizing the book becomes easier but still a bit muddled. For example I might ask the question, Who exactly is the book’s audience? Is it application developers? Certainly, there is a large section of rules designed for them. Or maybe it’s for the operations team, offering advice on how to design systems, networks and data centers, and advice for optimizing and redirecting development efforts? Or maybe it is a book for managers, as the people and process related rules certainly are targeted towards those folks. But if that’s the case then much of the book is probably too technical for such an audience.
Ok, so let’s step back, when or why might you have all these crisscrossing themes and roles? The answer is that like me, the authors are consultants and in the course of engagements a consultant is often asked to wear many different hats. So sometimes we’re looking at scalability in regards to operational decisions, while at other times we’re looking at scalability through the lens of application design decisions. And still other times scalability can best be achieved by focusing on people and processes. I’d add that not only is this a handy reference for consultants, but for any bootstrapping startup as well. Coders these day are expected to be at least a little bit knowledgeable with web operations, and vice-versa. Especially pushing towards the guiding principles of devops, this book can help engineers take a critical look at their roles within an organization.
Looked at in that light you can really see how this book is truly an opus of knowledge on scaling web sites. Although the organization is sometimes confusing, it will surely bring insights and enlightenment to all of your teams, whether operations, devs, managers, or business units.
