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.