We’ll do a demo shortly on creating a Virtual Machine Scale Set but first we must understand how to use Virtual Machine Scale Sets which in a way helps to explain its purpose. We have two ways of scaling VMs: Scaling Up and Scaling Out. Scaling Up, sometimes referred to as scaling vertically, involves upgrading your virtual machine to a more powerful VM. In Azure this means resizing your VM to a higher SKU. Just like we resize standalone VMs in the Portal, we may also resize all the VMs in an entire VM Scale Set all at once.

Scaling Out is commonly referred to as scaling horizontally, meaning we keep the same VM size for all our VMs but we instead add more VM instances to our VM Scale Set in order to service resource demand.

Knowing when to scale up or scale out can be a tricky scenario. Sometimes you have a well known peak period where you can anticipate a need for higher resource capacity to keep your services running well during this peak period. Other times, however, you may have a web application which gets unexpectedly high loads of traffic early one morning which exceeds the capacity your currently running infrastructure. In both these scenarios, you would want some way to prepare for such events. This is where Autoscaling comes to play. With Autoscaling you may manipulate the Scale Out feature of Azure VM Scale Sets based on a predefined schedule or other predefined thresholds such a CPU usage. So let’s say that if CPU usage hit 80% across your currently running VMs. You may configure a threshold that says when we hit 80% CPU utilization, I want Azure to automatically spin up two additional VM instances in order to service the request. And if we then again hit 80% then spin-up two more VMs. Consequently we may say that if after a while the cpu traffic drops back down lower than say 10% CPU utilization, then we’d like to Scale-In by removing two VM instances. This is the power of VM Scale Sets and Autoscaling and now I think it’s time for a Demo putting together all that we have learned.