I've created Azure function using Visual Studio as library project, have single project with 12 functions
e.g.
As of now my function hosted in Dedicated AppService Plan and one of function (EventHub listener) processes millions of message per-day, hence it utilizes 90%+ CPU all the time.
So we are planning to scale or Separate App Service plan for that single function. I see following possible solutions
Change dedicated app service plant to consumption. (not sure about pricing impact or SLA).
Create a new project, move single function in that project and deploy that function in a separate app service plan. (required code and CI/CD pipeline changes.)
Deploy same function dlls in 2 AppService Plan and remove functions according to scale. (not sure this is possible with Azure DevOps or not).
would like to know the better approach, if customer does not agree on consumption plan.
The advantage of a dedicated plan over a consumption plan is predictability. Running a workload on a consumption plan will usually work out faster and cheaper than running the same workload on a dedicated plan, but using a dedicated plan does prevent unexpected spikes in usage from leading to unexpected spikes in cost and also prevents cold start issues.
If you switch to the consumption model (option 1), you're paying for individual function execution so whether you run one or two function apps makes no difference from that point of view. You should decide how to split your functions based on how independent they are. If you'll only be deploying them as a single unit then stick to one function app, but if you may want to update the listener separately, put it in a separate project.
If you split into two apps running on separate dedicated service plans, creating a new project (option 2) is certainly the cleanest way to go about it. However, deploying the same project to both apps (option 3) is technically possible - you just need to disable the functions that shouldn't run on each app using app settings. Create settings named AzureWebJobs.MyFunction.Disabled with value true (see https://learn.microsoft.com/en-gb/azure/azure-functions/disable-function#functions-2x---all-languages).
wont help you, it scales all the functions in the function app
that will work
its the same as version, just with 2 app service plans, not one.
Better approach is - isolate this function into a single Azure Function App and then you can scale it independently.
Related
When hosting an Azure Function in an App Service Plan, are there any significant differences compared with using an App Service (EDIT: for a restful API) associated with the same App Service Plan? I assume the only difference is that the Function offers additional out of the box triggers. Any differences I'm missing that would lead to preferring one over the other?
I'd also like to confirm that hosting Azure Functions in an App Service Plan can actually limit scalability if scaling is not configured on the App Service Plan. As I understand it, Functions automatically scale as needed when using Consumption or Premium hosting without additional configuration.
When hosting an Azure Function in an App Service Plan, are there any significant differences compared with using an App Service associated with the same App Service Plan? I assume the only difference is that the Function offers additional out of the box triggers. Any differences I'm missing that would lead to preferring one over the other?
Well, an Azure Function is a different beast than an App Service. An Azure function is triggered by an external event or a timer. It then executes the code of the function. When hosted on a consumption plan this execution is allowed to run for 5 or 10 minutes max. When you need a longer execution time you need to run it on an App Service Plan.
An App Service can host any app you've created. Like a website (that runs continuously and doesn't need to be triggered before it starts doing something) or an api for example.
I'd also like to confirm that hosting Azure Functions in an App Service Plan can actually limit scalability if scaling is not configured on the App Service Plan. As I understand it, Functions automatically scale as needed when using Consumption or Premium hosting without additional configuration.
Correct, when hosting Azure Functions in an App Service Plan you are responsible for making sure the app service is scaled to allow the function to perform well under load. Thats why the consumption plan is designed to handle this so the developer can focus on the functionality and does not need to worry about the infrastructure.
So, for integration scenario's azure functions are a very natural fit. For web sites an App Service might be the best solution.
To address your comment:
I should have mentioned that this question was in the context of hosting a restful API and not a UI application. In this scenario, I'm not seeing much difference between a Function and App Service, but please correct me if I'm missing something
A couple of things: For one, there is a certain sweet spot. If traffic is heavy enough a consumption plan based azure function might be more costly than having a dedicated app service plan. That depends of course on a lot of factors (CPU usage, request duration etc.). Also, you won't be able to use things like Asp.Net Core Middleware out of the box.
Finally, I'd argue that if your api is becoming large enough managing a single asp.net core solution may be easier than having to manage a lot of azure functions with small functions or one azure function project with lots and lots of functions, but hey, that's just my opinion (haven't actually dealt with it to be honest)
Some resources to consider:
https://www.taztopia.com/single-post/2019/07/28/azure-function-vs-web-app-aka-serverless-vs-paas
https://dasith.me/2018/01/20/using-azure-functions-httptrigger-as-web-api/
The main difference is in how you pay for it:
Azure Functions Consumption plan you pay per execution
Azure Functions in an App Service (dedicated plan) you pay for the allocated hardware per minute.
You also have control of which VNET your functions run in when you use an app service plan. You may have security requirements that make this important.
You are correct that if you run it in an app service that is not configured to scale, then throughput will be limited by the allocated hardware.
For details see: https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
If you are having limited and predictable workload then deploy az function in AppService plan with supports VNET integration for private compute otherwise go for Premium plan which will provide autoscaling capability of your compute environment.
Can anyone tell me or explain me what are the limitations/drawbacks of deploying multiple micro services (say 2-3) on a single Azure AppService server?
To achieve following we use microservies
Serve a single purpose or have a single responsibility
Have a clear interface for communication
Have less dependencies on each other
Can be deployed independently without affecting the rest of ecosystem
Can scale independently
Can fail independently
Allow your teams to work independently, without relying on other teams for support and services
Allow small and frequent changes
Have less technical debts
Have a faster recovery from failure
But How the Azure app service works when we try to deploy one of the microservice? will it impact other mircoservices? can we use this it in production environments?
I came across few links hosting mutiple apps on single appservice by defining virtual path for windows and for linux by adding azure storage but is it best/good practice to do?
No, it's not. They will compete for compute resources, and in case of hardware failure all of them will go down.
It sounds like you're referring to hosting multiple App Service apps in a shared App Service plan. This is conceptually (and physically) the same as running multiple apps on a server, and I would think about pros/cons along those lines.
You can host many apps on the same plan as long as the plan provides enough memory/CPU/network resources to cover the needs of the combined demands of those apps. For a few small apps, a modest plan size shouldn't have a problem handling all of them in production. The main benefit of combination is saving costs, since the plan is the unit of charge, not the apps.
Microsoft documents some reasons to isolate apps on separate plans:
The app is resource-intensive.
You want to scale the app independently from the other apps in the existing plan.
The app needs resource in a different geographical region.
From my experience, I'd add some considerations:
Deployment and restarting of apps can cause CPU spikes for the plan (which is a server). If your apps are performance sensitive and you deploy often, you might want more separation
Azure maintenance requires servers to restart at least once a month or more. If all your apps are on a shared plan, a patch reboot can mean the entire system is down and that all apps compete for resources when starting up simultaneously
I generally use separate plans as environment boundaries, so a production plan separate from a test plan. "Test" apps go on test plan, "Prod" apps on production to prevent testing from impacting users.
Azure Functions may be better fit for hosting many microservices
I am working on a HttpTrigger based azure function and trying to figure out the scaling and cold start issues.
While looking into scaling, I found that the azure function documentation states that the
"instances of the Azure Functions host are dynamically added and removed based on the number of incoming events"
which has confused me as to how does the number of events determine the scaling out of function instances, as different function can be of different sizes in terms of how much compute power or memory they require to execute.
And where exactly can I find this "number of events" that supposedly triggers a new instance to be added?
You won't find a specific "number of events," it's based on a wide variety of factors that Microsoft measures to determine the load of the currently running instances. Functions that are grouped together in a single project and deployed as a single Function App on Azure scale together. If you need functions that consume different levels of resources to scale independently, then be sure to deploy them as separate Function Apps (in the C#/VS world, that means different Projects).
If you have cold start issues, then the Premium plan can come into play. You pay for at least one instance to always be on and "pre-warmed" so that you never have cold starts. The plan will then scale from there based on the previously mentioned "events" that Azure measures to determine if scaling out is needed. MS has said that scaling out tends to be faster on the Premium Plan. You also get a longer default function runtime on Premium if that is necessary (30min vs 5min).
When I create an Azure Function App via the portal, it's not possible to select whether an existing Consumption Plan is used or a new one gets created.
However, it is possible to do so via ARM Templates.
Azure Function Apps: Organizing the Azure Function Apps under same Consumption Plan discusses this, but it does suggest no implications.
What are the practical differences between having 1-on-1 mapping between Consumption Plans and Function Apps vs. many Apps in a single Plan?
In practice, for apps in a consumption plan, there really is no difference whether they're in a plan created for that app only (trying to avoid the word dedicated here to avoid confusion :) ) or sharing with other apps. The behavior will be the same.
That's an interesting question. IHMO, it should not be a problem until you need to scale both function apps. You need to be aware of App Service sandbox limits. More info: https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#numerical-sandbox-limits
I'm using consumption plan functions.
I can add a new function to an existing App Service or I can create a new App Service. I just realized that I don't have an adequate understanding of in what situations one should add a new App Service. Would appreciate any high-level guidance on that.
Remember that the unit of scale for a function is the Function App. So if the runtime determines that one function needs to be scaled, it will scale the Function App and all functions within it.
If your function can run in the consumption plan (finish within 5 minutes) and is logically related to the other functions, then I would probably add it to the current consumption plan.
However, if it needs to run for longer than 5 minutes or it is not related to the other functions, I would separate it to its own plan.
As far as I'm aware, consumption plan can scale "indefinitely", so there is no real reason to create another App Service, unless you want to logically separate those, or give out specific permissions (as you can't have permissions to functions inside Azure Function) or say, you want some of them to be configured from Git and some not.