Werner Vogels puts forth some coherent thoughts on Scalability (like we'd expect any less). I love the part about heterogeneity in long-lived products. Moore's Law is still in effect, and any architect that doesn't pay attention to this is naive. A good friend of mine once told me a story of a great architect who was developing a process control system in Smalltalk for a large semi-conductor manufacturing system. The architect knew that the project was at least 5 years in duration, and so he designed the system taking into account that computing power would have increased roughly an order of magnitude in that timeframe. Clever.
I've discussed scalability before, so I won't dwell on the difference between scalability and performance, but I did want to talk a little bit about what it means to design a system to be scalable and then verify that the design works.
First, let me reiterate and paraphrase the point that Werner makes so well: scalability is about adding resources to increase capacity of a system without imposing a deleterious effect on performance.
So, Jef, if scalability is about adding resources, what kinds of resources contribute to the scalability of an architecture?
Well, you could add memory, processors, disk, NICs, whole computers, data centers, (people?) ... you get the point. Resources that affect scalability scale from the very smallest computer components to the largest system of computers. Oftentimes, it is more interesting to discuss not the scalability of the system, but instead the marginal cost to scale a system. If I spend a couple thousand dollars on some new memory for a computer and I double it's capacity, then the marginal cost is very low. If I have to spend $50K for a new database server -- eh, not so much. So one things you need to do up front is figure out whether you are interested in maximizing the scalability of the system OR minimizing the marginal cost to scale.
So, Jef -- once I have made an architectural decision about how I will choose to scale my application, how do I tell if it works or not?
One of the best ways to tell, of course, is to actually scale it.
Wh-wh-what? How, Jef?
Well, there are a couple of things to consider.
First, you need to have something to compare against -- a baseline. To get a baseline, create a load/utlization test. Run your system up to the desired utilization and/or maximum response time, whichever comes first, and determine the threshold for capacity. Record the throughput, response times, and faults, if any. Second, you need to add resources in the dimension along which you intend to scale the system. Take the resources, pour them in, and rerun your tests, increasing the volume by the desired marginal percentage. Did your performance degrade? How much? Where are the bottlenecks now? Can you fix those bottleneck? Ok, then, rinse and repeat.
But wait, Jef. I don't need that much capacity right now. In fact, I can't afford that much capacity right now. I just want to make sure that when I do need the capacity, I can obtain it in a cost effective, performant manner. If I've already bought the extra hardware, then I am no longer really concerned with building a scalable system, right? I have more capacity than I need, right?
Good point. You know more about this than you originally led me to believe.
Obviously, testing for scalability can get very expensive very quickly. Most of the time, when you are designing a system to scale, you aren't intending to take it to scale right then. How do you manage that cost? You scale down the scope of the test to a miniature version of your architecture. First, you prove it works for one unit of increment, and then, if you can afford it, you prove it works for 2, and so on. Then by [a really weak form of] induction you have verified that it scaled. The induction never quite works the way it did in math class, because different forces come into play as systems get very large. Eventually, scaling one dimension of a system is going to create a constrained resource in another dimension of the system, and then the dynamics of the environment change.
I like Werner's point about the argument ender - "but that doesn’t scale." When I hear that, I want to make sure that there is an implied "to the levels that we need to have a successful solution," as in but that doesn’t scale to the levels that we need to have a successful solution." What I explicitly don't want is "But that doesn't scale to support all of the users on the internet."
What about Google, Jef?
Google. Right. Unless I am working for Google. Ack.
There are lots of things that "don't scale," but it is important to understand what the necessary range of scale (read: requirements) is to be able to speak intelligently about the scalability of a system. Most of the time, that range should be driven by the financial implications at scale. In business, money is a key arbiter and a convenient shared language in which to discuss the value of a solution.
Recent Comments