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.
Related
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.
Recently, i have been introduced to Azure and i have an application that is using high CPU (almost 80%) during morning hours between 9 am to 1 pm. After that the CPU utilization is reduced to a minimal of 10% the whole day. So in order to reduce my cost i was thinking to implement vertical auto-scaling in my application. When i read more on this i could find automation account and RunBook as the only way but my need is that is there any other way to implement Vertical auto-scaling in Azure IaaS VM apart from automation account?
If Yes, please share the approach.
Yes you can use Azure PowerShell and/or the Azure CLI to execute scaling commands on a VM. Here are some PowerShell examples: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/resize-vm?toc=%2Fazure%2Fvirtual-machines%2Fwindows%2Ftoc.json
You would then just have to schedule the script to run either locally or in an Azure service like Functions, Container Instances or etc.
If you wanted to scale vertically a single VM based on a performance metric (CPU, memory, etc.) you can use the classic metric alerts system to do that. When those alerts fire based on thresholds you set you can invoke a webhook OR Logic App to trigger execution of a script or ARM Template.
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.
We currently have a window service which send some notification emails to users after doing some processing on database(SQL database). Runs once in day.
We want to move this on azure cloud. One alternate is to put it on Azure VM as is. but I am finding some other best possible solution for that.
I study about recurring and on demand Web jobs but I am not sure is this is best solution.
Also is there any possibility to update configuration of service code in App.config without re-deploy the code of service on cloud. I means we can manage configuration from Azure portal.
Thanks in advance.
Update 11/4/2016
Since this was written, there are 2 additional features available in Azure that are both excellent choices depending on what functionality you need:
Azure Functions (which was based on the WebJobs described below): Serverless code that can be trigger/invoked in various ways, and has scaling support.
Azure Service Fabric: Microservice platform, with support for actor model, stateful and stateless services.
You've got 3 basic options:
Windows service running on VM
WebJob
Cloud service
There's a lot of information out there on the tradeoffs between these choices, but here's a brief summary.
VM - Advantages: you can move your service basically as it is without having to change much or any of your code. They also have the easiest connectivity with other resources in Azure (blob storage, virtual networks, etc). The disadvantage is you're giving up all the of PaaS advantages and are still stuck managing your own VM infrastructure
WebJob - Advantages: Multiple invocation options (queues, blobs, manually, queue receive loops, continuous while-loop style, etc), scheduled (would cover your case). Easy to deploy (can go with website, as a console app, automatically through Kudu), has some built in logging in Azure portal - and yes, to answer your question, you can alter the configuration in the portal itself for connection strings and app settings.
Disadvantages - you'll need to update code, you don't have access to underlying resources (if you need that), and more of something to keep in mind than a disadvantage - it uses the same resources as the webapp it's deployed with.
Web Jobs are the newest of the options, but at the same time appear to have active development going on to increase the functionality and usefulness.
Cloud Service - like a managed VM, has some deployment options, access to underlying VM if needed. Would require some code changes from your existing service.
There's nothing you've mentioned in your use case that makes me think a Web Job shouldn't be first thing you try.
(Edit: Troy Hunt has a great and relatively recent blog post illustrating most of the points I've mentioned about Web Jobs above: http://www.troyhunt.com/2015/01/azure-webjobs-are-awesome-and-you.html)
I've got my head around creating cloud instances in AWS, Azure and Rackspace. However, I need to turn my instances off at the end of the day and on in the morning as this will half my hosting cost (they are for development).
I've looked at a few management services but they blew my brains out. Is there a simple way to do this?
Azure
REST:
You can do this to Azure deployments by using the Windows Azure Service Management REST API. Because it is REST you can use most programming languages to access it.
You could have an application running on your local machine that schedules calls to these services to delete at a certain time at the end of office hours and then create your service again in the morning.
PowerShell:
Or you can manage your deployments in the same way but instead of using REST you can use Azure PowerShell cmdlets. I have done this way myself and it works nicely.
To help you get started there is a nice tutorial on how to do use PowerShell to deploy Azure applications.
also if you didn't already know I should also mention there is a 3month free trial with Azure if you are simply looking for cutting costs whilst developing.
Approach
You could always roll your own solution, insofar most cloud providers offer a respective API to start/stop instances on demand (or even on schedule), which is what those management services are actually using as well of course - the AmazonEC2 Java interface offers all relevant methods for example (amongst many others), specifically:
StartInstances()
StopInstances()
RebootInstances()
Via Scripting (EC2)
The most simple approach for this regarding Amazon EC2 would be to craft yourself some Python scripts by means of the excellent boto (An integrated interface to current and future infrastructural services offered by Amazon Web Services), which exposes all EC2 methods mentioned above; you could then start those scripts on demand or via your operating system scheduler.
Via Continuous Integration / Automation (EC2)
Another option would be to facilitate a continuous integration server as an automation engine (a sometimes overlooked aspect of these systems), in case you happen to run one anyway; it would allow you to both start/stop instances on demand or scheduled similar to cron.
We do exactly this by means of the Bamboo AWS Plugin (it's Open Source and the code is available on Bitbucket), see my answer to How to start and stop an Amazon EC2 instance programmatically in java for more details on this approach. While Atlassian Bamboo is a commercial offering, there should be something similar available for popular Open Source CI solutions like e.g. Jenkins as well.
NOTE: As for June of 2013, IaaS Instances can be placed in a "stopped (deallocated)" state. In this state you are only billed for storage of any disks associated with the VM. The original answer below describes a VM instance that is in a "stopped" but not deallocated state. The deallocated state is currently the default for VM stop actions taken via the Azure management portal.
The only way to accomplish this in Widows Azure today is to delete the deployment.
If you stop the service, you are still billed (like renting office space, you pay for it even if you aren't in it), and you can't set the instance count to zero. An option may use is to just reduce the instance count to absolute minimum (1) an then scale it back up during needed hours. But the cost benefits of this will depend on the size of your instances.
Old thread I know, but Microsoft introduced 'Runbooks' for Azure in 2014 that you can use for automation, including scheduled startups and shutdowns. As mentioned above, be sure you are in stopped (deallocated) state, as opposed to just stopped, in order to prevent charges.
More info:
Script to stop your VMs
Azure automation, official MS docs.
Yes Automation Runbook are there by which we can schedule the job. I created the script for stopping (De-allocated) Azure VM.
https://gallery.technet.microsoft.com/Deallocate-all-VM-under-79049c69
Please read about how to use runbook http://azure.microsoft.com/blog/2014/06/19/azure-automation-runbook-management/
Dellocation and stop are different, since stop vm will also incur cost.
The best article on automation + switching on/off VMs I have found so far. [05 February 2015]. http://clemmblog.azurewebsites.net/using-azure-automation-start-und-stop-virtual-machines-schedule/
Recommended solution for AWS:
The AWS Data Pipeline is uniquely suited to this task. Data Pipeline
uses AWS technologies and can be configured to run AWS CLI commands on
a set schedule with no external dependencies. Data Pipeline can write
logs to S3 and runs in the context of an IAM role, which eliminates
key management requirements. Data Pipeline is also cost effective; for
example, the Data Pipeline free tier can be used to stop and start
instances once per day.
https://aws.amazon.com/premiumsupport/knowledge-center/stop-start-ec2-instances/
Refer to this article, there some options to turn your instances on/off inside AWS.
AWS Datapipeline
AWS Lambda scheduled events
Scheduled Cron on EC2 instance
Scheduled Scaling of Auto Scaling Group
So in your case I'd recommend the followings:
For AWS:
Through Shell Command like AWS CLI commands: See Turn on/off
Cloud instances using AWS Pipeline. this method will initiate a
separate EC2 instance to be started and terminated for each AWS API
call that running times affect to your Bill.
Through programming languages like Node.js / Python: See Turn
on/off Cloud instances using AWS Lambda. The task running twice a
day for typically less than 3 seconds with memory consumption up to
128MB typically costs less than $0.0004 USD/month
For Azure and Rackspace (or other platforms you may have):
Use the above tools to provide a Respective API to start/stop instances on demand.
You may also consider to set scripts-per-boot which runs each time your instance is started.
AWS
AWS SDK is your best bet but I am using TotalCloud.io to start and stop instances under the free tier. Very customizable.
Easy to setup.