Vertical Scale & Horizontal Scaling – Pros, Cons & Use Cases

Scaling services generally come in two forms: vertical scaling and horizontal scaling.  Both are a means of scaling, but they’re very different animals and each have their pros, cons and ideal use cases.  We’ll explore them a bit and try to give a good foundation for what to expect when you need to scale, regardless of the nature of your scaling needs. 

Vertical & Horizontal Scale: What’s the Difference? 

Vertical scaling is the process of adding additional resources to existing services.  For example, we may be hosting an application server via AWS and give the server more CPU and RAM to handle increased load.  This is “scaling up” or Vertical Scaling. 

Horizontal scaling works on the other axis: rather than increasing CPU and RAM on a particular server, we may instead create copies of that server and split the total load between them. 

Here’s a quick visual: 

With a conceptual understanding of each, let’s dive into some specifics! 

Vertical Scaling: Pros, Cons & When to Use 

Vertical scaling is straightforward, easy to implement, and tends to have a few well-defined use cases.  Because of its ease of use, it is often employed as a band-aid solution where horizontal scaling or other optimization methods should be implemented instead. 

Advantages of Vertical Scaling 

The primary advantage of vertical scaling is that it’s dead simple.  Go to our cloud provider, increase the resources, reboot, and we’re done.  We might have a few minutes of downtime, but there really are no other prerequisite tasks that need to be handled. 

Vertical scaling has extremely low operational risk.  If an application runs with 2 vCPUs and 8Gb of RAM, increasing that to 4 vCPUs and 16Gb of RAM is about as low risk as you can get.  It’s one of the very few times we can make an operational change and not have to worry much about what the side effects will be. 

Disadvantages of Vertical Scaling 

Vertical scaling has a few disadvantages and danger areas.  The most prominent is through inappropriate use.  Because vertical scaling is so easy, it’s often employed as a knee-jerk reaction to scaling needs.  Some further considerations are:  

• Scaling Limitations: Vertical scaling only offers so much.  At some point, we hit a cap.  It may be possible to have a server running with 256 vCPUs and 24Tb of RAM, but the cost will probably kill us before we make it that far.   
• Non-Optimal Resource Usage: Often, when companies employ vertical scaling, they do so while many applications or services are running on a single server.  In this case, it’s very common to have one application or service driving the need for resource scaling.  Typically, this means that the resource could be moved elsewhere and handled in isolation. 
• Automation Difficulty: Vertical scaling is quite easy, but often handled manually, especially in the cases where it’s used as a “quick fix” to an emergent issue.  Automating vertical scale should be done with great care, within well-defined constraints. 
• Complacency & Scale Creep: It’s easy to use vertical scale to hide operational inefficiencies, then it tends to compound itself.  Time and time we’ve seen the same story, and it tends to go like this: 

1. 1. We’re having issues!  Let’s increase resources and hope it fixes it.
   2. Ok, great, it seems to be working better.
   3. (weeks later…) Last time we had the resources down at that level we were having issues, better to leave it where it is.
   4. (months later) We’re having issues! Let’s increase resources and hope it fixes it…  

It’s easy to fall into inappropriate use patterns and end up spending thousands (or even tens of thousands) each month on infrastructure costs when a two-hour programming fix would have taken care of the problem.  The false confidence danger while hiding inefficiencies can back us into a corner without even realizing it, leaving us in a dangerous position of having an unhealthy and worsening system with no easy cure.  That’s a bad spot to be.  If we’re employing vertical scale, it should be for specific reasons with a full understanding of the potential long-term consequences. 

Use Cases for Vertical Scaling 

It may seem the dangers of vertical scaling are quite significant, and that’s certainly true, but it doesn’t mean vertical scaling doesn’t have ideal use cases.  This type of scaling is quite viable and optimally fills the need in many situations: 

• There are known peak periods in typical business operations (end-of-month or quarterly spikes in usage, etc.). 
• There’s slow but steady growth of a service and the future needs can be confidently projected. 
• System operations are generally stable and resource usage needs are predictable and not subject to erratic changes. 
• Dealing with certain types of applications that resist horizontal scaling; database servers, heavy algorithm processors that can’t run in parallel, and things of that nature. 

Generally, vertical scaling is a solid choice when the operational envelope is well-known and predictable but needs some flex room.  When we start getting into planning for unknowns, we start taking a closer look at horizontal scaling… 

Horizontal Scaling: Pros, Cons & When to Use 

Horizontal scaling is the practice of adding additional servers (technically: containers) to support higher loads.  While vertical scaling is easy to implement and ideal for well-constrained situations, horizontal scaling tackles the problem from an entirely different direction. 

Advantages of Horizontal Scaling 

The advantages of horizontal scaling are significant.  It’s almost limitless in the amount of resources and flexibility it can support. 

• Few Limitations: We can run a single container, ten containers, a thousand containers, or more.  There’s (more or less) always some next level we can scale to. 
• Highly Flexible: Horizontal scaling is deeply rooted in automation, and many of those automations are triggered through thresholds of the infrastructure itself.  This allows for highly customized scaling logic to be implemented.   
• Unknown Demand Handling: A system that can scale well horizontally can be reasonably prepared for unknown volume demand. 
• Advanced Logistics: A comprehensive horizontal scaling infrastructure also supports advanced logic, such as varying load capacity management mechanisms, A\B service testing, automated rollbacks and similar. 

While vertical scaling is a highly targeted means of serving a particular purpose, horizontal scaling is like a blank canvas you can paint any sort of picture you like. 

Disadvantages of Horizontal Scaling 

The major downsides of horizontal scaling are the required effort and risks of failure.  Significant architecture planning on both the application and infrastructure levels.  Additionally, this is one of those “must be done right to be done at all” type of ventures.  Here are some primary considerations: 

• Infrastructure Support: Horizontal scaling requires a lot of supporting practices at the infrastructure level.  Load balancers, networking, container management, automation pipelines, etc. 
• Monitoring & Service Discovery: With so many peripheral things in place to make this work, when something inevitably goes awry it can be near-impossible to determine the place and cause of the failure.  Clear monitoring, traceability, and discoverability through the infrastructure is a hard requirement.   
• DevOps & Automations: Trying to manage horizontal scale manually is a recipe for disaster; solid automation procedures are an absolute must, particularly in the service deployment area. 
• Application Architectures: Many monolithic applications hide operational inefficiencies that are major blockers to horizontal scaling.  It’s a subtle area but can easily backfire.  
• Application Resistance: Some types of applications resist horizontal scale and need to be handled with special care.  Relational databases are an excellent example, requiring significant data platform re-architecture to scale horizontally.  

Horizontal scaling systems significantly increase complexity and have a great many moving parts.  There are no shortcuts, and if it’s not done correctly the results can be catastrophic. 

Use Cases for Horizontal Scaling 

We noted that vertical scaling is particularly useful in well-defined, highly constrained, and hard-capped scenarios.  Horizontal scaling handles the opposite and therefore has a great many potential use cases.  Some of the more common ones are listed below. 

• Fast Growth: When the goal is to scale by orders of magnitude, horizontal scaling is really the only option.  
• Special Needs Services: Not everything always needs horizontal scaling.  Many organizations can operate just fine in a mixed mode, where only specific services that are otherwise bottlenecks are put under some horizontal scaling mechanism. 
• Unknown Spikes: Horizontal scaling is great insurance against unknown or vague spikes in demand.  A new tax prep company might expect to be hit hard during the first quarter of the year, but how hard?  Horizontal scaling can prevent unknown demand from crippling your operations and keeping uptimes and response times where they need to be. 

Mix & Match, Can We? 

Absolutely!  In fact, most systems of substance have a mixture of both horizontal and vertical scaling techniques employed.  This is especially true for multi-tenancy scenarios where each tenant has its own dedicated services (horizontally), but within each tenant’s service ecosystem, vertical scaling is employed as necessary depending on the tenant’s resource needs. 

Wrap-Up 

Well, there we have it.  Vertical and horizontal scaling.  Two very different approaches, with very different strengths, weaknesses, and use cases.   Vertical scaling is great for finite, well-known, and highly constrained scaling needs, and can be easily achieved.  Horizontal scaling is great for handling unknowns, large scope, long-term, and strategic scaling, but takes much more effort. 

If you have scaling concerns and you think we might know what we’re about, feel free to reach out!