Web Role, Worker Role and VM Role are all designed to solve problems along the continuum of abstraction <==> control that I talked about in a previous post:

image

We call it abstraction because the technology forces a greater separation between the OS and the application.

A traditional application might tend to eat in to the OS and make tweaks and changes: COM registrations, registry changes and so on. The following diagram shows a traditional application’s relationship to the underlying OS.

image

The green hatched area is where the 2 overlap. To take an application that is written in this way and run it on a PaaS system, where the boundary between OS and app is much stricter, is difficult. To handle this problem (and others beside, such as lengthy or GUI-based installations), VM Role was introduced. VM Role is positioned further to the right on the first diagram.

A new product, currently in CTP and part of System Center Virtual Machine Manager, called Server App-V, allows us to take an application like the one above and install it in to a PaaS system, on to the cloud-operator supplied OS image (in this case, a Worker Role in Windows Azure):

image

In this case you can see a clear boundary between the OS and the application. This is taken care of by the “boundary”. The boundary is the application virtualization environment. This environment presents a set of virtual OS services to the application. For example when it makes changes to the registry, it is making changes to its own virtual copy of the registry. These changes won’t affect or pollute the underlying OS.

This technology creates a greater isolation between OS and application and so increases abstraction. This can work with an app written in the traditional way. There is a deal that has to be stuck however. If you want the application to be able to scale out, it has to be written to be stateless. It needs to recognise notions such as multi-instance and scale-out.

If it hasn’t been written in this way, there’s nothing to stop you from deploying it to Windows Azure. But obviously you’ll only be able to deploy to a single-instance. You’ll be unable to get the 99.95% uptime SLA (which is only available if you have more than one instance).

But let’s think about those applications which have developed and grown over the years. There may be large parts of them that are difficult to deploy to Windows Azure because of that green-hatching I talked about above. If the application elements can be separated out – Server App-V for Windows Azure presents new opportunities.

I’ll make a separate post about how you use it to actually deploy an app soon.

Planky GBR-257