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
6 years now...
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?
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.
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?
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.
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 Veldhuizen commented
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.