Add Application Initialization Support for Scale Up/Down
The application initialization/warmup feature works great when scaling out/in, but when scaling up/down requests are immediately routed to the new instances before the application is warmed up. It would be great if the new instances could be warmed up before rerouting requests to them.
Placing under review per Ruslan’s comments. We don’t have a timeline to share, but we will update the item once there is more information available.
can we do auto-scale in / out or up / down via Azure Policy ? The users create a service plan, after an policy starts and applies the config auto scale rules on this service plan (deployifnotexist) ?
is it possible ?
Craig Humphrey commented
Just added my vote to this.
An additional comment: I'd like to be able to auto-scale up/down, similar to the in/out, primarily around situations like:
- I know the pattern of my users and it's more cost effective to run a tiny system (with the potential to scale out [or up], if I get caught out) during off-peak times.
- I know I'm about to get an increased base-level load (just onboarded a new client with 100's/1000's users, or new version of the software is slower...), so my existing (single server) performance level is too low. But I don't want to interrupt my existing (24/7) users...
- I have background tasks (web jobs), that need more performance (e.g. big overnight processing), where scale-out doesn't help.
Dustin Smith commented
Thanks for the reply, I would agree that in/out should happen more than up/down.
We're not using app services in production yet, but we're in the process of getting there. My concern is we pick a pricing tier, and we're pretty much stuck with it.
If we determine an S3 is more powerful than we need, and we can go back to an S2, we're going to experience some downtime. That's partly our own fault since our application takes a while to warm up, but the scale in/out works so well that I was hoping it would work the same with up/down. I understand that it's probably more difficult.
If I had to guess, I would say we would only scale up/down 3-4 times per year. In/out I'm going to guess is going to happen far more often.
Thank you Dustin for the suggestion. We have this work item in a backlog but considering it is a significant change to the routing logic it will take a while before we have it available in production.
Our expectation so far has been that the scale up/down is performed much less often than scale out/in. That's why appinit and auto-scale are only supported for scaling in/out. It would be useful for us to learn how often do you need to perform scale up/down comparting to scale out/in.