Allow a Role instnace 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.
This is on roadmap but ETA isn’t until post Fall 2012. More votes for this feature might help move it up though timing depends on some other factors as well. Mark Berman on the planning team suggested a workaround that involved removing the instance from the front-end load-balancer i.e. so that it doesn’t respond to any requests? RDFE has an API that allows you to stop sending requests to an instance. The idea being that you can have n number of instances in hot standby waiting. This is of course a workaround, but it might address some of the short term need while we wait on the feature.
12 comments
-
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.
-
Christopher commented
Fall 2012... Sometimes I wonder if they even give a fuck about what we write here
-
XinTW
commented
Whatever happened to this? 2012 came and went ...
-
ryancrawcour
commented
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 ...
-
Anonymous
commented
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.