Very similar to (but not a duplicate of!) this question: Limit number of instances of an azure webjob when scaling out
I would like to be able to limit the number of instances of a webjob within our standard webapp. I am aware of the possibility of having a singleton instance but would like to be able to limit this to a number other than 1.
Is such a thing possible? If not, are there any sensbile workarounds for the type of scenario described in q. 45067648 for those of us running on the Standard App Service?
Footnote on why this isn't a duplicate of q. 45067648:
I asked the previous question without considering that there could be a different answer depending on whether the app service was running on a premium or standard SKU. The answer Amor gave would be an ideal answer for those running on the premium SKU but is unsuitable for those running the standard SKU. I considered amending the original question but, after advice on meta (here and here), discovered this is best posed as a new question
limit the number of instances of a webjob within our standard webapp.
Under "Create a continuously running WebJob" section in the article, you can see: "If your web app runs on more than one instance, a continuously running WebJob will run on all of your instances". And it enables us to make continuous WebJob to run on only one instance.
To limit the number of instances that continuous WebJob run on, Amor has gave you a workaround in this thread: using Per app scaling feature (available only for Premium SKU App Service plans). If you do not want to scale your Standard SKU App Service plan to Premium SKU App Service plan, you can create another new Standard SKU App Service plan with specific number of instance that you want to run your WebJob, in this way, your WebJob will not cause resource contention with other web apps.
Besides, you can give a feedback on Azure UserVoice.
Related
As I understand there is no concept of update domain in App Services (and in other PaaS offerings). I am wondering how Azure is handling OS updates if I have only a single instance of an App Service app. Do I need to plan for two and more instances if I want to avoid such cases when an app goes down during the OS/other updates or this is handled without downtime? According to docs App Service has 99.95% SLA - is this time reserved here?
First of all, welcome to the community.
Your application will not become unavailable when App Services is patching the OS, you don't have to worry about that. Imagine if that would be the case, it would be a huge problem. Instead, the PaaS service will make sure your application is replicated to an updated worker node before that happens.
But you should have multiple instances, as a best practice listed in this article:
To avoid a single point-of-failure, run your app with at least 2-3 instances.
Running more than one instance ensures that your application is available when App Service moves or upgrades the underlying VM instances
Have a look at this detailed blog post:
https://azure.github.io/AppService/2018/01/18/Demystifying-the-magic-behind-App-Service-OS-updates.html
When the update reaches a specific region, we update available instances without apps on them, then move the apps to the updated instances, then update the offloaded instances.
The SLA is the same regardless the number of instances, even if you select "1 instance":
We guarantee that Apps running in a customer subscription will be available 99.95% of the time
Have a look at Hyper-V and VMWare, it will give you a rough idea on how App Services handle that.
If you're looking for zero-downtime deployments with App Services, what you are looking for are deployment slots.
Managing versions can be confusing, take a look at this issue I opened, it gives you a detailed how-to approach about managing different slot versions, which is not clearly described by Microsoft docs.
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 web app hosted in app service in Azure with auto scale out rules defined and it works as expected - when the memory usage reaches the threshold. An VM instance is added automatically
The problem is that, we discovered that when a new VM instance is added, a new instance of our web app is also added - we do not want this, as our web app is not designed to be horizontally scaled out. We only want one instance of the app.
On Azure portal when I click on Scale up (App service plan), I can only choose another app service plan, it seems to me there is no way I can do something like when a threshold is reached, automatically scale up to the next level of app service plan but keep the number of VM instance.
I am wondering why there is no such option available in Azure?
Or even our conclusion that when scale out, the number of web app instance also increases is true?
You're right, there's no automatic way to scale up and when you scale out, the number of web app instance also increases.
Yes, there is no out of the box option for this and that could be because there is a chance to have latency issues during the scale up / down operation and Azure might want the consumer to make this decision consciously. Having said that, I use the below approach to achieve the vertical scaling you are looking for.
Step 1: Create an Automation account
Step 2: Create a PowerShell Runbook in the automation account you created in previous step. This script would scale up your app service
plan
Step 3: Create an alert rule using the Azure Monitor for your criteria. say, alert
to be fired when Memory usage % is more that 40% or CPU utilization more than 5%)
Step 4: Create an action group that will invoke a runbook you created in
Step #2
Step 5: Associate this action group to the alert you have created in Step #3.
This will do what you are looking for. when the memory utilization is over 40% the alert is triggered which in turn will call you runbook to scale up your app service plan.
You can refer to my article here for detailed description of how to create an automation account and also for the PowerShell script to scale up an app service plan
I thought one of the advantages of Azure was that I could turn services on and off depending on when I want them to be available.
However I cant see how to pause my App Service Plan.
Is it possible?
I want to use the S1 tier so that I can play with what it offers. However I want to be able to pause the cost accumulation when I am not using it.
I see from the app service pricing help that an app will still be billed for even though it is in the stopped state.
Yet the link also clearly states that I only pay for what I use. So how does that work?
If you put your hosting plan onto the free tier, you will stop being charged for it. However if you have things like deployment slots and certificates these will be deleted.
The ability to turn services on and off, is more to do with being able to scale services, so if you need 50 servers for an hour you can easily do that.
What you can do to make your solution temporary is to create a deployment script, using Powershell or Resource manager Templates then you can deploy your solution for exactly as long as you need it and then delete it again when you don't. In this sense you can turn your services on and off at a whim.
Azure provides building blocks for you to create the solution you need, it is up to you to figure out how to best use those building blocks to create the solution you seek.
Edited to answer extended question.
If you want to use the S1 pricing plan, and not have it charge when you are not using it, the only way of achieving that is by using automation. Fortunately, this is reasonably trivial to achieve.
If you look at this template it is pretty much all configured to deploy a website from Github to Azure on demand. If you edit that to configure it to your needs you can have a new Azure website online with 2 minutes of running the script.
Then you would have another script that deleted it once you had finished.
Doing it this way you would loose no functionality, and probably learn quite a bit about what is possible with Azure along the way.
App Service Plan
An app service plan is the hardware that a web app runs on. In the free and shared tier your web apps share an instance with other web apps. In the other tiers you have a dedicated virtual machine. It is this virtual machine that you pay for. In that case it is irrelevant whether or not you have web apps running on your app service or not, you still have a virtual machine running and you will be charged for that.
To change the App Service Plan via PowerShell, you can run the following command
Set-AzureRmAppServicePlan -ResourceGroupName $rg -Name $AppServicePlan -Tier Free
I was able to accomplish this using the dashboard by selecting the App Service Plan, clicking Scale up (App Service Plan), and then from there if you click Dev/Test you can select the Free tier.
As others have mentioned, you need to script this. Fortunately, I created a repository with one-click deployment to your Azure resources.
https://github.com/jraps20/jrap-AzureVerticalScaling
The steps are intended to be as simple and generic as possible:
Execute the one-click deployment from the repo readme
Select the subscription, resource group etc.
Deploy resource to Azure
Set up your schedule to scale up and scale down as-needed
The scripting relies on runbooks and variables to maintain the previous state of each App Service Plan and App Services within those plans. Some App Services cannot be scaled due to specific settings being used (AlwaysOn, Use32BitWOrkerProcess, ClientCertEnabled, etc.). In those cases, the previous values are stored as variables prior to down scaling and then the original values are reapplied when the services are scaled up.
For more clarity, I have written a blog post that goes into detail. The post is pertaining to Sitecore, but applies to any App Service setup- Drastically Reduce Azure PaaS Hosting Costs in Non-Prod Environments With Scheduled Vertical Scaling. It also includes a brief video tutorial to show its use case.
Myself and others have been using this repository/approach for well over a year and it works great. I mostly use it for POC's to reduce costs when I'm not actively working on something. However, its main intention was for targeting non-prod environments to save costs during non-work hours.
Azure App Service Plan is just an logical concept of a set of features and capacity that you can share across multiple apps. I don`t think you can "pause" a plan, instead you can pause your service. and depends on billing model of each service, you might or might not get charged.
Pausing = Delete or lower tier.
Scripting is the key.
Design Diagram
Use scripts to create (also consider shared resources)
Delete using scripts
Use scripts to recreate.
eg: If we use resource group properly per environment then
Export-AzureRmResourceGroup will create a template for us (everything in the resource group will be pulled out as script). So we can delete it and recreate it anytime.
To pause a VM and stop billing you need to shut is down and deallocate it. Just shutting down still has the capacity reserved as if its running.
Storage can't be shutdown - it can be moved to lower cost tiers.
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.