views:

129

answers:

6

G'day,

I was reading the item Quantify in the book "97 Things Every Software Architect Should Know" (sanitised Amazon link) and it got me wondering how to quantify scalability.

I have designed two systems for a major British broadcasting corporation that are used to:

  1. detect the country of origin for incoming HTTP requests, or
  2. determine the suitable video formats for a mobile phones's screen geometry and current connection type.

Both of the designs were required to provide scalability.

My designs for both systems are scalable horizontally behind caching load-balancing layers which are used to handle incoming requests for both of these services and distribute them across several servers which actually provide the service itself. Initial increases in service capacity are made by adding more servers behind the load-balance layer, hence the term horizontal scalability.

There is a limit to the scalability of this architecture however if the load balance layer starts having difficulty coping with the incoming request traffic.

So, is it possible to quantify scalability? Would it be an estimate of how many additional servers you could add to horizontally scale the solution?

+1  A: 

Here's one way:

"assume that a single processor can process 100 units of work per second..."

From http://www.information-management.com/issues/19971101/972-1.html

mcandre
+3  A: 

I think this comes down to what scalability means in a given context and therefore the answer would be it depends.

I've seen scalability in requirements for things that simply didn't exist yet. For example, a new loan application tool that specifically called out needing to work on the iPhone and other mobile devices in the future.

I've also seen scalability used to describe potential expansion of more data centers and web servers in different areas of the world to improve performance.

Both examples above can be quantifiable if there is a known target for the future. But scalability may not be quantifiable if there really is no known target or plan which makes it a moving target.

RSolberg
Ah, the "must be future-proof" requirement! (-:
Rob Wells
@Rob - at least it was identified though... My favorite is when something gets done and then someone comes in and says, but it doesn't work on this....
RSolberg
+1  A: 

The proper measure of scalability (not the simplest one;-) is a set of curves defining resource demanded (CPUs, memory, storage, local bandwidth, ...), and performance (e.g. latency) delivered, as the load grows (e.g. in terms of queries per second, but other measures such as total data throughput demanded may also be appropriate for some applications). Decision makers will typically demand that such accurate but complex measures be boiled down to a few key numbers (specific spots on some of the several curves), but I always try to negotiate for more-accurate as against simpler-to-understand measurements of such key metrics!-)

Alex Martelli
+2  A: 

I think it is possible in some contexts - for example scalability of a web application could be quantified in terms of numbers of users, numbers of concurrent requests, mean and standard deviation of response time, etc. You can also get into general numbers for bandwidth and storage, transactions per second, and recovery times (for backup and DR).

You can also often give numbers within the application domain - let's say the system supports commenting, you can quantify what is the order of magnitude of the number of comments that it needs to be able to store.

It is however worth bearing in mind that not everything that matters can be measured, and not everything that can be measured matters. :-)

frankodwyer
+1  A: 

When I think of scalability I think of:

  • performance - how responsive the app needs to be for a given load
  • how large a load the app can grow into and at what unit cost (if its per server include software, support, etc)
  • how fast you can scale the app up and how much buffer you want over peak period usage (we can add 50% more bandwidth in 2-3 hours and require a 30% buffer over planned peak usage)

Redundancy is something else, but should also be included and considered.

meade
+1  A: 

"The system shall scale as to maintain a linear relationship of X for cost/user".

jldupont