Scaling virtual machines is quite simple and easy in Azure Cloud. This is where microservices shine through. With scale sets, you can raise the instances of the same virtual machine images in a short amount of time, and automatically too, based on the ruleset. Scale sets are integrated with Azure Autoscale.
Azure virtual machines can be created in such a way so that as a group, they always serve the requests even if the volume of the requests increases. In specific situations, they can also be deleted automatically if those virtual machines are not needed to perform the workload. This is taken care of by the virtual machine scale set.
Scale sets also integrate well with load balancers in Azure. Since they are represented as compute resources, they can be used with Azure's Resource Manager. Scale sets can be configured so that virtual machines can be created or deleted on demand. This helps manage virtual machines with the mindset of pets vs. cattle, which we saw earlier in the chapter in terms of deployment.
For applications that need to scale compute resources in and out, scale operations are implicitly balanced across the fault and update domains.
With scale sets, you don't need to correlate loops of independent resources, such as NICs, storage accounts, and virtual machines. Even while scaling out, how are we going to take care of the availability of these virtual managers? All such concerns and challenges have already been addressed with virtual machine scale sets.
A scale set allows you to automatically grow and shrink an application based on demand. Let's say there's a threshold of 40% utilization. So, maybe once we reach 40% utilization, we'll begin to experience performance degradation. And at 40% utilization, new web servers get added. A scale set allows you to set a rule, as mentioned in the previous sections. An input to a scale set is a virtual machine. The rules on a scale set say that at 40% average CPU, for five minutes, Azure will add another virtual machine to the scale set. After doing this, calibrate the rule again. If the performance is still above 40%, add a third virtual machine until it reaches the acceptable threshold. Once the performance drops below 40%, it will start deleting these virtual machines based on traffic inactivity and so on to reduce the cost of operation.
So by implementing a scale set, you can construct a rule for the performance and make your application bigger to handle the greater load by simply automatically adding and removing virtual machines. You, as the administrator, will be left with nothing to do once these rules are established.
Azure Autoscale measures performance and determines when to scale up and down. It is also integrated with the load balancer and NAT. Now, the reason they're integrated with the load balancer and with NAT is because as we add these additional virtual machines, we're going to have a load balancer and a NAT device in front. As requests keep coming in, in addition to deploying the virtual machine, we've got to add a rule that allows traffic to be redirected to the new instances. The great thing about scale sets is that they not only add virtual machines but also work with all the other components of the infrastructure, including things such as network load balancers.
In the Azure Portal, a scale set can be viewed as a single entry, even though it has multiple virtual machines included in it. To look at the configuration and specification details of virtual machines in a scale set, you will have to use the Azure Resource Explorer tool. It's a web-based tool available at https://resources.azure.com. Here you can view all the objects in your subscription. You can view scale sets in the Microsoft.Compute section.
Building a scale set is very easy using the Azure templates repository. Once you create your own Azure Resource Manager (ARM) template, you can also create custom templates based on scale sets. Due to scope and space constraints, we have omitted a detailed discussion and instructions on how to build a scale set. You can follow these instructions by utilizing the ARM templates given at https://github.com/gbowerman/azure-myriad.