We all want growth, but we often find ourselves unequipped to deal with it. It’s a bit like going to the gym, lifting weights, and seeing real results, only to realize that you no longer fit into your old clothes. Now you have to decide if you want to modify them or buy new clothes.
We can use this very simple analogy to understand the differences between horizontal and vertical scaling.
Related article: “The 15+ Best Cloud Cost Management Tools”
What Is Scalability?
Scalability describes a system’s elasticity. While we often use it to refer to a system’s ability to grow, it is not exclusive to this definition. We can scale down, scale up, and scale out accordingly.
If you are running a website, web service, or application, its success hinges on the amount of network traffic it receives. It is common to underestimate just how much traffic your system will incur, especially in the early stages. This could result in a crashed server and/or a decline in your service quality.
Thus, scalability describes your system’s ability to adapt to change and demand. Good scalability protects you from future downtime and ensures the quality of your service.
But what options do you have when it comes to implementing scaling and ensuring your business’s scalability? That’s where horizontal and vertical scaling come in.
What Is Horizontal Scaling?
Horizontal scaling (aka scaling out) refers to adding additional nodes or machines to your infrastructure to cope with new demands. If you are hosting an application on a server and find that it no longer has the capacity or capabilities to handle traffic, adding a server may be your solution.
How horizontal scaling works
It is quite similar to delegating workload among several employees instead of one. However, the downside of this may be the added complexity of your operation. You must decide which machine does what and how your new machines work with your old machines.
You can consider this the opposite of vertical scaling.
What Is Vertical Scaling?
Vertical scaling (aka scaling up) describes adding additional resources to a system so that it meets demand. How is this different from horizontal scaling?
While horizontal scaling refers to adding additional nodes, vertical scaling describes adding more power to your current machines. For instance, if your server requires more processing power, vertical scaling would mean upgrading the CPUs. You can also vertically scale the memory, storage, or network speed.
How vertical scaling works
Additionally, vertical scaling may also describe replacing a server entirely or moving a server’s workload to an upgraded one.
Horizontal Vs. Vertical Scaling: At a Glance
|
Horizontal scaling |
Vertical scaling | |
|
Description |
Increase or decrease the number of nodes in a cluster or system to handle an increase or decrease in workload |
Increase or decrease the power of a system to handle increased or reduced workload |
|
Example |
Add or reduce the number of virtual machines (VM) in a cluster of VMs |
Add or reduce the CPU or memory capacity of the existing VM |
|
Execution |
Scale in/out |
Scale up/down |
|
Workload distribution |
Workload is distributed across multiple nodes. Parts of the workload reside on these different nodes |
A single node handles the entire workload. |
|
Concurrency |
Distributes multiple jobs across multiple machines over the network, at a go. This reduces the workload on each machine |
Relies on multi-threading on the existing machine to handle multiple requests at the same time |
|
Required architecture |
Distributed |
Any |
|
Implementation |
Takes more time, expertise, and effort |
Takes less time, expertise, and effort |
|
Complexity and maintenance |
Higher |
Lower |
|
Configuration |
This requires modifying a sequential piece of logic in order to run workloads concurrently on multiple machines |
No need to change the logic. The same code can run on a higher-spec device |
|
Downtime |
No |
Yes |
|
Load balancing |
Necessary to actively distribute workload across the multiple nodes |
Not required in the single node |
|
Failure resilience |
Low because other machines in the cluster offer backup |
High since it’s a single source of failure |
|
Costs |
High costs initially; optimal over time |
Low-cost initially; less cost-effective over time |
|
Networking |
Quick inter-machine communication |
Slower machine-to-machine communication |
|
Performance |
Higher |
Lower |
|
Limitation |
Add as many machines as you can |
Limited to the resource capacity the single machine can handle |
Horizontal Scaling Vs. Vertical Scaling: An In-Depth Look
Once again, the biggest central functional difference between the two is that horizontal scaling often forces you to rework how you implement your services or layers. For instance, let’s look at simple three-tier architecture.
You have your presentation tier (user interface/client), logic tier (virtual server/services), and data tier (storage/databases). In the case of horizontal scaling, you can delegate each tier (or the functions responsible for them) to a different node.
However, you may already be running these tiers on different servers but find that one of these servers is underperforming or no longer meets demands. Once again, you can choose to scale this server vertically or horizontally. You may upgrade it with more resources or add another server to share the workload.
For further illustration, let’s consider databases. If you host your database on a single dedicated server and it gets too large, horizontal scaling would mean adding a new node, partitioning, and sharing the data between the old server and the new.
In our “lifting weights” analogy, horizontal scaling would mean buying new clothes while vertical scaling would be modifying your old clothes to handle your new gains.
With that being said, let’s look at a simple breakdown of the advantages and disadvantages of vertical and horizontal scaling.
Advantages of horizontal scaling
- Scaling is easier from a hardware perspective – All horizontal scaling requires you to do is add additional machines to your current pool. It eliminates the need to analyze which system specifications you need to upgrade.
- Fewer periods of downtime – Because you’re adding a machine, you don’t have to switch the old machine off while scaling. If done effectively, there may never be a need for downtime and clients are less likely to be impacted.
- Increased resilience and fault tolerance – Relying on a single node for all your data and operations puts you at a high risk of losing it all when it fails. Distributing it among several nodes saves you from losing it all.
- Increased performance – If you are using horizontal scaling to manage your network traffic, it allows for more endpoints for connections, considering that the load will be delegated among multiple machines.
Disadvantages of horizontal scaling
- Increased complexity of maintenance and operation – Multiple servers are harder to maintain than a single server is. Additionally, you will need to add software for load balancing and possibly virtualization. Backing up your machines may also become a little more complex. You will need to ensure that nodes synchronize and communicate effectively.
- Increased Initial costs – Adding new servers is far more expensive than upgrading old ones.
Advantages of vertical scaling
- Cost-effective – Upgrading a pre-existing server costs less than purchasing a new one. Additionally, you are less likely to add new backup and virtualization software when scaling vertically. Maintenance costs may potentially remain the same too.
- Less complex process communication – When a single node handles all the layers of your services, it will not have to synchronize and communicate with other machines to work. This may result in faster responses.
- Less complicated maintenance – Not only is maintenance cheaper but it is less complex because of the number of nodes you will need to manage.
- Less need for software changes – You are less likely to change how the software on a server works or how it is implemented.
Disadvantages of vertical scaling
- Higher possibility for downtime – Unless you have a backup server that can handle operations and requests, you will need some considerable downtime to upgrade your machine.
- Single point of failure – Having all your operations on a single server increases the risk of losing all your data if a hardware or software failure was to occur.
- Upgrade limitations – There is a limitation to how much you can upgrade a machine. Every machine has its threshold for RAM, storage, and processing power.
Which Should You Choose?
Both horizontal and vertical scaling have their own benefits and limitations. Since there isn’t a one-size-fits-all solution for organizations, you need to scale according to your needs and resources. Here are a few factors to consider along with which type of scaling suits the situation best:
- Cost – Initial hardware costs for horizontal upgrades are higher. If you are working on a tight budget and need to add more resources to your infrastructure quickly and cheaply, then vertical scaling may be the best option for you.
- Future-proofing – Adding additional updated machines through horizontal scaling will increase the overall performance threshold of your organization. There is a limit to how much you can vertically scale a single node and it may not be able to handle the demands of the future.
- Topographic distribution – If you plan to have nationwide or global clients, it is unreasonable to expect them all to access your services from a single machine in a single location. In a situation like this, you’ll need to horizontally scale your resources to maintain your service level agreement (SLA).
- Reliability – Horizontal scaling may offer you a more reliable system. It increases redundancy and ensures that you are not relying on a single machine. If one machine fails, another may be able to pick up the slack temporarily.
- Upgradability and flexibility – If you are running your application’s tiers on individual machines, they are easier to decouple and upgrade without any downtime.
- Performance and complexity – Performance will depend on how your services work and how they are interconnected. Simple straightforward applications won’t benefit much from being run on multiple machines. In fact, it may degrade its quality. Sometimes it’s better to leave the application as is and upgrade the hardware to meet demand. Horizontal scaling may require you to rewrite the code or add a virtual machine that unifies all the servers.
Horizontal Vs. Vertical Scaling: Use Cases
Here are examples of when it is best to use either scaling approach to optimize your workloads.
Use vertical scaling when:
- You’ve verified with your engineers and other stakeholders that increasing a machines capabilities, such CPUs and memory capacity, will deliver the price-performance level your workloads require
- If you’re just starting out; you don’t know how consistent the traffic is or how many users you’ll get
- Want to use your existing system internally and a cloud provider services for the bulk of customer-facing solutions
- You know redundancy is not feasible or required to operate optimally
- Upgrades are few and far between, so there is little downtime to worry about
- You have a legacy app that doesn’t require distributed or high scalability
Use horizontal scaling when:
- Providing high-quality service requires high performance
- Backup machines are necessary to reduce single points of failure
- You want more flexibility to configure your machines in different ways in order to increase efficiency, such as price-performance ratio
- You need to run your application or services across different geographical locations at low latency
- Updating, upgrading, and optimizing your system regularly is imperative — all without increasing downtime
- You are sure that your usage, users, or traffic are consistently high or will be growing exponentially soon
- You have the people and resources to buy, install, and maintain additional hardware and software
- You are using a micro-services architecture or containerized applications, which achieve better performance on a distributed system
Be sure to closely examine your current use case against future expectations before choosing horizontal or vertical scaling. For example, run part of your workload on each system to see how it performs against your service level agreements (SLAs) with your customers.
On-Premise Vs. Cloud Scaling
For the majority of this guide, we’ve chosen to keep things simple by using on-premise non-cloud scaling for our examples. However, cloud scaling works much the same.
A cloud service provider (CSP) may implement hyper-converged infrastructure-based horizontal scaling or choose to use virtual distributed services.
The former is quite common among private and hybrid cloud solutions. In most cases, your cloud provider will handle the scaling. This means you or your IT management won’t have to worry as much about what new hardware is required to meet new demands.
Service providers such as Azure and AWS have automatic scaling.
They can increase and decrease resources according to your requirements at any given time. They can scale up or out when traffic to your application is at its peak and scale down when demand is lessened. This provides organizations with more efficient and cost-effective scaling. This is another reason to consider cloud migration.
Cost: The Grand Determinant
Despite your aspirations or organization’s needs, what may determine your decision, in the end, is cost.
While horizontal scaling sounds great from a functional standpoint, you may not be able to afford it (right now). Nevertheless, it is still important to note that on-premise vertical and horizontal scaling may not be the only options available to you.
You can integrate both or migrate your organization’s infrastructure to a cloud service provider and allow them to handle scaling for you. The latter may be more financially and pragmatically feasible for you, especially in the long run.
However, how do you actually prove this? If you migrate to a cloud solution, how do you determine your present and future cloud expenditure?
A cloud cost management platform may be the best way to do this. You can determine and prove that migration and cloud auto-scaling will ultimately be more cost-effective than on-premise scaling.
CloudZero has assisted companies such as ResponseTap to improve cost predictability and scale more efficiently by allowing them to see exactly which features and products impact their AWS spend.
CloudZero allows companies to map and view a detailed breakdown of their cloud spend – from the highest level down to the most basic components; per customer, per product, per hour, etc.
and see just how we can assist you in understanding your cost challenges. Equip your engineering team with the right software for capacity planning with cost in mind.
The Modern Guide To Managing Cloud Costs
Traditional cost management is broken. Here's how to fix it.
