The Sheep-Pen of the Shaun

News

Shaun, the author of this blog is a semi-geek, clumsy developer, passionate speaker and incapable architect with about 10 years’ experience in .NET and JavaScript. He hopes to prove that software development is art rather than manufacturing. He's into cloud computing platform and technologies (Windows Azure, Amazon and Aliyun) and right now, Shaun is being attracted by JavaScript (Angular.js and Node.js) and he likes it.

Shaun is working at Worktile Inc. as the chief architect for overall design and develop worktile, a web-based collaboration and task management tool, and lesschat, a real-time communication aggregation tool.

Image Galleries

.NET

Today the Microsoft announced that the In-Place Upgrade feature had had some improvements. The major one would be, now the user could be able to change the VM Size by In-Place Upgrade, without redeploying the whole service.

What We Did Before

Before this improvement, since the VM Size was defined in the CSDEF file, we have to redeploy the service to change the VM Size property. This means we would remove the existing roles and VMs and then ask the Windows Azure to reallocate the new VMs with the new size, install the OS and runtime, extract and deploy our application.

Changing the VM Size is a very common requirement for scaling-up and down, which should not lead to the service down. But in Windows Azure, we should use redeployment which causes the service invariable at that moment.

What We Can Do Now

Let’s just have a look on what we can do to change the VM Size without redeploying the service. First of all, we need a hosted service created through the developer portal. And then, create a new windows azure project in Visual Studio. Let’s just added a ASP.NET MVC 3 Web Role, and set the VM Size to Extra Small. And then deploy this project to Windows Azure.

Let’s change the VM Size in the Visual Studio from Extra Small to Small and create a new package. After that we back to the developer portal and use In-Place Upgrade to upload the new one. In the In-Place Upgrade dialog we should check the box “Allow VM size or role count to be updated”, otherwise the upgrading will be failed.

The upgrade will take longer than the one without changing VM Size, since the Fabric Controller need to find a proper machine to host the application. This will cause more time, and more importantly, changing VM Size by In-Place Upgrade will erase all customized data on the original VM.

What I Can Do Else via the In-Place Upgrade

Not only changing the VM Size, now we can add or remove the roles, change the endpoints number and type, and increase the local storage size by using In-Place Upgrade. For example, in Visual Studio let add a new Worker Role and add a new input endpoint on the MVC 3 Web Role to 8080.

Then package and use In-Place Upgrade to upload to the hosted service. As you can see the new role and endpoint had been established.

PS: Do not forget to check the “Allow VM size or role count to be updated”.

Why I should Use In-Place Upgrade

In-Place Upgrade provides the ability to ensure our service will be keep running and available during the upgrading. Different from the redeployment, if we have more than one instance per role, it will be available during the In-Place Upgrade process, by performing the operation in each upgrade domain one by one. For example, if we have a web role with 2 small VM instances, when we changed it to small, only one instance will be changed at a time, then after it had been finished, the rest instance will be changed.

What’s Next

It’s said that in the coming next release, we can do more in Visual Studio directly rather than navigate to the developer portal. At that time the developer can finish the whole deployment task just in Visual Studio.