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.
Related
I have an Azure Function Premium plan for a C# function. I need this because my function needs to be deployed inside a VNET. Now I need to deploy another Python function. Can I reseuse my Premium plan? If I understand correctly it's a "server" which is running forever but which is only "used" when a function is triggered. Running two such a servers will be expensive and overkill for my functions.
Yes, you can run multiple Azure Function Apps in the same premium hosting plan, but the limitation is they should both run on same operating system either windows or Linux.
Running two such a servers will be expensive
Yes, it is expensive because of pre-warmed instances and always ready instances but predictable pricing.
The main 3 factors considered on Azure Functions are Application Insights, Network Traffic and Storage Account.
As per my experience,
Storage account is used by Azure functions for its internal state in which these costs are negligible.
When the functions are sending the traffic the outside world (Egress traffic), then the networking fees would occur which is usually low but may raise cost for high-volume data sending by the Azure Function.
Application Insights cost is the main factor we have to monitor and optimize. Refer to these few workarounds (Thread1 & Thread2) for optimizing cost in Azure Function - App Insights.
I am new to Microsoft Azure / Google Cloud and I am currently comparing these two different cloud solution providers, before starting a new project. I am planning to write a web application using either Google Cloud App Engine or Azure App Service.
I want to start with a very basic service instance, which I want to call via HTTPS. To reduce charges it would be nice to only pay for used service minutes resp. that the instance only runs, when needed.
Google Cloud offers dynamic instances, where compute instances are shutdown, when idle and started for incoming requests. Which seems way cheaper for a seldom used prototype and first usage of cloud services.
Instances are resident or dynamic. A dynamic instance starts up and shuts down automatically based on the current needs. [...] When an application is not being used at all, App Engine turns off its associated dynamic instances, but readily reloads them as soon as they are needed.
Unfortunately, I found in the Azure documentation only an Overview of autoscale in Microsoft Azure Virtual Machines, Cloud Services, and Web Apps, which does not cover my question of an automatic instance shutdown in idle state. Also Start/Stop VMs during off-hours solution in Azure Automation does not satisfy my information need, because I am looking only for a compute instance and not a full VM.
Is there an equivalent in the Azure domain, that allows to automatically start up and shut down app service instances, based on the usage resp. incoming requests?
Depending on the functionality of the two cloud service provider, I am deciding which one to use. Has anybody experience with this matter in the Azure domain? Thank you.
You can't do that with Azure App Service alone as of now (24-Feb-2019). But you could combine an Azure function to fire up a App Service instance and then forward all incoming traffic to an app hosted in this App Service via an Azure function proxy, see this description on learn.microsoft.com. I was planning to try this for while now too. In theory it should work... From experience, App Service instances fire up quickly, so the warm up time should be acceptable. Even better, you could keep free or shared App Service plan instance with your app running and forward the Azure function calls to it by default. On increasing load, move the app to a pre-configured plan which supports auto scaling.
Of course you could try to implement the entire app via a set of Azure functions which are fully "dynamic" using your terminology. Depending on the architecture of your application, this might actually be the best choice.
The Autoscale feature of Azure offers you to scale out/scale in based on configurable criterias, take a look here. You are limited by your pricing tier. Maybe this example will help you get an insight.
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 am concerned about the load performance of my Chat bot deployed in Chat bot service.
If for my Bots in production, there is sudden load of huge number of users chatting simultaneously, will my Bot handle that load.
Do I need to consider special criteria for auto scaling different than app service
As we know that Bot Service provides two hosting plans for your bots: App Service plan and Consumption plan.
And Consumption plan scales automatically, even during periods of high load.
Besides, if you host your bot application with an specified App Service plan on Azure web app and you configured autoscaling for the plan, then your bot application and other apps in that plan are scaled out together based on the autoscale settings.
As Fei Han mentioned above, Azure functions provides two option based on scaling and hosting capabilities: App Service plan and Consumption plan.
This article provides guidance to improve the performance and reliability of your serverless function apps.
The Consumption plan automatically allocates compute power when your code is running, scales out as necessary to handle load, and then scales down when code is not running. You don't have to pay for idle VMs and don't have to reserve capacity in advance.
With an App Service plan, you can manually scale out by adding more VM instances, or you can enable autoscale. And the other reason to consider this is, they support Linux.
You can decide by comparing both based on your business requirements. Hope this helps!!
I am trying to understand the azure service plan and how it effect our project's budget.
To give some background, we have two web applications running under Azure Cloud services in single instance auth.foo.com and api.foo.com. This was a good and convenient way to save some money as you still have to pay for one cloud service. We were doing this using hostheaders to deploy two apps on a same IIS instance.
With new WebApp model I understand we can not do the same thing.
Enter the app service plan. I understand its a grouping mechanism to group your apps so that they can be under one roof. The thing I am not clear about is how its billed? So If I have both apps under a same app service plan does it mean I get billed for two apps or just for one?
Think of an App Service Plan as a mapping from sites to servers. So you can have a large amount of small apps running on a couple of servers, or a small amount of large apps running on the same couple of servers. Provided that your App Service Plan is the same SKU and there are the same amount of instances in each, these will be the same cost.
That's why the billing page: https://azure.microsoft.com/en-us/pricing/details/app-service/plans/ has unlimited for the number of web apps. So to answer your question specifically, you will get billed for one App Service Plan regardless of the number of apps you have in it, since regardless of the number of apps, you'll be using the same amount of servers.