9

I want to deploy different VM sizes in my Azure deployments, depending on which cloud service is the target (e.g., I want bigger instances in production, but can get by with smaller ones in testing). It appears in visual studio 2010 that the sizes must be the same across all service configurations.

Is there a workaround, or is this just the way it is?

Ben Collins
  • 20,538
  • 18
  • 127
  • 187
  • possible duplicate of [Azure: Is there any way to deploy different instance sizes for test/production](http://stackoverflow.com/questions/11170755/azure-is-there-any-way-to-deploy-different-instance-sizes-for-test-production) – Dunc Mar 18 '15 at 16:07

3 Answers3

2

The best workaround I've found is to have two different cloud projects. So basically you just create two different cloud projects, add all the same roles into each of them, but have different configurations in each. You just have to be careful to update all the configurations in both places every time you change it. This amounts to having two CSDEFs, as Brent the Programming Simian mentioned already, this is just a concrete way to achieve that.

This also gives you flexibility in other ways. For example, you can have a test site with both HTTP and HTTPS endpoints, but the production site can have only HTTPS.

Brian Reischl
  • 7,216
  • 2
  • 35
  • 46
  • After considering, I think this is the best of the non-ideal options. I like @Igorek's approach in some ways, but ultimately, I think it would be easier to maintain multiple cloud projects than to maintain automated configuration transforms and carry it through deployments and environments. – Ben Collins Aug 23 '12 at 01:16
0

The VM size is declared in the service definition file. So creating cloud service packages with different sizes require different packages. Ultimately this isn't something that visual studio supports well.

Outside of this, if you're creating a cloud service (PaaS), I'd question why this needs to be done. The best guidance I've recieved is run the smallest VM you need and run as many of them as your load dictates. By having more, smaller instances, your solution ultimately has greater resiliency.

BrentDaCodeMonkey
  • 5,493
  • 20
  • 18
  • 3
    This is not necessarily good advice in the general case (running more, smaller instances rather than fewer bigger ones). There are trade-offs to consider either way, and knowing how to navigate them is inherently dependent on the particulars of the situation. Also, resilience is not a function of how many instances are running (it might be for a given situation that the two have an inverse relationship). – Ben Collins Aug 17 '12 at 18:57
  • I disagree Ben. the more instances, the less capacity you lose when an instance failure occurs (note I said "when", not "if"). As for resilience, multiple instances is one way of creating redundancy which contributes to overall resilience. But true resilience also requires the solution to be able to handle the the failures and shift/resume workloads that were being handled by failed instances with minimal impact on any clients the solution was servicing. Without that reduncancy, any outtages create a greater service disruption and thus drag down the appearance of resilience. – BrentDaCodeMonkey Aug 22 '12 at 22:46
  • 1
    Simply adding more instances only helps with resilience under 2 scenarios: the MTTF is short enough that adding an instance improves the probability of avoiding total failure in a statistically significant way, and if increased concurrency doesn't cause problems (and, like you say, if your software is written to respond to failures correctly). There is a threshold at which adding instances cannot help your resiliency in any appreciable way. Ergo, my point still stands: the claim is simply not true in the general case. – Ben Collins Aug 23 '12 at 01:14
0

I commented further up, but thought I would provide my solution with powershell. I'm running this prior to building on my CI server, which happens to be TeamCity, but this could be run locally or on CI.

Param(
    [string]$RoleType,  #WebRole or WorkerRole
    [string]$RoleName,  #RoleName from CSDEF
    [string]$VMInstanceSizeIn,  #Options for VM Size: Small, Medium, Large, ExtraLarge, A6, A7
    [string]$csDefPath  #File path for ServiceDefinition.csdef for the cloud service project
)

$timeStampFormat = "g"
if ($VMInstanceSizeIn -eq $null) {$VMInstanceSizeIn = "Medium"}

Write-Output "$(Get-Date -f $timeStampFormat) - Setting $RoleType role type with RoleName $RoleName VM Size to $VMInstanceSizeIn in ServiceDefinition.csdef prior to building the package file."

Try 
{
    $csDefConfig = "$csDefPath\ServiceDefinition.csdef"
    Write-Output "$(Get-Date -f $timeStampFormat) - config file location: $csDefConfig"
    $csDefConfigXml = [xml](Get-Content $csDefConfig)
    Write-Output "$(Get-Date -f $timeStampFormat) - Found ServiceDefinition File at $csDefConfig"
    $csDefCurrentXmlNode = $csDefConfigXml.ServiceDefinition.$RoleType | where {$_.Name -eq $RoleName}
    $csDefCurrentXmlNode.SetAttribute("vmsize", $VMInstanceSizeIn)
    $csDefConfigXml.Save($csDefConfig)
    Write-Output "$(Get-Date -f $timeStampFormat) - Successfully saved the ServiceDefinition.csdef file to $csDefConfig"
}

Catch
{
    Write-Output "$(Get-Date -f $timeStampFormat) - Powershell Script Error. An error occurred while attempting to modify the ServiceDefinition.csdef file prior to building the solution."  
    Write-Error -ErrorRecord $_
    ##teamcity[buildStatus status='FAILURE' ]
    exit(1)
}

Please note that at the time this was written I only had to deal with a single web and worker role, so I'm not sure if this was ever tested with multiple worker roles. It should at least be enough to get you started.

Ryan
  • 121
  • 1
  • 6