The Art of Scalability 63
Martijn de Boer writes "Creating high performance growing networks is really a special skill managers and network architects should possess to be ready for the future. The Art of Scalability is a book written for these kinds of functions, and prepares you for the present and the imminent future. Scalability is achieved by principles that work on many levels within enterprises, whether it's processes, organizational structure or setting up your project, this book covers it all." Read on for the rest of Martijn's review.
The sub-title for this book is "Scalable Web Architecture, Processes and Organizations for the Modern Enterprise" which is basically a catchy title for project managers and decision makers. It's just catchy enough to grab the book from a shelf and start digging into the table of contents, which is exactly the spot where you get hooked and decide to get the book. The book is written by two experts on the subject; both of them have a strong background in large corporations dealing with scalability. Throughout the book the authors shine a good light on tools and cases used for making a project scalable.| The Art of Scalability | |
| author | Martin L. Abbott and Michael T. Fisher |
| pages | 592 |
| publisher | Addison Wesley |
| rating | 8 |
| reviewer | Martijn de Boer |
| ISBN | 0-13-703042-8 |
| summary | Explains everything from organizational processes to the techniques used to accomplish a scalable high performance project. |
The book is divided into four sections which follow the process of starting a scalable project. First off you will need to know everything about strategy, organizational structure, the kind of people your organization needs and how to manage your team. The second part focuses on the how's and why's of scalability, aspects of planning for continuity, crisis and incident management. The later chapters in this second part talk about risks, how to value risk and the importance of testing to make educated conclusions about how far to scale your project, a notable mention here is chapter 19 which focuses on trade-offs in development speed or doing things the right way, often an underestimated point in these businesses. Architecting scalable solutions is the third part of the book, mainly taking a more technical approach to the matter. This part talks about containing faults and breaking up applications so they scale well. This goes all the way to scaling the database backend for your application to caching objects and making synchronous versus asynchronous calls to your application.
While most of the book is good for preparation, I think the fourth part of the book crosses the boundary from preparation to being very useful during the process as a fallback to your knowledge. It's titled accordingly "Solving other issues and challenges" and mainly focuses on things you will come across during the first and perhaps even later stages, providing solutions for unforeseen costs of data storage to monitoring your application for user experience, speed and the processes you will have to implement for this.
If you have read this far, and are thinking about how complex scalability really is, then you have found the right book. The clear writing style and detailed writing of numerous pitfalls for such big projects make this book a valuable asset to your knowledge base. It's also written in a challenging way, and between the lines there is also some humor (evident for instance in the reference to Rain Man in chapter 18), making it a fun way to learn or build upon a great skill set needed by organizations in the not so distant future. I feel very positively about the writing style of the book, but despite there being some illustrations there could be some more diagrams of organizational structure and the architecture of projects as I didn't find the illustrations adding much to the context.
The short appendixes to the book are mostly about calculating capacity for cpu power, bandwidth, etcetera. These appendixes actually provide sample calculations which are useful to backup your analysis when you need to make a bill of materials for your superiors and can also be used to better grasp the size of a project. Numbers mostly provide a context for the people above you, and I think these extra pieces of content could have deserved another part in the book, but perhaps it's better off as some food for thought.
Before starting with this book, I had not much prior knowledge about scaling projects other then some technical ideas of implementation. I always hate it when I know I'm just scratching the surface of something, and need to satisfy my urge to learn more about the subject. The Art of Scalability really helped me accomplish that, and provided much more background information then I expected. I was really surprised by the pieces about cloud computing, it's such a buzzword nowadays but the texts give it a real context.
If you are looking to set up a project or are generally interested by the concepts of scalability, then this is the right book for you. It's an appropriate recommendation for most businesses, because this knowledge can only be used to your advantage and just takes a little bit of time to read trough. It's a heavy subject, but once you finish the book you will be able to make a decision about architecture based on a good foundation of background information rooted in real situations.
You can purchase The Art of Scalability from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:How Marketable Will That Skill Be? (Score:4, Insightful)
Re:How Marketable Will That Skill Be? (Score:3, Insightful)
Re:How Marketable Will That Skill Be? (Score:2, Insightful)
Did you even look at the title of the book?
"Scalable Web Architecture, Processes and Organizations for the Modern Enterprise"
This has more to do than just processing power. Good Grief...
Re:How Marketable Will That Skill Be? (Score:4, Insightful)
I'm not sure that scalability will be all that relevant as long as Moore's Law continues to hold.
Ask Twitter or Facebook.
Moore's Law is helping them, I'm sure, but for really successful new websites, it's nothing compared to the influx of new customers to deal with. (And yes, it's Slashdot so we all must hate Twitter, but you have to admit they grew damned fast.)
I think you're overestimating the value of CPU power here. The real bottleneck is always data-- storing data in such a way that access to it is fast, but keeping it in a consistent state at the same time. Nobody would use Facebook or Twitter if it took a couple minutes for your status update to be visible by your friend.
Warning (Score:5, Insightful)
Unless you are actually working on a web site that needs to be scalable, thinking about scalability is both a waste of time and harmful. A totally unscalabe web app where each page view takes 1 second, can sustain 86k page hits per day or 2.5 million page hits per month. Will your web site see that much traffic? Really? If not, your main objective should be to get the site out of the door as soon as possible to keep development costs down. Hopefully, users flock to your site, melting the servers under huge loads of traffic. Good for you, you'll have a very profitable job designing the next scalable version of the site.
Or you get no traffic because the site idea was stupid to begin with. That sucks, but much less so than if you had spent months of effort making it scalable. "Scalable architecture" is merely a different form of premature optimization, and it is just as harmful.
Re:Warning (Score:3, Insightful)
Wrong, because 80k of those hits actually come during a 8-12 portion of the day, sometimes much smaller depending on the focus of the site.
Yes, its fine if you're never going to get anywhere near that kind of load, but load planning doesn't work in 'days' it works in hourly peaks and valleys if you want to look at it from a real rough perspective.
Ask some sites that get slashdotted how well capacity planning works when you get 120k hits in the first hour its on slashdot, and 10k for the rest of the day after it has moved down the list on the main page. Sure they could have easily handled the load with a little delay if they had built an app that loads in 1 second, IF the load was perfectly timed to send one request per second, which simply isn't the way it works.
Re:Warning (Score:4, Insightful)
"Your simplified model only holds true if all of those one second requests appear strictly one after the other. If all your eighty six thousand requests land over lunchtime, you might need to think about scalability."
A fairly good definition of "being slashdotted"
Re:How Marketable Will That Skill Be? (Score:3, Insightful)
Are you also fed up and sick and tired of the Windows-hating posts?
Yes.
Or IE hating posts?
Only the ones that don't acknowledge IE7 and IE8 exist, which is most of them. So... yup.
Or Apple-hating posts?
Yah.
I must have missed your impassioned pleas for those to stop.
Well, ok. I did a Windows one just a little bit ago... here it is: http://slashdot.org/comments.pl?sid=1531200&cid=30967046 [slashdot.org]
Is it really that wrong to want the level of discourse to rise above "moron" levels on this forum? Is it really so wrong that I object to reading the exact same comment a hundred times a week, that people get modded up for adding absolutely *nothing* we haven't seen a million times before?
Interesting that with all the griping and carping that goes on here, with all the rants against this product or this technology or that company, the one thing you decide to stand up and protect is...Twitter.
Maybe you should have waited for the answer to your questions before making assumptions. Because now you just look like an idiot.