question

VeliJussiRaitila-8710 avatar image
0 Votes"
VeliJussiRaitila-8710 asked VeliJussiRaitila-8710 commented

Are there differences in uptime guarantees having 1 vs. 2 App Service instances?

The App Service SLA (99.95%) does not mention the number of instances. However, is there still a practical difference in site behavior e.g. possible downtime during maintenance operations executed by the Azure infrastructure team?

In other words, does having 2 instances instead of one still give you higher reliability when it comes to having potential service outages - particularly in a situation where the site requires a slightly higher than average warm-up time?

azure-webapps
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

VernerFortelius-5889 avatar image
0 Votes"
VernerFortelius-5889 answered VeliJussiRaitila-8710 commented

At some point I have run an AppService with three instances when one of them have failed. Without using an affinity cookie this then resulted in exactly every third request failing.
With the new HealthCheck feature I suppose this failing instance would eventually have been restarted, but this would still have resulted in downtime, and from our perspective it doesnt matter much if every request is failing or every third, the app is still essentially broken.
In this particular case the end result would therefore be the same with one vs more instances. Of course this case was an unplanned crash of an instance, so I suppose it may work in cases where an instance is recycled on purpose...

Iirc also the HealthCheck functionality in itself will only work if you have multiple instances, so in this cases it does make a difference at least in terms of automatic mitigation.
https://docs.microsoft.com/en-us/azure/app-service/monitor-instances-health-check

· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

In this situation, was the reason for the single instance failing a direct result of something your team did? Or something that just happened "behind the scenes" - and you never found out the root cause?

Regardless, I understand what you are saying. And interesting observation regarding HealthCheck.

0 Votes 0 ·

in this particular case it was completely "random", ie not a direct result of a code or configuration change. Actually it seems like the text about running health check with one instance has disappear since the feature became GA

0 Votes 0 ·

No it's still there

Your App Service plan should be scaled to two or more instances to use Health check.

Anyway, it certainly seems to me that the number of instances certainly does matter in terms of application downtime - it is not simply about scaling.

Sometimes having 2 instances or more might help, and even in your case you at least had "partial" service available. I would venture to guess that if you had only one instance - and the same were happen to it, you would not have had service at all.

Do you agree?




0 Votes 0 ·
SnehaAgrawal-MSFT avatar image
0 Votes"
SnehaAgrawal-MSFT answered VeliJussiRaitila-8710 edited

Thanks for asking question! Azure's App Service plans are already highly available, from a service perspective. That is, it's a multi-tenant service set up for high availability, where you don't need to worry about the infrastructure.

To add to this the compute resources may be on shared or dedicated virtual machines (VMs), depending on the pricing tier that you choose. example for Basic plan it is up to 3 instances and for Standard plan it is up to 10 instances. Subject to availability. However, the SLA doesn't apply to free/shared tiers.

You may refer to SLA for App Service here.

Just keep in mind: If, for some reason, your app needs to be restarted (e.g. app pool recycling or some other reason), you might experience momentary unavailability if you only have a single instance of your web app running.

This SLA works based on the fault domain and update domains, you may wish to understand how fault domains and update domains works in Azure.


· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

@VeliJussiRaitila-8710 Just checking in if you have had a chance to see the previous response. Let me know if you have any other question on this.

0 Votes 0 ·

Thank you for the response, but I think you avoided addressing my question directly.

On the other hand you are saying that "I do not need to worry about the infrastructure" and simultaneously expect me to be able to interpret how fault and update domains apply to App Service specifically?

To reiterate my original question: is there a practical difference in the uptime expectations having 1 vs. 2 App Service instances?

You do mention that I might experience momentary unavailability in case the app needs to be restarted - and I am aware that this might happen if I do that deliberately - but then I am also fully in control of the situation. The key question, however, is whether this (app pool recycle etc.) is something the Azure infrastructure team might also be forced to do as a part of some maintenance operation? Because if so, there definitely is a practical difference in the uptime guarantees.

0 Votes 0 ·

What I’m getting here is that in case the app needs to be restarted (and I suppose it sometimes will) as part of an unannounced maintenance operation - not by me, but by Microsoft, does it help to have 2 instances instead of one?

I have assumed, since the SLA does not discuss the number of instances, that Azure infrastructure team will do everything it can in these situations to prevent downtime (e.g. provision a new instance behind-the-scenes, warm it up and switch) - even when only 1 instance has been explicitly provisioned by me.

But it seems my assumption has been false. Or has it?

0 Votes 0 ·
gregslack-7120 avatar image
0 Votes"
gregslack-7120 answered VeliJussiRaitila-8710 edited

Having been running App Services and App Service Plans (ASP) for about 5 years now I can say that as an organization we did discuss adding redundancy to the app services (additional data centers and use traffic manager and/or front door) in order to achieve a greater HA score. In the end though the juice wasn't worth the squeeze both financially and from a management perspective given not a single outage of our services were due to a Microsoft issue with App Services (other Microsoft outages rendered the application useless but the App Service was "working").

To answer your question more directly (I think) when you say "does having 2 instances instead of one", I believe you are talking about "scaling out" the number of instances. This does not help you achieve high availability (HA), this just increases the processing power the app or apps on the ASP can handle. Think of the ASP as a nebulous blob of IIS/memory/compute ... by scaling OUT your are doubling, tripling, etc. the capacity for the processing of work behind an "invisible" load balancer.

· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

I understand what you are referring to, but no - “scaling out” is exactly what I mean.

Just keep in mind: If, for some reason, your app needs to be restarted (e.g. app pool recycling or some other reason), you might experience momentary unavailability if you only have a single instance of your web app running.

already indicates that scaling out a web app to multiple instances has other implications apart from performance. And what I’m asking specifically, is whether Microsoft might recycle the app pool (or e.g. the backing host VM) without notice. Since if they do, and if my app takes longer than average to warm up, it certainly would result in less downtime if I had more than 1 instance provisioned for the app.

And if this really is the case, I’m surprised it is not discussed more.

Furthermore, there is no magic in App Service. For the purposes of this discussion it is still all just IIS and VMs behind the scenes - albeit fully managed and load-balanced.

1 Vote 1 ·