Its Day 54 of my 100 Days of Cloud journey, and today I’m going to attempt to understand and explain some of the Advanced Settings and Service Limits in Azure App Service.
In previous posts, we looked at the fundamentals of Azure App Service:
- It can use multiple programming languages to run your Web Apps or Services.
- Benefits of using App Service over on-premise hosting.
- The various App Service plans available.
- Manual or Automated deployment options using familiar tools.
- Integrate directly with multiple providers for authentication.
We then looked at how to deploy a Web App using both the manual deployment method and automated deployment using GitHub actions.
Deployment Slots
Let take a look at the concept of deployment slots based on our Web App deployment. You want to make changes to your application, but want to ensure that it is full tested before publishing the changes into production. Because we are using the free tier, we only have the “production” instance available to us and our default URL was this:
https://myday53webapp.azurewebsites.net/
Upgrading our App Service plan to a Standard or Premium tier allows us to introduce separate deployment slots for testing changes to our Web App before publishing into Production. For reference, the following is the number of slots available in each plan:
- Standard – 5 Slots
- Premium – 20 Slots
- Isolated – 20 Slots
We can upgrade our plan from the “Deployment Slots” menu within the Web App:
Based on the limits above, we could have slots for Production, Development and Testing for a single Web App. What this will do is create staging environments that have their own dedicated URLs in order for us to test the changes. So for example if we called our new slot “development”, we would get the following URL:
https://myday53webapp-development.azurewebsites.net/
Once we have our staging environment in place, we can now do our testing and avail of swap operations. This allows us to swap the production and development slots. In effect, this is exactly what happens – the old “production” slot becomes the “development” slot, and any changes that have been made in the development slot is pushed into production. The advantage of this approach is that if there are any errors found that were not discovered during testing, you can quickly roll back to the old version by performing another swap operation.
One of the other big advantages of slots is that you can route a portion of your production traffic to different slots. A good example of a use case for this would be to allow a portion of your users access to beta apps or features that have been published.
By default, new slots are given a 0% weighting, so if you wanted 10% of your users to access beta features that are in staging or development slots, you need to specify this on the Deployment Slots blade:
Scaling
There are 2 options for scaling and app in App Service:
- Scale up – this is where more compute resources such as CPU, memory, disk space. We can see the options available for Scale up from the menu blade in our Web App in the portal:
- Scale out – this increases the number of VM instances that run your app or service. As with Deployment Slots, there are maximum limits set on Scale out based on the pricing tier that is in use:
- Free – Single shared instance, so no scaling
- Standard – 10 Dedicated instances
- Premium – 20 Dedicated instances
- Isolated – 100 Dedicated instances
If using a Web App, we can also use autoscaling based on a number of criteria and triggers:
Full details can be found in this Microsoft Learn article. However, note that we must upgrade from the Free tier to use either manual or auto scaling options.
Conclusion
So thats an overview of Deployment Slots and Scaling options in Azure App Service. Hope you enjoyed this post, until next time!
Michael Durkan 