Yesterday, the Azure South Central datacenter got impacted by a severe weather event which caused a lot of systems going down, including 7 of my personal websites, 1 of them being this blog. I mentioned this to a few colleagues on separate conversations and interestingly both conversations ended up with a discussion around auto-scaling in the cloud.
There are two types of scaling I’d like to discuss: Horizontal and Vertical. The diagram below is my attempt of comparing these.
As my websites are personal and non-critical, I had them all hosted in a region where, at the time of creation, the cheapest in terms of pricing. I did select the app service size that allows for auto-scaling. However, this auto-scaling is vertical.
- Vertical scaling means adding more power to your web app / VM. You’ll still have a single instance and you’re upping the specs of it. It’s great because, while you are solving for performance, you’re saving costs too as you’re only paying a minimal amount, only having to pay extra when your web app scales up. However, one obvious limit is “availability” – when the datacenter that hosts your web app goes down, your website goes down with it.
- Horizontal scaling on the other hand adds more machines to your pool of resources. Setting this up is a little bit more complicated as you’ll need a load balancer on top and most likely a service bus too to ensure all resources are in sync. However, not only will you be solving for performance but for availability as well. So if you’re website requires High Availability (HA), then you probably will want to consider a failover region, setting up a resource that’s hosted in a different region.
In Azure, Vertical Scaling is also known as “Scaling up“. This configuration can be set up in your web app:
Horizontal scaling, on the other hand, is known as “Scaling out“. Here’s a typical Azure Portal screen for when configuring horizontal scaling:
