Think you know what scalability is?

"Scalability" is a word often cited in software vendor press releases (and discussed around the water cooler), but is quite often misunderstood. For example, many people infer performance and high availability when they are talking about scalability. Royans K Tharakan, in attempting to answer the question "What is scalability?", says:

Scalability, simply, is about doing what you do in a bigger way. Scaling a web application is all about allowing more people to use your application. If you can’t figure out how to improve performance while scaling out, its okay. And as long as you can scale to handle larger number of users its ok to have multiple single points of failures as well.

Royans notes that today we have two choices when it comes to scaling:

• Vertical Scalability - Adding resource within the same logical unit to increase capacity. An example of this would be to add CPUs to an existing server, or expanding storage by adding hard drive on an existing RAID/SAN storage.
• Horizontal Scalability - Adding multiple logical units of resources and making them work as a single unit. Most clustering solutions, distributed file systems, load-balancers help you with horizontal scalability.

Architects strive to achieve linear scalability, which refers to the ability to maintain a consistent throughput rate proportionally as resources are added to the system. However, adding resources incurs additional overhead, making it difficult to achieve. Royans refers to this as a "scalability factor", and uses it to enumerates types of scalability:

• If the scalability factor stays constant as you scale. This is called linear scalability.
• But chances are that some components may not scale as well as others. A scalability factor below 1.0 is called sub-linear scalability.
• Though rare, its possible to get better performance (scalability factor) just by adding more components (i/o across multiple disk spindles in a RAID gets better with more spindles). This is called supra-linear scalability.
• If the application is not designed for scalability, its possible that things can actually get worse as it scales. This is called negative scalability.

As with a lot of things in software development, there is no one size fits all prescriptive approach that will solve your scalability problems. Royans suggests "If you need scalability, urgently, going vertical is probably going to be the easiest" but warns "Unfortunately Vertical scaling, gets more and more expensive as you grow" and "While infinite horizontal linear scalability is difficult to achieve, infinite vertical scalability is impossible". He goes on to say:

Horizontal scalability, on the other hand doesn’t require you to buy more and more expensive servers. Its meant to be scaled using commodity storage and server solutions. But Horizontal scalability isn’t cheap either. The application has to be built ground up to run on multiple servers as a single application.

Royans ends his piece with advice on tackling scalability across the stack:

For a successful scalable web application, all layers have to scale in equally. Which includes the storage layer (Clustered file systems, s3, etc), the database layer (partitioning, federation), application layer (memcached, scaleout, terracota, tomcat clustering, etc), the web layer, load balancer, firewall, etc. For example if you don’t have a way to implement multiple load balancers to handle your future web traffic load, it doesn’t really matter how much money and effort you put into horizontal scalability of the web layer. Your traffic will be limited to only what your load balancer can push.