I have a function set up with ServiceBusTrigger which runs when it is deployed and then keeps running while I'm testing and sending messages to a topic. However, if I wait an hour or so and then send more messages they are not processed until I either restart the function app or disable and reenable the actual function.
How can I change this so that the function is always "on"?
Sounds like you are using a dedicated App Service Plan. Make sure you have "Always On" enabled. You need to have at least a "Basic" plan. If you don't want to pay for a basic plan, I suggest you use a consumption plan.
https://github.com/Azure/Azure-Functions/wiki/Enable-Always-On-when-running-on-dedicated-App-Service-Plan
How do I turn on "always-on" for an Azure Function?
Related
I have a background worker that listens to a service bus (Azure Service bus) for messages.
Each message stands for an async task that the service should work on, but for the case that no event is reaching the bus, I also want to trigger the service automatically each day.
The service bus is currently triggered by user events that are generated in different APIs.
This works fine, but who should trigger my service with a certain schedule?
I could of course write a second service that sends a message to the bus each week, but it feels kind of overkill to have a service running only for this task.
I am wondering if there is a better solution how I could do this? Even an Azure Function seems overkill for me...
How would you address this issue?
Azure Functions are ideal because you can create both a timer triggered, and service bus triggered function in the same Function App.
If you feel it is excessive, I suggest the other option is to use the Azure Web jobs which can run in the App Services.
You can have timer-triggered Web jobs and use that Web job SDK to trigger them whenever there is a message in the Azure Service Bus.
Refer to the Scheduled Webjobs and Service Bus triggered webjobs for more information.
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.
I have a (C#-based) Function App on a consumption plan that only contains queue triggers. When I deploy it (via Azure DevOps) and have something written to the queue, the trigger does not fire unless I go to the Azure Console and visit the Function App. It also works to add an HTTP trigger to the App and call that. After that, all other triggers work.
The same phenomenon is observed with Timer triggers.
My hypothesis is that these triggers only work when the runtime is active but not directly after deployment when no runtime was created. Is that true? If so, what is the suggested way around this?
My only workaround idea is to add an HTTP trigger and fire regular keepalive pings to that trigger. But that sounds wrong.
I have an app service that I use from time to time (test env). How to configure it to auto-close when I do not use it?
App Service always incurs cost so that is not possible. You can create it when you need it using some sort of automation (powershell\cli\arm templates\etc) and delete it after you dont need it.
another option - colocate it with some other App Service which you need all the time, so it will just use small fraction of that app resources (wont cost anything extra).
I would recommend to use Dev/Test option if you are really worried about pricing.
Dev/Test pricing applies only when you run the resources within an
Azure subscription that is based on one of the Dev/Test offer
May be a delayed answer but I have found an elegant solution. There is a "Always ON" flag in the settings page that can be used for this purpose.
Location
AppService --> Configuration --> General Settings --> Platform Settings --> Always On.
Usage
Always On: Keeps the app loaded even when there's no traffic. When Always On is not turned on (default), the app is unloaded after 20 minutes without any incoming requests. The unloaded app can cause high latency for new requests because of its warm-up time. When Always On is turned on, the front-end load balancer sends a GET request to the application root every five minutes. The continuous ping prevents the app from being unloaded.
Always On is required for continuous WebJobs or for WebJobs that are triggered using a CRON expression.
For dev/test there is an app service plan that is free (it has the "Always On" setting turned off and disabled). Create a Free F1 app service plan and then assign your app service to use that plan.
I am using Azure Functions V2 with a Service Bus trigger using 1.0.23 of the C# Functions SDK. I'm using the following approach to get secrets from KeyVault and use them within the settings of the triggers: How to map Azure Functions secrets from Key Vault automatically
The function, especially when it has done nothing for a while, doesn't fire when there are messages on the subscription. If I then go to the portal and execute manually (yes, that particular execution is fired with a null message) it kicks it into life and picks up the other messages on the queue and processes them correctly.
This obviously isn't ideally for our automated tests. Has anybody seen this, or know of anything that will help?
Also, the Function App is running on a consumption plan.
App Service Plan
If you're using App Service plan then it's simple, just make use of Always on
Consumption Plan
If you're using Consumption plan, the issue could be that your triggers did not sync properly with the Azure Infrastructure (Central Listener). It could have happened due to the way you deployed/edited your trigger related settings as explained in issue #210 below.
When you access the function directly from Portal, it might be forcing your function app to come alive, but as you can see that's only a workaround. Something similar is mentioned here
Take a look at these issues:
Service Bus Topic Trigger goes to sleep - Consumption Plan
They also mention that it wakes up only on accessing it via the portal or calling a HTTP triggered function in the same app, which is similar to the behavior you are seeing.
Issue #210
Issue #681
There are 3 suggested ways to resolve it, mentioned as part of Issue #210 above
In order to synchronize triggers when these deployment options are
used, open the Azure Portal and click the Refresh button, or make a
API call to the sync triggers endpoint:
https://github.com/davidebbo/AzureWebsitesSamples/blob/master/ARMTemplates/FunctionsWebDeploy.json#L90
Powershell sample:
https://github.com/davidebbo/AzureWebsitesSamples/blob/master/PowerShell/HelperFunctions.ps1#L360-L365
I've had a similar issue. ServiceBus connection was injected using ServiceBus value in ConnectionStrings section of Function configuration. This is enough when Function is in hot state but after transitioning to cold state AzureWebJobsServiceBus value is used to connect to service bus. So in my case setting AzureWebJobsServiceBus to ServiceBus connection string in Function configuration fixed this.