In-Place Updates in Windows Azure
November 21, 2011 1 Comment
Recent improvements to Windows Azure will now give developers better flexibility and control over updating existing deployments. There is now better support for in-place updates across a wider range of deployment scenarios without changing the assigned VIP address of a service. You can read more about these changes in the MSDN blog Announcing Improved In-place Updates by Drew McDaniel. Here is a bit more about the problem space and the new changes.
When you deploy a new service to Windows Azure, it is assigned a VIP address. This VIP address will stay the same as long as a deployment continues to occupy the deployment slot (either production or staging) for this service. But if a deployment is deleted and removed entirely, the next deployment will be assigned a new VIP.
Someday we will live in a world when this VIP address will not matter. For some applications, it doesn’t and the application continues to function just fine if it changes. But in my experience thus far, there are often cases were a dependency on this address will occur. Some very common examples are to support an A record DNS entry for a top-level domain name. Another common example the practice of IP “white-listing” for access to protected resources behind a firewall. I think that in the future, there won’t be a need for a this dependency as the infrastructure world catches up to the cloud movement. But we are not there yet.
In order to preserve the VIP address of your existing service across deployments, developers can utilize to mechanisms: in-place upgrades or the “VIP Swap” which is the swapping of two running deployments (i.e. staging and production). But there were limitations to the types of deployments that either of these methods could support. What this really meant is that as long as the topology of your service didn’t change, this would work fine. But for major releases, it likely would not work. For instance, if your new deployment added an endpoint (i.e. HTTPS), an in-place upgrade could not be performed. Or if your deployment added a new role (i.e. new worker role), a VIP swap could not be performed with the existing production instance. The end result was having to delete the existing deployment and deploy the new service. This would cause a brief interruption in service, cause a new VIP to be assigned, and any downstream dependencies on the VIP would have to be updated. It was a pain to deal with.
The new improvements to how deployments are handled, both in-place upgrades and VIP swaps, will eliminate these scenarios, along with many others! I am very pleased with these updates In fact, off the top of my head I cannot think of a deployment scenario that cannot be supported now by an in-place upgrade or VIP swap. Check out the matrix provided in the link above to see all of the different deployment scenarios which are covered.
We can’t get around taking that dependency on the VIP address of our service, but at least now we are better enabled to deal with preserving the VIP address for our service.
|Learn more about our Seattle office||Learn more about Slalom Consulting Cloud|
Subscribe to follow new Cloud posts