What is the best practice regarding App service plans. Is it best practice to have one App service and allow it to auto scale til capacity
Or is it normal practice to seperate some critical applications into their own app service. Microsoft has some recommendations. But want to know the general practice
https://learn.microsoft.com/en-us/azure/app-service/overview-hosting-plans
Regards,
Ujjwal
In case you have a multi-tier application, then you could consider separating the different tiers in different app service plans, so you can scale them independently according to the workload. One important detail to keep in mind is that if you have a single App Service plan for all your application(s), then the one or many applications under the same plan will share the same resources. If you want to leverage autoscale feature, and considering that your applications have different usage patterns, then again it would be good to have each app running on a separate app service plan, so you can scale just when it is necessary and just for that individual app.
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
We had a legacy monolith website application that is hosted on Azure windows server and had 10 customers using it, now as the application data grows the bandwidth of the application is affecting each customer because they were hosted in single server as a single website. Now the client wants to split the database as per customer separately to reduce the database load, so we divided the databases as per customer.
Regarding the website, we still had a dilemma on how to proceed, so we already divide the databases so we are thinking as
it is better to host each customer website on separate servers?
create a different website on a single server for each and every customer?.
Because the clients want this to be scalable and 100%, that one client’s activities and usage will not affect another, as well as be able to easily distinguish cost.
The client also asked to differentiate how much cost occurring for each customer on the resource groups,
previously we had a shared resource group.
Could anyone suggest how to solve this problem?
If your requirement fits you could leverage Azure App Service WebApps (PAAS solution).
You can host apps in the same App Service Plan or isolate your app into new App Service plan (as per your requirement) by having tradeoff between level-of control and costs.
Or to have greater control on the underlying VMs you could leverage Azure VMs (IAAS solution).
To start with, kindly take a look at this approach - Common web application architectures – monolithic application design using Azure App Service.
You could create the web application as separate App Service apps. This design lets you run them in separate App Service plans so they can be scaled independently. If you don't need that level of scalability initially, you can deploy the apps into the same plan and move them into separate plans later if necessary.
The pricing tier of an App Service plan determines what App Service features you get and how much you pay for the plan.
Azure App Service plan overview
App Service plans pricing
Azure offers a number of ways to host your application code.
Kindly checkout this architecture guide on compute decision choice
Resource Group is a just a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. It doesn't have direct cost implications, but the resources/services (in this case App Service) under it does.
You may wish to know:
Explore and analyze costs with cost analysis
Prevent unexpected charges with Azure billing and cost management
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'd need to use Traffic Manager to route traffic to three app services I have in the same region (one app service with three instances won't work, I need more control on the load balancing).
I read here that this is possibile
I tried to set up the app services in different app service plans but still I cannot assign the same domain to more than one app service. In the doc I read "scale unit" but I do not know what it is, any ideas? Basically I cannot create two App Services in the same region with the same domain assigned to them.
I am not really sure that you need more App Service Plans, but let's say you need.
Than what you will be looking at is nested profiles.
There is also good documentation which explains the limitations:
Each Traffic Manager profile can have at most one Web App endpoint
from each Azure region. To work around for this constraint, you can
configure a Web App as an External endpoint. For more information, see
the FAQ.
and workarounds for some of them here.
The scale unit, is the one that bugs you. #juunas is on the correct path to help you find your scale unit. However AppServicePlan is not a single VM, but that's another subject.
So the basic idea:
you create an app service plan
you create a web app within it
you rung the nslookup yoursite.azurewebsites.net to discover your real DNS name. Just like #juunas pointed, it would be something like waws-prod-am2-077.vip.azurewebsites.windows.net. The waws-prod-am2-077 is your scale unit.
You repeat these steps until you discover that your App Service Plans run on different scale units.
It is really pity that this is not documented anywhere. And no, there is no easier way to check the scale unit of an app service plan. Neither is there easier way to deploy multiple app service plans across different scale units.
On the other hand, having your app service plans spread across different scale units will give your app much better resiliasncy against partial service outages :)