A hosted service is likely one of the most versatile components of Windows Azure. So many different application architectures can be implemented with hosted services. Even if they include another language or framework than .NET. When implementing a site or service on Azure, I will first consider using a Web Role. If the application lifecycle either requires lots of background processing or does not work under IIS management, a Worker Role will do the trick. With either the Web or Worker Role, you can also invoke start-up tasks to install or configure any other dependencies.
If the application is a migration or requires a large amount of fragile configuration, one option is to use a VM role. A VM Role is currently (as of May 2012) a beta program. To start using this role you need to sign up for the beta program using the Azure management portal. Even if you use a single Live ID for multiple subscriptions, each subscription needs to be accepted into the beta program separately.
With a Web or Worker role you have the option of using a Server 2008 or 2008 R2 OS. A VM Role however, needs to be created with Windows Server 2008 R2 Enterprise.
It is not uncommon for someone to consider the VM Role as an IaaS (Infrastructure-as-a-service) implementation. It is very important to note that the hosted service is still stateless. Any changes the the virtual hard drive of the VM once it is live will be lost if the machine is migrated to a new host. In my opinion, to classify a service as IaaS the current state of the VM should be persisted. Alternatively, because Windows Azure is a PaaS (Platform-as-a-service) the virtual machines are provisioned repeatedly when needed. Provisioning a machine involves installing the hosted service package. In the case of a Web or Worker role, Visual Studio invokes the SDK command line tools to create the ZIP file like package for the hosted service. If the solution is to complex to setup in that package, using a VM role is the next option. However, because the VM needs to be sysprepped before uploading, it acts as the deployment package.
Later in an upcoming post I will go through the process of creating and hosting a VM role. For now I want to outline a couple of considerations when setting up a VM for Azure hosting.
VHD Size: You can use a dynamically expanding VHD however on some documentation the max size for the different VM sizes is unclear. Use the following as a guideline when creating disks.
Extra Small Instance – 15GB VHD
Small Instance – 35GB VHD
Medium, Large, and Extra Large – 65GB VHD
When using the command line tool to upload the VM, the output will tell you which VM sizes can be used with the VHD.
Machine Name: When setting up a VM for hosting, sysprepping the VM is one of the final steps before uploading. Because the machine is sysprepped, once online the machine will have a different name than previous. This will affect the security and user accounts on the machine. One suggestion I have for this is to use the IIS app pool user rather than a local configured user. Of course there may be a number of other issues this can cause. Once the machine is prepped locally on you Hyper-V host, create a differencing disk an start the machine back up to test how the machine reacts to being prepped. This allows for a close feedback loop, rather than taking 4-8 hours to upload the VM and try it online.
Ok that’s all I have for now. Stay tuned for more info about the VM role and setup process.