In Windows Azure: What are web role, worker role and VM role?
The application I work on contains a web role: it's a simple web application. I needed to host the application in Windows Azure, so I created a web role. I actually want to know what these roles are for. What is their significance coding wise or storage wise?
Answer
EDIT 3/3/2013 - updated to reference UDP endpoints, Virtual Machines, and more languages
EDIT 6/6/2013 - updated to reflect the discontinuation of VM Role, and update to web/worker role baseline OS images to Windows Server 2012
Good link by @Vladimir. A bit more clarification: All roles (web, worker) are essentially Windows Server. Web and Worker roles are nearly identical:
- Web roles are Windows Server VMs with IIS enabled
- Worker roles are Windows Server VMs with IIS disabled (and you could manually enable it)
- VM roles are Windows Server 2008 images you construct locally via Hyper-V and upload to Azure (and are now discontinued and no longer available as of May 31, 2013
- Virtual Machines are Windows or Linux images created in Azure, stored as a vhd in your own storage, and have several enhancements over VM role. For example: since the vhd is in your own storage account, you can easily create an image template from your vhd, copy it to a new vhd, or even upload it to VM Depot (Linux only).
To answer your question about what to do with these roles: The Platform Training kit (mentioned below) will give you lots of good ideas and samples, but here are some straightforward use cases:
- You can run any code that exposes a tcp, http, https, or udp endpoint (web applications, SOAP/REST services, etc.). You need to think about the stateless way of doing things though - if you have more than one VM instance running, user traffic is distributed across those instances. The platform training kit will show you how to use storage or cache to deal with this.
- You can run code that lives off a queue or a timer. Maybe you have on-demand tasks such as thumbnail-generation of photos, or calculations based on user input. These don't need externally-available endpoints. You can push your requests to a queue, and then have a task running which simply feeds off this queue (and you can scale this process across multiple instances, with queue messages consumed by all instances).
- You can run .NET, Java, php, python, node, ruby, etc. You just need to distribute the appropriate runtime code along with your project code. All languages can make REST calls to the Azure API, and several languages (including those mentioned above) have SDKs that take care of this for you. All language SDKs are here, with source code on github, here.
With a VM role, you can install and run software with very complex/time-consuming installations, installations that require manual intervention, and installations that can't be reliably automated. You must deal with OS maintenance in this case. Beyond VM Role, there are now Virtual Machines, providing cloud-based VM construction along with both Windows and Linux support. I'd suggest Virtual Machines over VM Role.
With Web and Worker roles, the OS and related patches are taken care of for you; you build your app's components without having to manage a VM.
With VM roles, you build a complete Windows Server image, add the Azure hooks to it, and push the entire VM into the cloud (and then maintain the VM image over time).
With Virtual Machines, you simply pick an OS image from a gallery, which gets created for you and stored as a vhd in blob storage. You then RDP/ssh and set it up how you like.
Wearing the architect hat, this is where it gets fun and interesting. You can run web services in a Web Role or worker role (and be able to open ports in either); You can host Tomcat or other web servers in a Worker role. you can choose to combine a website plus services in a single role, or split them into multiple roles for different scalability needs.
For a good start, take a look at the Platform Training Kit and start walking through the exercises.