Scaling on consumption plan: inconsistent documentation

[rvdginste]

It is not clear to me how function apps scale that share the same consumption plan. The documentation on this is inconsistent.

Excerpt from Azure Functions Consumption plan hosting:

Function apps in a given plan are all scaled together, so any issues with scaling can affect all apps in the plan.

Excerpt from Event-driven scaling in Azure Functions:

Function apps that share the same Consumption plan scale independently.

I was a bit surprised to read that all function apps in the same consumption plan scale together... that does not make sense to me. Can you confirm which of the above is in fact the correct one?

[rvdginste]

And I found other documentation that claims it scales independently...

Excerpt from Organize functions for performance and scaling:

When using the Consumption plan, we recommend you always put each app in its own plan, since apps are scaled independently anyway.

[v-bbalaiagar]

Hi @pragnagopa , Can you check if we can give some more insights in the documentation

[pragnagopa]

@cachai2 - assigning this to you for now to help clarifying issues in the docs. Please reach out to @chiangvincent @TsuyoshiUshio if you need more details.

[rvdginste]

@v-bbalaiagar @pragnagopa

Updating the documentation is one thing, but that seems to take a while. Does anyone know the answer to the question: do all function apps within the same plan scale together, or scale independently from each other?

[TsuyoshiUshio]

I tested. It scales par site. According to the scaling logic on Scale Controller. We scale per site, so that the result is make sense. I forcefully use the same AppServicePlan as dynamic.

@ggailey777 Do you know the context?

However, the scaling logic is different between http scaling that is not done by scale controller and the other (e.g. queue based) is different. If he doesn't have a context I'll do one more repro.

[ggailey777]

I would have to do some deep research to determine how we ended up with conflicting guidance. Since some of it is in best practices, maybe @FinVamp1 remembers?

[rvdginste]

@TsuyoshiUshio

Thanks for the answers, those things are clear now. However, I didn't think about that with my last comment, but in the mean time, requirements for our project changed and vnet integration is needed. This means we can no longer use the "consumption plan", but we could go with the "elastic premium plan". I assume that the scaling logic on that plan is exactly the same as on the consumption plan, because that is what the documentation says.

However, what is not clear from the documentation is how pricing works on the "elastic premium plan". I find the following at Pricing - Functions.

Azure Functions Premium plan provides the same features and scaling mechanism used on the Consumption plan (based on number of events) with no cold start, enhanced performance and VNET access. Billing for the Premium plan is based on the number of core seconds and memory allocated across instances. There is no execution charge with the Premium plan. At least one instance must be allocated at all times per plan. To learn more, see Azure Premium Plan details.

The reference to "Azure Premium Plan details" is not a link, so it's a bit hard to find where that reference is. Could that be added?

I do find documentation on the Elastic Premium plans (Azure Functions Premium plan - available SKUs) and EP1 has 1 vcore and 3.5GB of memory. So the minimum monthly price is based on 1x vCPU price + 3.5x GB-month price? So I assume that is the base price per month. But I have a couple of questions with that.

If the function apps scale independently of each other, then what is the role of chosing EP1/EP2...? Suppose I have 2 function apps: app1 and app2. At some point a bulk of queue messages arrives that need to be processed by app2. So app2 scales out to 10 instances for 1 hour. Then how is the extra price calculated? 9x vCPU price for 1 hour + the amount of GB that app2 uses for 1 hour? Or is it 9x the base price for EP1?

And what about when at the same time bulk arrives for both app1 and app2. App1 scales out to 5 instances and app2 scales out to 10 instances? How is the extra price calculated then? Both for app1 and app2 separately and then added? Or 9x the base price for EP1?

If, upon scale out, the price is calculated in function of the base price for the chosen Elastic Premium plan, then what is the difference with just deploying the function app on 'normal' app service Premium plan? I am aware of the difference regarding auto/dynamic scaling, but I assume that one can easily setup auto scaling on a normal app service Premium plan based on cpu load. I am aware scaling will not react completely the same way, but are there any other differences between both plans in that case?