How can we improve Azure Cloud Services (Web and Worker Role)?

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.

723 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Chris AuldChris Auld shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Anders MadsenAnders Madsen shared a merged idea: Support worker roles with zero instances  ·   · 
    Chris WiederspanChris Wiederspan shared a merged idea: Allow the lower-end of the AutoScale's Instance Range to start at 0 instead of 1.  ·   · 
    bojingobojingo shared a merged idea: Stop billing for stopped Cloud Services  ·   · 
    btmibtmi shared a merged idea: Make it easier to remove or disable or keep a staging build after it has moved into production  ·   · 


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      • LeroyLeroy commented  ·   ·  Flag as inappropriate

        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?

      • Anonymous commented  ·   ·  Flag as inappropriate

        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 LandheerJeroen Landheer commented  ·   ·  Flag as inappropriate

        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)Thomas (Mentum) commented  ·   ·  Flag as inappropriate

        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.

      • ryancrawcourryancrawcour commented  ·   ·  Flag as inappropriate

        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 KellerBryn Keller commented  ·   ·  Flag as inappropriate

        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 GranAlexander Gran commented  ·   ·  Flag as inappropriate

        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 AuldChris Auld commented  ·   ·  Flag as inappropriate

        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 StaykovAnton Staykov commented  ·   ·  Flag as inappropriate

        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 ...

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        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 udviklingsteamSpiir udviklingsteam commented  ·   ·  Flag as inappropriate

        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 DaveyMatthew Davey commented  ·   ·  Flag as inappropriate

        Extremely important feature - our real world Azure experience for our Event Ticketing solution would benefit massively from this, especially for batch processes.

      • Michiel van OtegemMichiel van Otegem commented  ·   ·  Flag as inappropriate

        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.

      • btmibtmi commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base