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
Related
I have a couple unrelated websites that I host using the free subscription of Microsoft Azure. They are currently all under the same Resource Group and same App Service plan (though I don't understand those concepts well enough to know if they should or shouldn't be).
In the past, I've had a problem with individual apps eating up large amounts of some resource, like CPU Time or Data Out. The issue is that they all share one quota... so if Website A has a problem that consumes all the CPU Time for the day, then Website A, Website B, and Website C ALL go down until the quota resets, even though Website B and Website C aren't contributing to the problem.
In short, how do I prevent that so that each website has its own quota (not a shared quota)? Can I separate the websites into different Resource Groups? Different App Service plans? I tried to understand Microsoft's documentation on how these quotas work, but I was unable to find the answer to my question.
Thanks!
I have a couple unrelated websites that I host using the free subscription of Microsoft Azure. They are currently all under the same Resource Group and same App Service plan (though I don't understand those concepts well enough to know if they should or shouldn't be).
Resource groups define a way to group multiple related azure resources together. Typically all resources in the same resource group are deployed together, for example using ARM/Bicep templates.
An App Service plan defines a set of compute resources for web apps to run.The free tier provides 60 minutes of cpu time per day. You can host multiple web apps on the same plan, as you do. But in that case they all consume parts of that 60 minute cpu time quota.
In short, how do I prevent that so that each website has its own quota (not a shared quota)? Can I separate the websites into different Resource Groups? Different App Service plans? I tried to understand Microsoft's documentation on how these quotas work, but I was unable to find the answer to my question.
If you do not want to share the cpu time between the multiple web apps on the same app service plan you can create a free tier App Service Plan per web app, and deploy each web app to their own dedicated free tier App Service Plan.
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
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.
Does Azure charge only for the utilization of App service plan resources or for the number of app services we create under that App service plan? Does the number of app services created under a app service plan effects cost?
I am developing a microservices project and I am unsure of whether to deploy each microservice in a dedicated app service or deploying all in one app service as virtual directories. Cost is a concern for our project.
Thanks.
Does Azure charge only for the utilization of App service plan resources or for the number of app services we create under that App service plan?
Ignoring the Free and Shared tiers, you'll pay only for the App Service Plan (cost per selected machine size x number of instances). You'll pay the same whether you have 0 or 50 Apps on the Service plan (although any other I/O, Storage etc consumed by those Apps will be additional).
(Whereas the free tier allows a max of 10 Apps, and the Shared tier allows 100 Apps)
In theory you can then add as many App Services (apps, e.g. Web Apps, Services, Function Apps etc) as you like on each App Service Plan, however in practice you'll be limited by the overall resources of the VM size and plan you've selected (e.g. 10GB Disk space on Basic, and a B1 only has 1.75GB RAM).
From the Microsoft docs, the recommendation is:
Isolate your app into a new App Service plan when:
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.
I would also add the opinion:
If applicable, keep your environments (Dev, UAT, Prod) isolated, either at App Service Plan level, or consider isolation at Resource Group or Subscription level.
Unless your apps are maxing out CPU usage, while installing as many apps per Service Plan as makes logical sense, but monitor performance and the resource usage on the VM instances as you go.
In my situation, I've typically found that RAM to be the bottleneck, so I would typically try to scale up to a VM size with more RAM to host more Apps before separating out the Apps and adding more Service Plans.
If you are on .Net Core or another stack which doesn't need Windows, I would recommend looking into the Linux Service Plans - they are considerably cheaper than Windows instances. One caveat - as at present, there's a weird limitation which doesn't allow mixing of Windows and Linux Service Plans in the same resource group.
Each App is logically fairly well isolated on the Service Plan instances, so you can add, delete, and deploy apps without interfering with the others.
Although Docker containers can be deployed as an App Service, you might find AKS a better fit.
And More Detail
The terminology around the Azure Managed App Service Plans is somewhat confusing, but to clarify:
An App Service Plan (Service Plan) can have 1 or more managed VM instances
e.g. 1 Service Plan scaled to 3 Instances = 3 VMs to pay for.
Ignoring the Free / Shared tier (on the shared tier you pay for each App), and also ignoring the Isolated tier, you'll pay a fixed monthly cost for each Instance
You can add multiple Apps to each App Service Plan - e.g. Web Apps, Function Apps, Misc. Console Apps, and Docker images. These will be deployed to all instances in the plan.
On the Standard tier and above, you can also configure Deployment Slots on your Apps, which provides the ability to smoke-test and provide continued uptime during deployments, especially in your production environment.
App Service Plans (microsoft.web/serverfarms) account for approximately 40% of our overall Monthly Azure costs
This cost can quickly multiply, especially if you are running multiple isolated environments (Dev, UAT, Prod etc) and if you need to scale out to more than one instance per environment for redundancy or scale reasons.
As at time of writing, indicative VM instance costs on US East are approximately
Dev B1 1.75GB RAM are ~$15pm Linux / ~$50pm Windows
Prod P1V2 3.5GB RAM are ~$80 Linux / ~$150pm Windows
So it's only natural to try and minimize costs by deploying multiple apps to a single VM, especially in a fine-grained Microservice enterprise or system.
I would add to this that if you have an app that is memory intensive, I would definitely isolate it to its own App Service Plan. Since usage limits are at the plan level, you don't want to get errors for mission critical apps due to a runaway app or an app experiencing higher traffic. Another good tip is to set up auto scaling with rules you define by your needs, this will prevent downtime if higher traffic than what the plan allocates is experienced.
Though yes, money can definitely be saved by grouping apps together in the same plan.
Yes, you can save cost by hosting multiple apps in one app service plan. You do not need a separate web app plan for each web app.
Generally the price you pay is for the app service plan and not the web app (Exception here is the shared plan) so your costs do not increase as you add more applications to the same plan.
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.