Computer systems or individual applications have capacity limits. A web site might be working just fine with one or two or fifty users, but when use goes way up, it may no longer work correctly – or a tall. A desktop application may work fine for a long time – then one day, we try loading a really large file or data set, and it can’t handle it. These are scalability challenges.
After our system or application reaches its capacity limits, what are our options to make it work even with the new demands? In other words, how do we make it scale?
The following scalability approaches allow us to handle more computations (with vertical and horizontal scaling) or more system instances (with juxtaposition scaling).
There are other very important scaling patterns that we might address in a future post – such as the scalability using algorithms that embrace parallelism (such as Map/Reduce), NoSQL-like schema-less storage, and data sharding. These are not covered in this article.
Scale Up with More Powerful Hardware
The obvious option in many cases is to address a scalability problem with better, faster, more capable hardware. If we can’t load that giant spreadsheet model on a computer with 512MB of RAM, we install 2GB and give it another try. If it is still too slow, we can use a machine with a faster processor or faster hard disk.
This approach can also be applied to web servers, database servers, and other parts of your system. Got an architecture problem? Get some better hardware.
This approach is variously called “scaling up” or “vertical scaling” – since we are addressing the problem by substituting a more capable system (usually a single server), but one that is still logically equivalent.
The essential point here is that, generally speaking, the limits of scalability are due to the limits of a single computer (or perhaps the limits of an affordable single computer).
In Scaling Up (also known as Vertical Scaling) the limitation is hardware related in a very specific way: how much memory, disk, and processor a single server can support…
The key challenge with Scaling Up is that you might run out of hardware options. What happens if you are running on the fastest available machine, or it can’t take any more memory? You may be out of luck.
Scale Out with More Hardware Instances
Another option is some cases is to leave the existing machines in place, and add additional machines to the mix to share the burden. This is variously called “scaling out” or “horizontal scaling” – a metaphor suggestive of spreading out the system as we add more machines beside the existing ones.
The key point here are that systems need to be architected to support Scaling Out – though the benefit is that they can generally scale a lot more than a Scale Up system – and scalability is enabled by the software architecture.
In Scaling Out (also known as Horizontal Scaling) scalability must be architected into the system… it is not automatic and is generally more challenging than Scaling Up. You scale by running on more instances of the hardware – and having these hardware instances share the workload.
As mentioned, scaling out is an attribute of the architecture of the system. This is a great fit for the elastic nature of cloud computing platforms.
Scale Side-by-Side with More Systems
In the real world, not all of our scaling concerns are with “the” system – we tend to have many copies of systems. I recently heard that for every production instance of SAP, there are seven non-production instances. And in my own experience, organizations *always* need many instances of systems: for development, test, training and … then we have different versions of all these systems … and the list goes on.
It turns out that another great use of the cloud generally (including the Azure Cloud) is for spinning up these other instances of our system for many purposes – sometimes we don’t want 1 N-node app, we want N 1-node apps.
I dub this use of cloud to be “scaling side-by-side” or “juxtaposition scaling” – a metaphor suggestive of putting similar systems beside each other, since they are a related collection of sorts, even though the instances of systems scaled side-by-side to are not connected to, or operationally related to, any of the other instances.
Scaling Side-by-Side (also known as Juxtaposition Scaling) happens when you use the cloud’s elastic nature to create additional (often temporary) instances of a system – such as for test or development.
Also, scaling side-by-side (juxtaposition scaling) is orthogonal to scaling up (vertical scaling) or scaling out (horizontal scaling). It is more about scaling to support more uses of more variants (versions, test regions, one for training, penetration testing, stress testing, …) for overall environmental efficiency.
And, finally, like other ways to leverage cloud infrastructure, to efficiently scale side-by-side you will benefit from some automation to easily provision an instance of your application. Azure has management APIs you can call to make the whole process automagic. Consider PowerShell for building your automation…
[It was in a conversation at the Hub Cloud Club with several folks, including William Toll and John Treadway. John mentioned the SAP statistic and also suggested that adding more instances is just another type of scaling in the cloud. I agreed and still agree. So I am giving that type of scalability a name… Scaling Side-by-Side or Juxtaposition Scaling. Neither seems to have any real hits in Google, but let’s see if this catches on.]
Coding Out Loud 
