Note: This blog post is part of a series centered around the topic of high availability in Azure:
- The basics
- SLAs and the 9s (coming soon)
- Availability sets
- Availability zones
- Storage redundancies
- Load balancing (coming soon)
- Application gateways (coming soon)
- Traffic management
- App Service, Function Apps (this post)
- SQL (coming soon)
- CosmosDB (coming soon)
- Wrapping up (coming soon)
I'll not be addressing scaling (horizontal or vertical), backups/restores and resiliency/healing in these posts. Each of those topics deserve their own series, perhaps I'll write about them in the future if time permits.
# Azure App Service Apps (web apps)
An Azure App Service Plan (opens new window) is pinned to a specific Azure Region. Any App Service Apps (opens new window) created in the App Service Plan will be provisioned in that same region. If your app needs additional redundancies in other regions or geographies, you'll have to:
- Provision them yourself (you'll need to create new App Service Plans in those regions, if they don't already exist).
- Use Azure Traffic Manager to route traffic to all available redundancies (you can only specify one App Service endpoint per region in a Traffic Manager profile). More details here (opens new window).
The SLA for Azure App Services (opens new window) guarantee a 99.95% uptime for each regional deployment.
# Azure Function Apps
Azure Function Apps (opens new window) too have regional deployments. If you're using the consumption plan (opens new window), then you explicitly specify the region. If on the App Service Plan (opens new window), then the region is the same as that of the App Service Plan.
Similar to App Services above, any additional redundancies will have to be explicitly created and traffic to these will have to be routed via Azure Traffic Manager.
The SLA for Azure Functions (opens new window) guarantee a 99.95% uptime for each regional deployment (for both app service plan and consumption plan).
# Miscellaneous
# Horizontally scaled instances
As I've previously mentioned, horizontal auto-scaling exists to address performance concerns rather than high-availability concerns.
App Service Apps: When horizontal auto-scaling is enabled on a parent App Service Plan, additional instances are created, and each instance hosts all App Service Apps contained in the parent App Service Plan. All instances are created in the same WebSpace. The App Service's integrated load-balancer (non-accessible) manages the traffic. Note that all scaled out instances of an app will still have the same endpoint URL.
Function Apps: Based on a combination of factors (trigger types, rate of incoming requests, language/runtime and perhaps the host health-monitor stats (opens new window)), the scale controller (opens new window) will create additional instances of an Azure Function App (max limit of 200 instances). Note that the scaling unit is the Function App (host) itself and not individual functions.
Bonus reading:
- Read more about the scaling limits imposed on App Service Apps (opens new window) based on pricing tiers (opens new window).
- Read more about ARR affinity (opens new window) and ARRAffinity cookies (opens new window) for scaled out instances.
- You can now enable per-app horizontal scaling (opens new window). More details in this blog post (opens new window).
- Read more about the scaling behavior (opens new window) of Function Apps.
# The "Always On" setting
If you have an App Service App or a Function App associated with an App Service Plan in the production or isolated tier, then you should consider enabling the "always on" setting. This ensures that your app is always running and never unloaded (default behavior is to deactivate/unload idle apps to conserve resources).
Notes:
- This setting is not available for App Service Apps in dev/test tier.
- Idle Function Apps in the consumption plan will be subject to cold start latency (opens new window).
# Cloning and Moving App Service Apps
Using Azure Powershell, it is possible to create clones of existing App Service App (opens new window) within the same region or in a new region. Please note that there are some caveats/restrictions (opens new window) though.
You can also move an App Service App to another App Service plan (opens new window) as long as both the source plan and the destination plan are within the same WebSpace.
FWIW, I've never tried this out myself.
And yes, like any other Azure Resource, App Service Plans and App Service Apps can be moved between resource groups.
# WebSpaces
WebSpaces are units of deployment for Azure App Service Plans. An App Service Plan's WebSpace (opens new window) is identified by the combination of its resource group and the region in its deployed. Any additional App Service Plan deployments to the same resource group + region combination gets assigned to the same WebSpace. See more details here (opens new window).
To see the WebSpace associated with an App Service App or App Service Plan, navigate to that resource in the Azure Resource Explorer (via the Azure Portal (opens new window) or via the website (opens new window)) and see the WebSpace and SelfLink properties.