Art of scalability

I will write two or three articles about scalability. I will call the first one ‘Scalability principles’ and I will speak about what is the scalability and its principles, and then I will move to Scalability pattern, anti-pattern, and guidelines in next posts. So let’s start.

Scalability principles:

In telecommunications and software engineering, scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged. For example, it can refer to the capability of a system to increase total throughput under an increased load when resources (typically hardware) are added. An analogous meaning is implied when the word is used in a commercial context, where scalability of a company implies that the underlying business model offers the potential for economic growth within the company. [Wikipedia]

If it’s hard to understand the Wikipedia Scalability definition, so read this: At the simplest level, Scalability is about doing more of something. Scaling a web application is about allowing more people to use your application is same time. Scaling it’s the ability to handle larger number of concurrent users.

Today we have two choices when it comes to scaling:

• Vertical Scalability: Vertical Scalability refers to adding resource within the same logical unit to increase the capacity. For example: Add more CPUs to your application server, or expanding the storage or the memory. The Vertical Scalability focus on the hardware only.
• Horizontal Scalability: Horizontal Scalability refer to add multiple logical units of resources and make them together work as a single unit. You can think about it like: Clustering, Distributed, and Load-Balancing. The Horizontal Scalability focus on the software and the hardware.

Now the big question: How we can architect and design our software to be Scalable?   The architects strive to achieve linear scalability, which refer 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 K Tharakan refers to this as a “scalability factor”, and uses it to enumerate 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, it’s 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, it’s 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. If you need scalability, urgently, going to vertical scaling is probably will to be the easiest, but be sure that 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.

On the other hand Horizontal scalability doesn’t require you to buy more and more expensive hardware. It’s 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.