I have a scenario where one of my Class has a static member whose value I can set from a Function App. Suppose another Function App belonging to same App Service Plan also uses this same class and also sets/relies on the value of the static member. Now, if the two function apps never run simultaneously, we have no issue. Also, if they don't run under same instance, then we also have no issue as each running instance will have their own definition of the class.
My question is, do each Function App from same App Service run on different instance?
I understand redesigning will eliminate any possible issues, but I am just curious on the interaction between Function Apps in same App Service.
I think it will be better for you to understand the process boundaries.
You have an Azure Function App (FuncApp1.azurewebsites.net) that may have one or more functions hosted on an App Service Plan. You're mentioning that you have another Azure Function App (FuncApp2.azurewebsites.net) with one or more of it's own set of functions hosted on the same App Service Plan. Is this correct?
FuncApp1 will have it's own process id, memory/cpu consumption, and threads on some machine in the cloud and the same for FuncApp2. The static member basically exists independently in two separate programs. In the case where your function app may scale out, each new instance will most likely have it's own process id, etc.
So NO your function apps will not step on each other. Your only concern should be if the static member is thread safe within the same process id. In what scenario are you relying on a static member that may be altered per request? Some incrementing ID?
My question is, do each Function App from same App Service run on
different instance?
I don't think this is possible, just as others have answered. All function apps are run on all the instances provisioned by your App Service Plan. But.. having said that, using per app scaling it is possible to limit the number of instance that a particular app service can be run on during scale out. I have not used this for Function Apps backed by App Service Plan; but an interesting read [https://learn.microsoft.com/en-us/azure/app-service/manage-scale-per-app]
From MS docs
When using App Service, you can scale your apps by scaling the App
Service plan they run on. When multiple apps are run in the same App
Service plan, each scaled-out instance runs all the apps in the plan.
Per-app scaling can be enabled at the App Service plan level to allow
for scaling an app independently from the App Service plan that hosts
it. This way, an App Service plan can be scaled to 10 instances, but
an app can be set to use only five.
Further, to your query on my comment; I think there are two cases here
a) Multiple Function Apps using the same App Service Plan using shared static class with static member
b) Multiple functions within the same Function App using shared static class with static member.
In both cases your static members are not shared. They are per function scope only. Just to be sure, I created two functions, FunctionA and FunctionB under a Function App (FunctionApp1). In both the functions, I refer to a static class Static1. I noticed that changes I make to the static members from FunctionA is not visible to FunctionB.
However, the static member state is preserved between multiple invocations of the same function under the Function App
I found a somewhat related question here https://stackoverflow.com/a/44971720/5344880
one another case would be different Function Apps using the same shared static class and I am reasonably sure that in this case the static class's static member's state is not shared.
Each function app from same App Service plan will run on every instances.
For example, if you have an app service plan which has 3 instances, your function app will run on each instances.
So for your question
do each Function App from same App Service run on different instance?
The answer is no, function apps from same App Service will run on the same instance.
Related
What is the difference between SingletonScope? Function & Host in Azure WebJob?
I have Time trigger hosted in two regions in AKS. I want to ensure that only one instance runs every time.
All my instances are sharing the same storage account. Can I use one of the above settings to configure my scenario?
Difference between WebJob host and Azure function:
The host is a runtime container for functions. The Host listens for triggers and calls functions.
In version 3.x, the host is an implementation of IHost.
In version 2.x, you use the JobHost object.
You create a host instance in your code and write code to customize its behavior.
This is a key difference between using the WebJobs SDK directly and using it indirectly through Azure Functions.
In Azure Functions, the service controls the host, and you can't customize the host by writing code.
Azure Functions lets you customize host behavior through settings in the host.json file.
For more information, see Compare the WebJobs SDK and Azure Functions
What is Singleton?
The Singleton attribute ensures that only one instance of a function runs, even when there are multiple instances of the host web app. The Singleton attribute uses distributed locking to ensure that one instance runs.
As in below example, only a single instance of the ProcessImage function runs at any given time:
[Singleton]
public static async Task ProcessImage([BlobTrigger("images")] Stream image)
{
// Process the image.
To learn more about how the SingletonMode.Function works see: https://github.com/Azure/azure-webjobs-sdk/blob/master/src/Microsoft.Azure.WebJobs/SingletonMode.cs
Further you can specify a scope expression/value on a singleton. The expression/value ensures that all executions of the function at a specific scope will be serialized.
Check this link for example: https://learn.microsoft.com/en-us/azure/app-service/webjobs-sdk-how-to#scope-values
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 I deploy one Azure time trigger function from one repo to multiple App Services?
Example:
Currently I have a repo with one Azure function in it (name Function1, runs every few mins).
I have 5 customers, I have a database for each customer and therefore I have 5 connection strings. Each customer requires me to host the function in isolated environment independent from the other customers.
The function "Function1" does the same logic for each of my customers. It just accesses a different database for each using the different connection string.
Therefore, I created 5 App Services: Function1-Customer1, Function1-Customer2, ... to satisfy the "independent environment requirement".
Each App Service has the unique db connection string assigned in the App Settings.
I tried to deploy the "Function1" to all these 5 App Services. However, when then going to see the Log Stream for any of the App Services it seems that only one instance of that function is running, depending on which App Service deployed last.
So for example, if Function1-Customer1 deployed last and I go to Function1-Customer2 or Function1-Customer3 to see the Log Streams, both outputs a conn string of Function1-Customer1. If Function1-Customer2 deployed last then I would see its conn string in all other App Services.
Is it possible to deploy the Function1 to serve all these 5 App Services? Or do I need a different architecture here?
The functions coordinate by obtaining leases in the underlying blob storage. If two function apps end up fighting over the same lease, they will block each other even though they are supposed to do different things. You can explore this by looking at the blobs in the underlying storage account an check the "lease" status.
Based on our discussion in the comments, I would recommend to use a dedicated storage account for each function app. I would not recommend AzureFunctionsWebHost__hostid or similar solutions, since it adds more complexity.
For each trigger Azure function manages it's own queue in Azure Queue Storage. You can use single function app and trigger 5 different tasks for each customer or you can create separate Azure storage account for each function app.
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.
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.