Scale Vertically Before You Scale Horizontally

Scaling out is the fashionable answer and frequently the wrong first one. Making a single machine larger is dramatically simpler, and simplicity has real operational value.

What horizontal scaling actually costs

Adding a second application server introduces problems the first one never had:

• State has to move. Sessions, uploads and caches held in local memory or on local disk must go somewhere shared.
• Something must distribute traffic. A load balancer is another component to configure, pay for and monitor.
• Deployment becomes a rollout. Updating several machines without downtime is a different process from restarting one.
• Debugging gets harder. Which server served the failing request, and do the logs agree?

None of this is insurmountable. All of it is work you do not have to do while one machine suffices.

The ceiling on vertical scaling

Vertical scaling ends in two ways. There is a largest machine, and that limit is high enough that most applications never reach it. More importantly, one machine is one failure domain: when it restarts, you are down.

The honest signals to scale out

• Availability is a requirement. If the business cannot accept the downtime of a single reboot, redundancy is the reason to spread out, not performance.
• You have run out of machine. You are near the largest size and still constrained.
• Load is genuinely spiky. Adding and removing capacity is cheaper than paying permanently for the peak.
• Geographic distribution. Users on another continent need capacity nearer to them.

Note that only one of these is about raw performance.

Preparing without committing

You can make a future split cheap without doing it now:

• Keep session state in a shared store rather than in process memory.
• Write uploads to object storage rather than the local disk, as discussed in block versus object storage.
• Log to somewhere central.
• Keep configuration in the environment rather than in files edited on the box.

These are good practice on a single server anyway, and they turn scaling out from a rewrite into a configuration change.

Resize on measurement

Whichever direction you go, decide with numbers rather than instinct. The method is in how to size your first cloud server.