Migrating .NET app to Azure Scale Set (Part 2)

The next azure offering we are going to investigate is Azure Scale Sets , which are at a high level, multiple identical VMs sitting behind a load balancer that can be configured to scale in response to demand.

Reviewing the requirements we can assess if azure scale set meets our needs

A scale set is multiple identical virtual machines managed by azure. In order to deploy your application onto each instance you have several options

1. Use an azure custom script extension which will execute a script to install all necessary components after a VM instance is deployed. These scripts can be downloaded from azure storage or github.
2. Specify a custom VM image that can be used for creating instances, this image would include any applications or configurations required. Using an image can reduce the number of tasks that need to be carried out after a Vm instance is deployed.

In the case of our sample application, one option is to provision an Azure file share for the application to write the files to instead of local storage and mount the file share to the VM using a custom script extension.

If for example the reason we were unable to use azure app service was because we were unable to make the application changes necessary, be it legacy code or time restriction or whatever. If the location your uploaded files are saved to is configurable, a simple config change to point to the azure file share instead of the local drive would allow us to achieve the requirements without code changes.

There is still work to do however in terms of choosing how you want to manage the scale set VM deployment, but it bypasses the blocker from not being able to update the application and still meets the requirements defined. Based on the above options the rest of this post is going to follow through an example using an azure custom script extension.

Scale Set Demo

For this sample we need to :

1. Create an azure storage account with 2 file shares and a blob container
   • Upload the application code repo to one of these
   • The other is to store the files users upload to the site
2. Create a powershell script that will configure the VM instance after its created and then upload this script to the blob container created above and retrieve the public URL from azure storage. This public URL will be needed in step 3 when setting up the custom script extension. The powershell script itself needs to do the following:
   • Install ISS
   • Create app pool and configure it to work with azure file share local account. Because for this sample we want to access the file share through IIS the only way I could currently find of doing so was creating a local account that matches the name on the storage account
     • I found this blog post great for help on this step https://blogs.iis.net/davidso/azurefile 
   • Copy the application code from the file share to local folder
   • Set up new web application within IIS to point to the application code copied above and use the new application pool created above
3. Get a script to create the actual azure scale set and configure it to run a custom script extension on startup of a new VM instance, this script extension will then run the powershell script  created in step 2 on every start up of a new VM instance.
   • For the demo in the video I am going to follow the Microsoft quick guide on creating a scale set https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/quick-create-powershell .  
   • The setup of the scale set is ran through quite quickly in this demo as its main focus is just to give an overview of what scalesets are. So if you are unfamiliar with setting up an azure virtual network , subnets or load balancers , then id advise perhaps having a look at this link first (Creating an Azure VNET) . You might also already have an azure VNET that you can create a subnet in for use by the scale set.
   • If these networking concepts are all new to you, try not to get overly concerned with them at this stage and instead try to assess if the scale set itself is something that might be worth pursuing for your scenario.

Once we have the storage accounts and scripts created, then we need to run the powershell script from step 3, this does all the initial set up of

• creating the virtual network (if you don’t already have one),
• creating the load-balancer that sits in front of the multiple Virtual Machines to give a single entry point
• configures the NSG (Network security group) to allow access to port 80 so we can access our web application

Configuring Autoscaling 

Then once the scale set is up and running in the sample we see it creates 2 instances – so 2 identical virtual machines that were setup by running the powershell created in step 2 above.

As demand on our application increase we can then configure the scale set to automatically increase or decrease the number of VM instances, we can do this by defining some auto-scale rules for the scaleset.

For example a rule that will increase the number of VM instances by a specified number when the average CPU goes over 70% over a 5 minute period. Rules can be configured through the portal or via powershell.

There is a good tutorial on setting up these rules and testing by simulating load to cause the scale set to automatically scale on the Microsoft documentation – https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/tutorial-autoscale-powershell

Application Updates

Scale sets have a setting called “Upgrade Policy” that defines how VMs are brought up to date to the latest version. There are several ways in order to roll out an update

• Using Powershell to re-deploy the custom script extension 
• If you use the option of a custom VM image to deploy new VM instances, then you could integrate application updates with a deployment pipeline to build the new image and deploy upgrades across the scale set. This approach allows the pipeline to pick up the latest application builds, create and validate a VM image, then upgrade the VM instances in the scale set. ( Deploying your application )
  

However going back to our sample application, if the file location is not configurable perhaps its been hard-coded within legacy code, or for some other reason you don’t want to pursue the option of using azure scale sets,  then where does that leave you, what other options do i have ? 

At this stage perhaps we need to review the requirements, how important is it that the application automatically scales? Currently the application resides on a single server, if we cannot make any changes to the application then, is it more important that the application has high availability and potential for it to have scope for manual scale than for it to auto scale. If the answer to this is yes then have a look at part 3 of this series Migrating to Azure VM