Allow a Role instance count of 0
In many scenarios it is useful to have a role that is only run for certain periods of the day. At present this is very complex to achieve as it involved using the management API to deploy and undeploy a whole service (from Blob storage). it would be much more elegant if the role count could be set to Zero thus undeploying all instances of just that role. In this way other services in the project could use the management API to start and stop just that Role.
To reduce costs of worker roles, I suggest that you update management api to support instance-count of zero so that idle role instances can be eliminated.
I'm talking about worker roles that primarily executes work at specific hours, and lay idle the rest of the day.
Furthermore this ought to also be implemented in the Auto Scaling section.
For Cloud Services/Worker Roles, if the AutoScale's Instance Range could start at 0 instead of 1, then you could effectively create an on-demand back-end service that would only launch/scale-up as jobs become available (in the form of queued messages), and then scale-down to zero once all work is processed. This would be great for batch processes that run only once a day, for example.
Billing has now been stopped for IaaS offerings when the VM is stopped, why not Cloud Services? Cloud Services run on VM instances too, and it should take even less resources to manage a stopped Cloud Service since you should just need the deployment package to rebuild the VM instance instead of needing an entire VHD.
We are likely to support this in phases. Stay tuned for more details.
Please provide an update. This is an important feature and I now see that Azure competitors are providing functionality to facilitate - e.g. AWS Lambda
Leon Meijer commented
Please provide an update. For development purposes, 0 role instances (or via Azure Automation) would be appreciated
Alan M commented
Please provide an update on support for this.
What surprises me is that we can deprovision a VM, but not a Worker Role or a Web Role. Currently this is only possible if we remove the deployment, which is quite cumbersome.
"Post Fall 2012" is quite a broad timeframe. Can you please provide one that is more accurate?
Is there any update on this feature? Now that cloud services can have reserved IPs providing this feature for Cloud Services only with reserved IPs would be okay with me.
Jeroen Landheer commented
Today they have released pricing changes on Azure, but unlike virtual machines, it does not look like charges stop if cloud services or role instances are stopped. (The portal still tells you that you continue to incur charges until a deployment is deleted.) If this changes there might be a work around or even a solution to this.
Thomas (Mentum) commented
I'd second that. Rule #1 when setting status on an idea. Don't tell dates if it's not planned.
BTW: the suggestion with removing instances from the load balancer totally mis the point: keep configuration while not paying. I' m not sure when it would make sense to have a hot standby, that is not doing anything, if you still pay for it.
Fall 2012... Sometimes I wonder if they even give a fuck about what we write here
Whatever happened to this? 2012 came and went ...
Interesting comment Calvin, however if we remove it from the load balancer we still get charged for having the role sitting there doing nothing.
Bryn Keller commented
Great idea! Would really help in multiple scenarios. Why make people delete configuration data to release resources? Keep the configs, release the resources. Makes it easy to bring it back when you need it.
Alexander Gran commented
We also have an application that scales by growing a tree of instances. Having the ability to swtich an role off would mean we can enable/disable levels of the tree just by configuration, without redeployment. That would be so extremly easy.
Doesn't look any hard to do, actually.
Chris Auld commented
Hi Calvin. Thanks heaps for the update. The load-balancer based workaround doesn't really solve the problem because a key goal of this is cost management; we'd still be paying for the Hot standby. The goal is to shut it down and undeploy so as to not be billed for it.
Anton Staykov commented
Totally agree with Chris! I do have a live customer, where I am doing exactly like this - deploy for the time of processing. Then delete. Then deploy again ...
Please o please. We have multiple scenarios where we do not want any instances available in various environment (e.g. testing web service should not go to production)
Spiir udviklingsteam commented
Damn... this is a great idea. I see allot of great opportunities with this feature.
Eg. we could have a deployment with the job with our monthly, weekly, once a day job.
Also this could solve the problem with stopped roles that still are billed. So when you click "stop" you get an option to select instance count of 0 (knowing that this will result in a new DeploymentId, IP and so on).
Matthew Davey commented
Extremely important feature - our real world Azure experience for our Event Ticketing solution would benefit massively from this, especially for batch processes.
Michiel van Otegem commented
This IMHO is an extremely important feature. There are companies that really only use their apps during office hours, and would like to shut it down outside those hours. An even better example is batch processes that run only once a day. I've worked on an app like that for a bank, and that only needed to run when the stock exchange was open. If you really want to make Azure interesting for these kinds of customers, make it possible to set a schedule during which instances are operational.
Having just learnt that you get billed for the Staging slot just like any other, I would like it ot be easier to remove a staging build once it has gone live, or to perhaps archive it (in you Storage account?) so that you can roll back to this build even if you have deleted and suspended it.