In computer operations scalability is not about:

• How many servers you have
• How fast your hardware is
• How many data centers you have
• How much traffic you have
• Crude and obvious double entendres

Rather is about a mindset.

Not just Google

I recently spoke at PICC with George and took the opportunity to listen to some talks there as well. Tom Limoncelli from Google spoke about some of his thoughts on a university level degree for system administrators. One of the ideas he presented was that the “future of system administration is going to be less about support and more about scalability.” When he said that, someone blurted out what I imagine a lot of us were thinking:

“Of course you think that, you work at Google!”

His answer was something along the lines of,

“Well that really doesn’t matter, even when I was starting out and was a lone system administrator, I still had to scale my time.”

This short dialogue captured the essence of what I think it means to be scalable, and that is doing more with less.

Why do people think it is about size?

When a web site starts to get more traffic and the things that usually follow (More servers, more people, etc) then they basically have no choice but to figure out how to do more with less. This is really for two reasons.

The first reason is that system itself might just break down because it is the wrong way to do it. Sam Saffron put this perfectly when he was interviewed at MIX: “By adding more servers all we would really be doing is distributing the slow”. (Why is turning non-nouns into nouns so catchy?). The other reason is that the cost to throw more hardware at the problem starts to become untenable.

When faced with these problems, a company will generally have no choice but to learn how to scale. But when they are learning to scale because of this, what they are really learning how to do is to do more with less.

Do more with less

You can start to become scalable very early on, even with only a few servers. There are lots of ways we generally practice scalability, a few examples are:

• Code and script management tasks. When you have 3 servers you may not need to do this, you can probably do it by hand. However, when you have 100 you will have no choice.
• Use algorithms and data structures that are efficient.
• Use caching effectively.
• Document tasks so you are not a single point of failure and so you don’t have to relearn things every time.
• Use centralized authentication, configuration management, updates, etc.
• Use automated building and deployment processes.

There are two traits in all off the items I listed above:

1. They all save time in the long run (they are asymptotically superior) which results in doing more with less.
2. You don’t need very many servers to do them.

I won’t deny that there are some unique problems that will only start to show themselves when you get really big, and that only at certain sizes do you discover that some systems will start to break down. However, in reality you only need a small amount of hardware to start practicing the principals of scalability.