Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last month.
Improve this question
If I deploy a bunch of Azure Functions in to a functions app and setup the functions app to use a consumption plan, then each calendar month the compute cost for the first 1 million calls is basically free.
How come I can't do this with a web API using something like MVC or OData?
The only difference I can see is the framework parts used, presumably there's some infrastructural reason for this?
Which leads to ...
I'm tempted to make all API implementations a set of Azure Functions to make the most of cloud costs but it feels like I'm making the infrastructure costs dictate my technical decisions a little too much here or that I'm missing something.
As a sort of secondary question if there's any MSFT peeps out there, would Microsoft consider making it so that all Azure app Services can be consumption planned?
The big difference between an App Service and a Function App is the fact that, for your App Service, there's an App Service Plan dedicated to run the App Service which reserves a set of resources like CPU and memory.
An App Service plan defines a set of compute resources for a web app to run. These compute resources are analogous to the server farm in conventional web hosting. One or more apps can be configured to run on the same computing resources (or in the same App Service plan).
When you create an App Service plan in a certain region (for example, West Europe), a set of compute resources is created for that plan in that region. Whatever apps you put into this App Service plan run on these compute resources as defined by your App Service plan.
Source: Azure App Service plan overview
For a Function App on a Consumption Plan, this is a specialized version of an App Service Plan. In that case you have a lot less to say about how that plan is configured or what resources it gets: that's all abstracted away for you as a user.
When you're using the Consumption plan, instances of the Azure Functions host are dynamically added and removed based on the number of incoming events. The Consumption plan is the fully serverless hosting option for Azure Functions.
Source: https://learn.microsoft.com/en-us/azure/azure-functions/consumption-plan
And while the Azure Functions Host is the application constantly handling requests by checking to see if your Function App is being called and requests need to be passed on to your code, in a more traditional application like an MVC app, it is your application that actually handles the request beginning to end.
EDIT
why can't I put an MVC controller up on the same contract terms in the cloud as I can with an azure function
Because the current implementation of an App Service is "analogous to the server farm in conventional web hosting", meaning it expects an entire web application. An Azure Function expects a piece of code that can handle the request (better: trigger). A controller is more than just that, and has some (a lot...?) of fluff around it to be able to work.
And, somewhat simplified: because it hasn't been made available by Azure. Presumably because it would make Azure Functions way too biased on how the (.NET, HTTP triggered) function should be implemented.
Abstraction: a Function is a piece of code that can handle a trigger. This trigger can be a lot of things, one of which is a HTTP request. From the Functions runtime's point of view, all triggers just need to be mapped to a handler. Currently, that handler could be considered framework agnostic, Azure Functions only prescribes it adheres to a certain signature.
By allowing developers to host an MVC Controller as the handler for an Azure Function, this would also mean it needs to have all the fluff around the controller either be in place (what, how, ... ?) or the controller be slimmed down to 'just' be a handler for a HTTP trigger... which would make it a regular Azure Function.
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.
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.
Please help me understand why we say azure functions is a serverless compute service. It does require cloud to host it and run. Cloud is also a server still why we are saying it is serverless?
Serverless computing does not mean that servers are out of the picture. Servers are very much required, just like they have been for all these years, or else, where will your code run. The reason why the phrase was coined is that as a developer, you do not need to worry about what server your code runs on. In fact, you do not know which server it eventually runs on. Once your code is deployed, Azure assigns the responsibility of executing the code to the next available server. What Azure ensures, and what is ultimately important for you, is that your code will execute whenever required.
Ref: Serverless Computing with Azure Functions
Hope it makes sense :)
To get a better idea this is how we evolved. Cloud providers are making sure we should only worry about the business logic but nothing else.
IaaS (Infrastructure as a service)
You get a running VM somewhere in the data centre but you are required to maintain everything. From Deployment to patching your VMs or anything running on the VM.
PaaS(Platform as a service)
You are not longer required to maintain platForm but you are still responsible to manage your server in terms of load balancing etc.
FaaS(Function as a service)
Servers are abstracted from you . You are only required to maintain your code without worrying about what's under the hood or how to load balance your servers. It's then cloud provider responsibility to package your code and run it for you. But servers are still there.
Going by the official documentation of Azure Serverless computing service, Azure Functions can be defined as;
Azure Functions is a serverless compute service that enables you to run code on-demand without having to explicitly provision or manage infrastructure. Use Azure Functions to run a script or piece of code in response to a variety of events.
Azure Functions is an event driven, compute-on-demand experience that
extends the existing Azure application platform with capabilities to
implement code triggered by events occurring in virtually any Azure or
3rd party service as well as on-premises systems. Azure Functions
allows developers to take action by connecting to data sources or
messaging solutions, thus making it easy to process and react to
events. Azure Functions scale based on demand and you pay only for the
resources you consume.
Here the serverless compute service is like a metaphor which implies, the end user doesn't need to manage the servers or infrastructure to run the applications over the Azure and can spend time to focus on managing and improving the business logic.
Few more points to consider,
Serverless in Azure builds on an open-source foundation, the core of
which is Azure Functions, an event-driven compute experience and open
source project. Community contributions include support for new
languages, integrations and deployment targets.
Azure Functions can be used on-premises, in hybrid environments such as Azure Stack, on IoT Edge devices and deployed on top of orchestrators such as Kubernetes – as well as in other clouds.
They enable faster time to market with lower infrastructure and operating costs.
There are heaps of definition of serverless which you can easily google. But I will share my understanding anyways.
1. It does require cloud to host it and run.
You are correct with this. But anything on Cloud requires Cloud, doesn't it? Azure being one of the cloud providers consists of hundreds of services to cater to different needs people are after from using Cloud.
2. Cloud is also a server still why we are saying is serverless
This is not quite right. Cloud is different from a server. Server is a physical box sitting somewhere. With hundreds of thousands of servers all over the world, Cloud hosts all sorts of different services on these servers.
The reason we say Functions are serverless is that the infrastructure of hosting a Function is abstracted away from devs. It is still deployed to some servers but Azure is responsible for all the resource managing, configuration, load balancing, scaling and networking etc. It allows developers to focus primarily on their code, not having to worry about servers.
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.
This is my azure payasyougo usage cost for this month.
I'm struggling to understand why I would be charged for a Standard Medium App Service, I would of thought that it would be included in the compute hours? I have only one Cloud Service running and this seems a bit steep for a cloud service that is not doing much...
Any suggestions?
While pricing is off-topic, I think I can answer this from a general operational angle (even though this will likely be closed since it's not programming-related).
As your graphic shows, you are consuming resources for different services. Compute-hours equates to your virtual machines that you've deployed, and you're consuming those resources whether you're using 0% or 100% CPU / memory / network, whether you've deployed code or not. They are allocated and, as far as Azure is concerned, deployed for your use, no matter what you're doing (or not doing) with them.
When you created your App Service, that was yet-another set of resources deployed. And another set of resource-hours you're consuming (again, whether you use 0% or 100% is irrelevant).
Same thing would happen if you created a database instance or any other Azure service: You'd pay in whatever way is described for that particular service. And each service has its own specific cost which is described in detail in Azure's pricing page.
There's no nesting of separate services. In your specific case: there's no concept of creating an App Service inside a Virtual Machine (nor is there any hint of that anywhere). They are two separate services.
Computer covers only Virtual Machines and Cloud Services. Pricing can be found here:
https://azure.microsoft.com/en-us/pricing/details/virtual-machines/
App Services are "special", while they internally use compute resources behind the scenes, they are charged based on the tier of performance and SLA you want to achieve. Pricing for them can be found here:
https://azure.microsoft.com/en-us/pricing/details/app-service/
You will notice that there is a PREMIUM price for the same level of service on App Services. The theory is that the App Service stack is providing more managed value and thus worth more. For my use cases I have not found this to be the case and instead choose to run our environments under the PaaS VM / Cloud Service stacks.