Become a fan of Slashdot on Facebook


Forgot your password?

Book Review: Scalability Rules 54

eldavojohn writes "As a web developer in the 'Agile' era, I find myself making (or recognizing) more and more important decisions being made in developing for the web. Scalability Rules cemented and codified a lot of things I had suspected or picked up from blogs but failed to give much more thought to and had difficulty defending as a member of a team. A simple example is that I knew state is bad if unneeded but I couldn't quite define why. Scalability Rules provided this confidence as each of the fifty rules is broken down in a chapter that is divided into what, when, how, why and key takeaways. A strength of the book is that these rules cover all aspects of web development; but that became a double edged sword as I struggled through some rules meant for managers or technical operators." Read below for the rest of eldavojohn's review.
Scalability Rules: 50 Principles for Scaling Web Sites
author Martin L. Abbot and Michael T. Fisher
pages 272
publisher Addison-Wesley Professional
rating 8/10
reviewer eldavojohn
ISBN 978-0321753885
summary 50 Principles for Scaling Web Sites
You might recognize the authors as two of the three partners of AKF Partners which means that the book pushes a lot of their concepts like the AKF Cube. A bonus is that they have a very long list of clients and aren't afraid to remind the reader that they have consulted to hundreds of companies so when they say they see these rules solving problems frequently, there's weight to that. Also, they have two books but don't confuse Scalability Rules with The Art of Scalability as the latter focuses on people, processes and technology instead of the rules of scaling.

First off this book gives you a primer of rules for you to start with depending on whether you are mostly a manager, software developer or technical operations personnel. I'll concentrate on the specifics of the software developer chapter and summarize the others at the end of this review. Also note that aside from some SQL, I only saw PHP code in this book. Luckily there's only a handful of snippets presented and they are easy to follow. Additionally each chapter ends with solid references (usually online resources) to back up the claims listed in those sets of rules.

The first chapter is devoted to reducing the equation and focuses on removing needless complexity from your solution. You can find this chapter here if you want to see how the layout looks. They give a lot of solid reasons for this and also a lot of good examples like understanding what your users care about. Why build a prompt to export a blog post as a PDF if 99% of the users don't care about it? Next up they say the rule to design to scale means designing for 20x capacity, implementing for 3x capacity and deploying to 1.5x capacity. A strength of the book are the grids that illustrate what is low, medium or high cost and impact through the chapters. Every time they discuss options at different parts of the solution development process, the user is given a chart to understand why. The next rule stresses that you can usually identify 80% of your benefit achieved from 20% of the work (80-20 rule). Rule 4 is strangely specific and implores the reader to simply reduce DNS lookups. However — and this is the first of many — they remind the reader that this rule must be balanced with putting your system all on one server just to reduce DNS lookups. Such a strategy can result in that becoming a choke point. Rule 5 quite simply instructs the reader to use as few objects as possible in your webpage.

The final rule of chapter one is the first one I disagree with in the book. The rule says "Don't mix the vendor networking gear." And this goes against every fiber of my being. Why even have networking standards if you are not to mix the vendor networking gear? Looking to upgrade one component? Better stick to brand X no matter how crappy they have become. This results in being nickeled and dimed and vendor lockin. If scalability is your sole goal than perhaps this is sound instructions. But I cannot understand how anyone would indicate lockin to a vendor — especially in today's networking gear.

Chapter two is incredibly short but potent. It covers some basic database concepts like why ACID properties of databases make them difficult to split. This chapter is spot on and calls upon the AKF cube for dimensions of scalability. Three dimensions are: You can clone things, split different things and split similar things (like by country region). This cube reappears throughout the book and it should be noted that the book does a good job of giving examples of when each dimension is a good choice for scaling and when it is a bad choice compared to the other two. In my line of work, massive scaling solutions have implemented all three.

Skipping to the next developer chapter on not duplicating your work, the text ranged from the incredibly obvious "Don't double check your work" to relaxing temporal constraints. The chapter is short like chapter two and didn't offer me a whole lot. A third rule was again oddly specific in saying not to do redirects and even getting down into the very fine specifics of what HTTP codes are and how they affect your response times.

The next chapter for developers is chapter ten on avoiding or distributing state. Rule 40 actually came in useful at my job as it simply states "Strive for Statelessness." There was an easy solution to a problem in one of our projects that involved storing an object in the session to keep track of what was being displayed to the user. Having read the book, I instead made this web application nearly stateless (except user authentication and the like). Later on, as we started testing the application in multi-tabbed browsing and users began opening many search tabs and viewed several objects at once to compare them, I was glad that I had not gone down this path. Doesn't have much to do with scalability but I think all web developers should read this chapter as it really does pay to avoid state when possible.

As the rules grew closer to 50, they lost their potency. The authors did a good job of trying to put a bit of ranking in the appearance to these rules. The final developer chapter on asynchronous communication and message buses is probably the most specific and was the least useful for me. While all the rules in this chapter are true, they again border on the banal with examples like "Avoid Overcrowding Your Message Bus."

Having read this book cover to cover, it is a very short book with extremely succinct and organized summaries (the final chapter is a short review of each rule). The manager and operations chapters didn't really do a lot for me overall but would occasionally have very interesting chapters that opened up a lot of the logic behind content delivery services to me. Occasionally I would take slight issue with some rules but the most egregious rule I read was Rule 28 "Don't Rely on QA to Find Mistakes" and then the chapter opens with calling the title of this rule "ugly and slightly misleading and controversial." Because it is and could probably be replaced with another sentence from the chapter: "You can't test quality into your system." Why rely on sensational headlines when I'm already holding your book? I think this book would have been a solid 9/10 if not for this oddity in the large rule set.

I've given each of these rules a decent amount of thought and will keep them at the back of my mind as I write code in an agile environment. Mistakes made early on can be very costly in scaling terms. This book will definitely be kept around at work when I need a solid argument for those design decisions that might take more work but save in the future when it needs to scale.

You can purchase Scalability Rules: 50 Principles for Scaling Web Sites from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.


This discussion has been archived. No new comments can be posted.

Book Review: Scalability Rules

Comments Filter:
  • by wabb ( 2459758 ) on Wednesday September 28, 2011 @07:36PM (#37548018) Homepage
    Hi folks - I'm one of the authors. All good answers in here and all correct. One throat to choke is a great response with which we agree. The point in our book though is along the lines of the "it should work, but it doesn't" statement already given. Most vendors implement proprietary protocols that they claim to be consistent with RFCs 792, 1058, 4271, 5340 (ICMP, RIP, BGP, OSPF for IPV6) and others . These RFCs are loose enough to allow for differences in implementation. This in turn can cause a bit of a "stacked dependency" problem where 2 or more providers' gear works correctly IAW the RFCs, but not always with each other. Based on our analysis of many companies (n>200) and our personal experiences at both large and small companies the best solution is just to stick with one provider. Specifically, we often see device communication errors between providers as one of the top 5 reasons for down times across our client companies where they have heterogeneous networks. The most common fix is to replace with homogeneity - take your pick of provider. The problem is exacerbated in that device providers don't test each other's equipment communication as well as they check their own. So more problems are bound to occur. It's really not that much different than the browser problem where your site may work with 3 browsers but get jacked up with another 2. If you haven't had problems, it may not be worth fixing. If you are designing from scratch, our view is that it's best to stay homogeneous. Thanks for the review and the perspective!

"If value corrupts then absolute value corrupts absolutely."