Based on your feedback, today we are making some helpful updates to Windows Azure that provide developers flexibility for making in-place updates to deployed services. Best of all, these updates are easily made without changing the public IP of the service.

Windows Azure now supports a wider range of changes to a deployed service without requiring the use of a VIP swap or a complete delete and re-deploy of the service. With the following changes permitted through an in-place update, you will now be allowed to make almost all possible updates without requiring a VIP swap or a re-deploy!

The newly allowed in-place updates are:

  • Change the virtual machine size (scale-up or scale-down)
  • Increase local storage
  • Add or remove roles to a deployment
  • Change the number or type of endpoints

Summary of changes allowed

Changes permitted to hosting, services, and roles

In-place update

Staged (VIP swap)

Delete and

re-deploy

Operating system version

Yes

Yes

Yes

.NET trust level

Yes

Yes

Yes

Virtual machine size

Yes

Warning

Changing virtual machine size will destroy local data. When making this change using the service management APIs, the force flag is required

Note

Requires Windows Azure SDK 1.5 or later

Yes

Yes

Local storage settings

Yes

Increase only.

Note

Requires Windows Azure SDK 1.5 or later

Yes

Yes

Add or remove roles in a service

Yes

Yes

Yes

Number of instances of a particular role

Yes

Yes

Yes

Number or type of endpoints for a service

Yes

Note

Requires Windows Azure SDK 1.5 or later.

 

Note

Availability may be temporarily lost as endpoints are updated

No

Yes

Names and values of configuration settings

Yes

Yes

Yes

Values (but not names) of configuration settings

Yes

Yes

Yes

Add new certificates

Yes

Yes

Yes

Change existing certificates

Yes

Yes

Yes

Deploy new code

Yes

Yes

Yes

 

Changing Virtual Machine Size example

The following example shows how to change the virtual machine size through the Windows Azure portal.

Figure 1: Initial state of the deployment

When attempting to change the size of the VM without checking the box for “Allow VM size or role count to be updated” the following error will be shown:

Figure 2: Error message when attempting to change role count

Now when the same operation is attempted with the “Allow VM size or role count to be updated” checkbox checked the VM size will be updated:

Figure 3: Update with the checkbox checked

 

Figure 4: Deployment after update has completed

More Control over in-place updates

In addition to the wider applicability of an in-place update, you now have greater control over the update process itself by being able to rollback an update that is in progress or even starting a second update. While an update is in progress (defined by at least one instance of the service not yet updated to the new version) you can roll back the update by using the Rollback Update Or Upgrade operation.

If the rollback operation is specified to be in automatic mode, the rollback will begin immediately in the first upgrade domain without waiting for all instances in the upgrade domain that is currently offline to return to the Ready state. To prevent multiple upgrade domains from being offline simultaneously the rollback can be done in manual mode. In manual mode the first upgrade domain will not be rolled back until Walk Upgrade Domain is called for the first upgrade domain.

Multiple Update Operations

Initiating a second update operation while the first update is ongoing will perform similar to the rollback operation. If the second update is in automatic mode, the first upgrade domain will be upgraded immediately, possibly leading to instances from multiple upgrade domains being offline at the same point in time. Further details on using the rollback operation or initiating multiple mutating operations can be found here.

Summary of Update Options

Now that most modification can be performed using any of the three options for updating a hosted service, it is worth taking some time to describe when each option is most appropriate. This is best described by the following table of advantages and disadvantages:

Update option

Description

Advantages

Disadvantages

In-place update

The new package is uploaded and applied to the running instances of the service.

Only a single running deployment is required.

 

Service availability can be maintained as long as there are at least two instances for each role.

Service capacity is limited while instances are brought down, updated and then restarted.

Service code must be able to support multiple versions of the code running on different instances as the instances are updated

Staged (VIP swap)

Upload the new package and swap it with the existing production version. This is referred to as a VIP swap because it simply swaps the visible IP addresses of the services. 

No service downtime or loss of capacity.

Two deployments are required to be running at least during the update.

Redeploy the service

Suspend and then delete the service, and then deploy the new version.

Only a single running deployment is required.

Service will be down between deleting the service and redeploying the service.

 

Virtual IP (VIP) will often change when the service is redeployed.

Further details on updating a Windows Azure service can be found here.