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

Allow the instance size to be changed without redeploying

allow changing instance size of web role (extra small, small, ...) through the management portal without having to redeploy the application

354 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    ThomasThomas shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Alexander VovkAlexander Vovk shared a merged idea: Allow to change vmsize without repackaging  ·   · 
    Thomas (Mentum)Thomas (Mentum) shared a merged idea: Scale up (size) and not only out  ·   · 

    6 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        Totally agree with this - if I could spend all my votes on this single change it would be on this one. Rather worrying that the last response from MSFT was in 2013 though. What is the current status on this?

      • JonGJonG commented  ·   ·  Flag as inappropriate

        In any proper SDLC, the Development, QA, PerformanceLab and Prod subscriptions would properly NOT have the same instance size (small in Dev, small or Medium in QA, and larger in Perf and Prod); if for no other reason than pre-production cost savings (not a trivial thing with many teams, projects, etc). The fact that changing the instance size for Cloud Services can only currently be accomplished by unpacking and repacking the CSPack file at deploy time is, for lack of a better term, functional broken. In addition to requiring custom pre-deployment scripts and utilities to accomplish this modification, it also means the package being deployed to different environments will actually be different (dissimilar MD5 hashes for deployed packages within the same SDLC); which, regardless of the subtleness of the change, this is unacceptable in many companies.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        I don't understand why this option isn't available in the .cscfg file for the role configuration - surely it should be as customisable as the instance count??

        Is it really the case that there is no way for our customers, who will be hosting our service within their subscription(s), to change the instance type in any other way than have to manually unpack & repack the cspkg file in order to make the required changes to the csdef file?

      • MaxMax commented  ·   ·  Flag as inappropriate

        So this has been "under review" for almost a year now. Any progress?

        I agree will all points so far.
        I have to deploy the same cspkg with many different databases, etc. which works fine via the ServiceConfiguration files, but once I want a deployment in a different size I need to repackage everything!? That is a pretty strange decision.

      • RoryRory commented  ·   ·  Flag as inappropriate

        Totally agree with Jan van Veldhuizen: sizing should be an ops decision.

        We use a cspkg file output from our automated build for deployments; it doesn't make sense to need to change our build process to output multiple files if we want to have different sizes for dev/test/demo/prod or for different customer deployments.

      • Jan van VeldhuizenJan van Veldhuizen commented  ·   ·  Flag as inappropriate

        It doesn't make sense that the developer determines the size when in reality it shouldn't matter to him. The system administrator in charge of deployment should be able to have packages from the developers and then we manage the scaling. It's strange that I can scale up and down the number of instances, but not the size, especially since the size determines not only the physical resources but the bandwidth as well.
        I would be great to be able to define the vmsize in the ServiceConfiguration files instead of the ServiceDefinition file. That would make it possible to have different sizes for each configuration, eg. XS for development, M for demo and XL for live.

      Feedback and Knowledge Base