Windows Azure SQL Database Marketplace
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:
Changes permitted to hosting, services, and roles
Staged (VIP swap)
Operating system version
.NET trust level
Virtual machine size
Changing virtual machine size will destroy local data. When making this change using the service management APIs, the force flag is required
Requires Windows Azure SDK 1.5 or later
Local storage settings
Add or remove roles in a service
Number of instances of a particular role
Number or type of endpoints for a service
Requires Windows Azure SDK 1.5 or later.
Availability may be temporarily lost as endpoints are updated
Names and values of configuration settings
Values (but not names) of configuration settings
Add new certificates
Change existing certificates
Deploy new code
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
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.
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.
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:
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
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.
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.