High Availability in Azure: App Service, Function Apps

---

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 is pinned to a specific Azure Region. Any App Service Apps 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:

1. Provision them yourself (you’ll need to create new App Service Plans in those regions, if they don’t already exist).
2. 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.

[image attribution: Azure documentation]

The SLA for Azure App Services guarantee a 99.95% uptime for each regional deployment.

Azure Function Apps

Azure Function Apps too have regional deployments. If you’re using the consumption plan, then you explicitly specify the region. If on the App Service Plan, 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.

[image attribution: Azure documentation]

The SLA for Azure Functions 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), the scale controller 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 based on pricing tiers.
• Read more about ARR affinity and ARRAffinity cookies for scaled out instances.
• You can now enable per-app horizontal scaling. More details in this blog post.
• Read more about the scaling behavior 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.

Cloning and Moving App Service Apps

Using Azure Powershell, it is possible to create clones of existing App Service App within the same region or in a new region. Please note that there are some caveats/restrictions though.

You can also move an App Service App to another App Service plan 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 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.

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 or via the website) and see the WebSpace and SelfLink properties.

That’s all for today folks! Comments? Suggestions? Thoughts? Would love to hear from you, please leave a comment below or send me a tweet.

---