Enterprise computing relied heavily on large, expensive database infrastructure. The cloud has rendered this type of design obsolete. Vertical scalability has given way to elastic horizontal scalability.
Vertical scalability vs horizontal scalability
Vertical scalability means the ability to increase the capacity of your hardware to handle more load. This was definitely a thing in mainframe days (so I’m told), where you had a single “machine” – the mainframe – and then bought more components for it if needed.
In the era of enterprise computing, vertical scalability was usually most applicable to relational database servers. For a long time, scaling out application servers has been pretty straightforward, but relational database servers (RDBMS) need a single view of a data set in order to enforce relational constraints. The larger the dataset the more memory, CPU and disk IO the server needs in order to handle increased load.
Vertically scaled systems are therefore dinosaur technology. They are big, cumbersome, expensive to buy, expensive to maintain and prone to becoming single points of failure.
Horizontal scalability on the other hand means increasing the number of machines that act in parallel to process workload. There are some design constraints to horizontal scale, principally that the machines should be stateless*. In order to distribute parallel work you should not care which machine you direct load towards, it should behave the same regardless.
If vertical scale is dinosaur, horizontal scale is definitely mammalian. Small, nimble, cheap to procure, ideally cheap to maintain (lots of things that are the same brings benefits of automation).
*Some web farms use sticky sessions, so a user’s state is tied to a server, but this is usually done with the explicit knowledge that a server outage will lose some transient state.
What broke vertical scale?
The web.
Improvements in hardware technology allowed enterprises to keep pace with growth: Better CPUs, memory, disks allowed vertical scale to keep up with large applications running on relational databases.
The web changed all that. No matter how good your database server, when you have millions to hundreds of millions of users your ability to scale vertically will run out of road sooner or later. Early pioneers of sharded data architectures showed that you can scale better and more reliably using commodity hardware and distributing load across many machines than you can with very powerful – and expensive – dinosaur systems.
Database technologies have moved on as well. The evolution of NoSQL database engines has given rise to sharding being baked into the database technology itself instead of being a layer that you need to apply yourself on top of a RDBMS. The popularity of MongoDB (https://www.mongodb.com/) is testament to this – making it into the top 5 most popular database technologies for the past couple of years. (It would be interesting to get stats on prevalence of database technologies categorized by user load). Cloud databases such as AWS DynamoDB (https://aws.amazon.com/dynamodb/) also bake sharding into the fundamental design.
(There are many site that perform DB ranking, I use this one: http://db-engines.com/en/ranking)
The next generation: elastic scale
Cloud technology is a refinement of horizontal scale. For those of us building cloud apps, the exciting thing is that the cloud infrastructure provides us with most of the things we used to have to design into our solutions to make them scalable and resilient (load balancing, sharding, provisioning new instances, multiple copies of data, separate fault domains). We still need to understand how these work, and we need to use them wisely in order to get the best performance for the lowest running cost.
An important feature of cloud scaling though is that we no longer have to provision physical hardware. We can scale up by running a couple of lines of script, but just as importantly we can scale down again when we don’t need the capacity. Most systems run on cycles of load. Internet shoppers tend to be thin on the ground overnight, banking activity is busiest around payday, logistics is busiest at Christmas. When we build systems in our own datacentres we have to provision enough tin to handle our peaks. When we build in the cloud we can pay for what we need, when we need it.
For many businesses cloud offers massive potential cost savings, and elastic scale – paying for the capacity we need at any point in time – is a major component of that.
In summary
Large-scale computer systems being designed now should not have to rely on large, expensive hardware in order to make them run. Vertical scale is a thing of the past. The future belongs to elastic scale.