Question

I’ve heard that people say that they’ve made a scalable web application..

1. What really is scaling?

2. What can be done by developers to make their application scalable?

3. What are the factors that are looked after by developers during scaling?

4. Any tips and tricks about scaling web applications with asp.net and sql server…

Answer 1

What really is scaling?

Scaling is the increasing in capacity and/or usage of your application.

What do developers do to make their application scalable?

Either allow their applications to scale vertically or horizontally.

Horizontal scaling is about doing things in parallel.

Vertical scaling is about doing things faster. This typically means more powerful hardware.

Often when people talk about horizontal scalability the ideal is to have (near-)linear scalability. This means that if one $5k production box can handle 2,000 concurrent users then adding 4 more should handle 10,000 concurrent users. The closer it is to that figure the better.

The ideal for highly scalable apps is to have near-limitless near-linear horizontal scalability such that you can just plug in another box and your capacity increases by an expected amount with little or no diminishing returns.

Ideally redundancy is part of the equation too but that’s typically a separate issue.

The poster child for this kind of scalability is, of course, Google.

What are the factors that are looked after by developers during scaling?

• How much scale should be planned for? There’s no point spending time and money on a problem you’ll never have;
• Is it possible and/or economical to scale vertically? This is the preferred option as it is typically much, much cheaper (in the short term);
• Is it worth the (often significant) cost to enable your application to scale horizontally? Distributed/multithreaded apps are significantly more difficult and expensive to write.

Any tips and tricks about scaling web applications…

Yes:

1. Don’t worry about problems you’ll never have;
2. Don’t worry much about problems you’re unlikely to have. Chances are things will have changed long before you have them;
3. Don’t be afraid to throw away code and start again. Having automated tests makes this far easier; and
4. Think in terms of developer time being expensive.

(4) is a key point. You might have a poorly written app that will require $20,000 of hardware to essentially fix. Nowadays $20,000 buys a lot of power (64+GB of RAM, 4 quad core CPUs, etc), probably more than 99% of people will ever need. Is it cheaper just to do that or spend 6 months rewriting and debugging a new app to make it faster?

It’s easily the first option.

So I’ll add another item to my list: be pragmatic.