I find Azure Container Instances (ACI) very confusing. In Azure Container Apps, if there are no requests, the service scales down to zero and stops billing. However, does ACI also have such a feature?
For example, if I deploy a container that is called once a month, and each call takes 5 seconds to complete, will I be charged for the 5 seconds or for every second in the month for which it was deployed/available?
How can I stop/pause ACI to only bill for the 5 seconds used?
I know that is not a strictly programming question, so I appreciate that this may not be the best forum to ask, but I am unsure where else to post this.
Thank you in advance!
You can use Azure Automation or logic app to stop/start containers in ACI but that's extra work on your part to implement that. In your scenario if you want to only pay for what you use and then the best options are
Azure Function (Basic App Service plan required, so there will be a minimum charge and won't quite scale to zero)
Azure Container Apps (scale rule to 0 when no traffic)
Your best bet (apart from going to the full-blown AKS, for which you still need to pay for the minimum 1 node required) here is to run this workload in Azure Container Apps and scale to 0 when there is no traffic and pay for only when you have traffic.
Currently Azure Container Apps supports HTTP, but TCP is coming very soon https://github.com/microsoft/azure-container-apps/issues/375
I realized that ACI is not the solution that should be used for such a workload. ACI is meant to run tasks like compiling apps, not for servers that wait for a client to request something.
Related
I was wondering what would be the minimal recommended instance count for azure app service web app in production scenario ?
We currently have app services under Isolated app service plan with Autoscale rule in place (scaling up to 10 instances).
However the minimal instance count is currently set to 1.
I was wondering if this number shouldn't be higher (at least 2)? Can this impact SLA and apps availability somehow ?
If availability is a concern you should use 2 or 3 instance to minimize impact. Having just one instance can cause downtime. If you have a web app running on 1 instance the Azure Portal warns you with the following advice:
Distributing your web app across multiple instances
The webapp is currently configured to run on only one instance.
Since you have only one instance you can expect downtime because when the App Service platform is upgraded, the instance on which your web app is running will be upgraded. Therefore, your web app process will be restarted and will experience downtime.
Having 2 instances mitigates this, but can still cause downtime if one instance is not available due to a platform upgrade and one instance is not available due to a new deployment. 3 is best since in that regards.
Do note that if high availability is a must, then you need to also think multi-region. Think worst case scenario such as a natural disaster taking the one data center offline that you are using. It would be best to have something like Azure Traffic Manager (ATM) in front of two web apps (each with 3+ instances) and if ATM detects one of your web app regions is offline, it can reroute traffic to minimize downtime. Customer's who are running storefronts and the availability of their app is tied directly to their app being online will often take this approach.
(source)
I have a .NET Core application currently running as an Azure App Service, and I need it to do a lot of 'work' only about a few times a day. In order to save on the hourly billing, this is the solution I developed:
Using a runbook (Azure Automation): scale the App Service Plan to the 'Free' tier at 7:00 PM
Using a runbook (Azure Automation): scale the App Service Plan back up to the premium tier at 8:00 AM
Hard-code my .NET Core application to ensure it only does the heavy 'work' between 8:00 AM and 7:00 PM
This is fine as it saves me a significant portion of cost, as I'm only paying for the hours in which the App Service Plan is scaled up to the premium tier. However it is definitely not ideal.
My question is - what design pattern should I implement in order to accomplish what I'm trying to do? I need a lot of compute resources but only for a few hours out of the day. I know AWS has 'spot' instances that you can configure - is there a similar mechanism in Azure?
Ideally I could implement a solution that involves me only paying for those heavy compute resources when I actually need it (e.g.: a few times a day, while the sun is up)
Thank you for any insight and help!
EDIT in regards to the type of computation, my summary is essentially a few ML.NET trainers running in parallel with some moderate Elasticsearch document writing
It is pretty tough to answer this with the whole description of your workload being a "lot" of "heavy compute".
If you can put your "compute" into Azure Functions, going serverless with a consumption plan will probably be the nicest solution. However, individual function executions have a given timeout, so you need to see if your app fits the bill.
As an alternative, you can put your application into an Azure Container Instance, and spin that up on demand.
If you have REALLY high workload, you can use Azure Batch. If your current workload can be done on an AppService plan, this may be "overkill".
The equivalent to AWS spot instances is called Azure Spot Virtual Machines. You can also use them with Azure Batch.
Yes, you can switch to Serverless. Host front end on Storage Accounts and back end move to Azure Functions (Consumption Plan).
PS: If it's a long running processing, it may not be the best solution unless you use Durable Functions.
This is a question on general advice on the usage of ACI and its pricing calculation.
I checked the MSFT link: ACI pricing
It stated that it is charged based on memory and CPU consumptions. And the calculations for my scenario is not available in the MSFT pricing calculator.
Some background studies that i did, tf I stopped/de-allocated my ACI, I should no longer be charged, but I read that a lot of tutorials actually guided us to create/delete a NEW ACI, and the start/stop functions only exist in Azure CLI.
Logic-app ACI custom connector does not have start/stop functions
Azure PowerShell does not have start/stop functions.
Questions:
If so, what is the difference between Stopping and Deleting ACI in terms of pricing and performance?
For example:
I can use Azure automation run book to call Azure CLI to stop/start my ACI.
I can use Logic app - ACI custom connector to delete/create a new ACI.
Wouldn't it be faster to just stop the ACI and start again, to avoid the bandwidth cost to pull the image from Docker hub (or keeping an image in Azure container registry)? And it will be faster rather than provisioning a new instance each time.
Why the stop/start functions are not available in the Azure PowerShell module, and logic app custom connector? Seems it sounds like a better an approach to handle them.
From here, I would say there is no difference. Also stopped instances should incur no cost.
When the containers are recycled, the resources are deallocated and
billing stops for the container group.
This, however, also means that restarting a stopped instance will not really be faster than creating from scratch. Starting might happen on a new host, so pulling the image will need to happen again as well.
Context: I am designing the auto-scaling (scale out) configuration for my .NET Framework 4.7 web app hosted on a Microsoft Azure App Service. I am using the P3V2 pricing tier. The application is CPU-bound. The app's 30 day CPU average is 30% usage while running on 2 instances, according to the stats indicated in the App Service plan. We occasionally have traffic spikes which will overwhelm the 2 instances: I want to implement auto-scaling.
I want to take into account the App Service Provisioning + App Startup Time when designing the metrics thresholds that decide when my app service scales out. I need to make my thresholds low enough to give Azure time to spin up a new app service instance but not so low that I am paying unnecessarily for processing power that's not needed. Budget is a significant factor.
Question: How long does it take for an Azure App Service instance to be available after a scale out? In other words, how long does it take for an Azure App Service to scale out?
P.S. I recognize that there is a lot more to scaling in/out that I am not addressing here. I'm trying my best to be succinct. :)
Generally, not long at all. By that I mean typically under one minute, but the time will vary depending on several factors, such as application size, time of day, region of deployment.
You could scale out manually and inspect the run history logs on the scale out tab.
FYI you can also use Azure Monitor to create auto-scale policies, in case this is of any use to you.
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.