Demystifying the magic behind App Service OS updates
Oded Dvoskin
Well, that’s a loaded title for a blog post! But here’s the thing, we’ve been asked many times about what actually goes on behind the scenes when App Service updates the resources hosting App Service apps.
First, we need to mention briefly what is App Service. App Service is a PaaS (Platform as a Service) offering that allows customers to focus on their code, rather than having to worry about managing the underlying Virtual Machines and other resources with the latest security updates, OS patches and so on.
Still, those resources don’t get magically updated, do they? That is the beauty in a managed platform — we do that for our customers! App Service applies monthly updates to the resources, making sure our customers’ code is always running on the most recent security patches and OS versions available. As an example, this was extremely useful for our customers when the latest Spectre and Meltdown vulnerabilities were announced. Customers did not have to take any action because the service was updated automatically.
To give some additional technical details and demystify the process, we’ll outline here what happens when the App Service updates takes place , but first we’ll go through some key concepts:
When the update reaches a specific region, we update available instances without apps on them, then move the apps to the updated instances, then update the offloaded instances.
This move results in a cold start, and there may be a performance hit associated with this. Application binaries are loaded to the new Virtual Machine, and libraries are loaded from the disk. Externally the user will see a one-time delay in responses to requests to the app, after which the site will run normally. The delay is dependent on many things, mainly on the complexity of the app, the framework it’s built on, and dependencies. You can reduce the impact of cold starts on your application by properly configuring the App Initialization model, as detailed in this blog.
Thanks for reading and if you’d like to try App Service yourself, create your first app using one of our quickstarts and see how easily you can deploy your app and change your code right away.
If you have questions about App Service, please reach out to us through the developer forums, on MSDN or Stack Overflow.
- App (or site) – the structure that manages the code that is deployed for users.
- Instance – The Virtual Machine hosting the code. It can be in variations of memory allocation, CPU etc.
- Upgrade Domain – Collections of VMs in a given Scale Unit that are taken offline at the time of an update.
- Scale unit / Stamp – The collection of Virtual Machines in a given region.
- Region (or datacenter) – An area in the world where there is a collection of Virtual Machines managed by Microsoft. As of writing this blog, Azure is deployed in 42 regions worldwide.
- Paired Regions – Two Azure regions which within the same geography which Azure guarantees not to update simultaneously.
App Service update cycle:
First and foremost, it’s important to note that App Service assures and maintains its SLA at all times, even during updates. Though we try our best, the upgrade process can sometimes run for over 18hrs which causes the upgrade activity to spill over into business hours. Following our robust best practices, which can be found under the Diagose & Solve blade for your resource or in this article, will ensure minimal SLA impact even during platform upgrades. Before beginning worldwide updates, we deploy first to a private region which is not commonly accessible. Only after testing is validated there, we begin to roll out to datacenters across the globe. Our typical time for completing updates worldwide is about 10 business days, which allows us to deploy during each region’s off hours and also avoid deploying to Paired Regions at the same time (for example, East US and West US). When you are planning your app’s infrastructure for high availability and looking to deploy in multiple regions, it’s always a good idea to deploy to the paired region of your target region, since if there is a platform issue in the update, it won’t affect the paired region. After mitigating any issue, we will only then continue to the paired region, after the first is complete. As a managed service, we always leave a buffer in our capacity for new resources, for scaling operations on existing resources, in case instances become unhealthy and force us to move apps to other instances and of course for our OS update process, detailed here.
When the update reaches a specific region, we update available instances without apps on them, then move the apps to the updated instances, then update the offloaded instances.
This move results in a cold start, and there may be a performance hit associated with this. Application binaries are loaded to the new Virtual Machine, and libraries are loaded from the disk. Externally the user will see a one-time delay in responses to requests to the app, after which the site will run normally. The delay is dependent on many things, mainly on the complexity of the app, the framework it’s built on, and dependencies. You can reduce the impact of cold starts on your application by properly configuring the App Initialization model, as detailed in this blog.
Thanks for reading and if you’d like to try App Service yourself, create your first app using one of our quickstarts and see how easily you can deploy your app and change your code right away.
If you have questions about App Service, please reach out to us through the developer forums, on MSDN or Stack Overflow.