Azure VM scale sets automate the process of horizontally scaling your application across multiple VMs automatically. VMs in a scale set are automatically distributed across Availability Zones as new instances are created.

Scale sets can be configured to scale out (that is, add more instances) in response to either set schedules or as pre-configured CPU and RAM thresholds are met. For example, you can create an autoscale rule that will automatically create a new instance of your VM if the average CPU across your exiting instances reaches 80%, and then scale back down when it drops below 20%.

You can also define the minimum and maximum number of VMs to have in a scale set at any one time, enabling you to control costs and ensure that in the event of a VM’s failure, a new one will automatically be created.

Because each VM needs to run your application, you must either create a custom image that contains your services or create a custom script that runs on each new VM to automatically install and configure your app.

Creating a custom image involves the following steps:

1. Create a shared image gallery that will contain all your customized images. This can be done through the Azure portal, using PowerShell, or by using the Azure CLI.
2. Create a VM through the normal process, then install and configure your application on it.
3. Prepare your VM for imaging by either running Sysprep on Windows VMs or waagent -deprovision on Linux VMs.
4. Create an image definition from the VM you just created. Again, this can be performed in the Azure portal by going to the shared image gallery you created in step 1 and clicking Add new image definition or using PowerShell or the Azure CLI. When creating an image definition, you define the publisher name, offer name, and SKU information.
5. As part of this process, you must decide whether to create a generalized image or a specialized image. Generalized images have had machine-specific information removed, such as any user accounts and the hostname. Specialized images retain all this information. Specialized images are created much faster as they do not need to go through an initial setup process to create and store this base information. However, because they retain the same hostname, conflicts can occur; therefore, you might need to update this through a post-build script.
6. Now create a version for your image and set the source disk used to create it. Version numbers must be in the format MajorVersion.MinorVersion.Patch – for example, 1.0.0.
7. Create your scale set using the image version created in step 5.

Either in addition to using an image or instead of using an image, you can use a custom script extension. A custom script extension will download a script such as a Bash script or PowerShell script from an accessible location such as GitHub or a storage account and then run it.

That script will install the necessary additional software such as Windows Internet Information Services or Apache on Linux and then deploy your custom code.

Creating custom scripts can be more complex and is much slower for scale-out operations as each new VM must be initialized and configured. However, the benefits are that you can always use the latest patched base image from the Azure gallery.

Conversely, when building your custom images, you must either manually keep them up to date or ensure the latest patches are installed on a newly created instance.

Important note

When building solutions with a scale set, your applications are best built to be stateless. We covered this concept in Chapter 11, Comparing Application Components. As a user may use a different backend server between one request and the next, we should not store information about that user on the server processing the request.

The next component you will want to ensure is resilient is storage. Also, managed disks, which we saw in this section, are automatically resilient when VMs are built across Availability Zones; you may also need to consider your redundancy options for using Azure storage accounts.