Azure Worker Role Is Not There Yet
Microsoft's foray into the Cloud (a.k.a. Azure) tries to play both in the Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) playgrounds (Kate Craig provides good definitions of IaaS and PaaS if you need them). Microsoft's IaaS offering (though it also has some PaaS attributes) is pretty simple and straight forward with a (yet in beta) Virtual Machine Role (VM Role).The VM role, as its name implies, lets you upload e VHD with a Windows 2008R2 virtual machine image and just run that . It provides a relatively easy path for cloud migration, but it also carries all the caveats such a solution incurs (e.g. the need to find somewhere to persist your data, patching the OS yourself, etc).
Anyway, PaaS is the more interesting offering and in Windows Azure, it is comprised of a lot of services like Azure SQL, ServiceBus, Web Role (to host websites) and our friend — the Worker Role. Microsoft defines the Worker Role as follows:
A worker role is a role that is useful for generalized development, and may perform background processing for a web role. When you have a need for a background process that performs long running or intermittent tasks, you should use this role
That sounds like a good plan — but what happens when you have an SOA with a lot of services? You'd think that it would be a good idea to allocate a worker role for each service, but that will translate to a large usage bill as each worker role runs on its own instance.
If all your services are stateless*, then you can use the web role to solve that. Starting with SDK 1.3 of Azure, you can use full IIS installation (MS understood that its former crippled web host was a mistake, but that's another story). Full IIS means you can host multiple services without worrying about it. And since they're stateless, you can scale easily by adding instances and all is well. This is, by the way, MS's official solution for the problem — which means that worker role is where we'd put our non-stateless (or stateful) services — and that's too costly if we go by the book (service per role) and also costly if we cram them all together, since now we'd have to develop quite a lot of infrastructure
Here's a real-life example: We at (CloudValue) are currently working with a client in the forex market that wants to port its current portfolio to the cloud. The database was a relatively painless port to Azure SQL, the web-servers took a little more work (mostly related to moving to IIS 7.5), but can now be deployed to a web role. The back-end, however, is built from quite a few services — some of which are, lo and behold, stateful. Exchange rates and related market data arrive at high rates and require low latencies. (here is an extreme example) So now what?
The first thing we're doing is moving everything to a VM role — that's the fastest way to get to "something" running in the cloud, and I guess that has some merits in the PR department. If we want to move these services to worker roles or (better yet) to a single worker role with multiple instances, we need to develop the infrastructure ourselves — I'm (re)writing a RoleManager, which is essentially a watchdog that monitors which services are running, allows the different services to be divided between instances, and generally does a lot of stuff I am expecting a PaaS vendor to provide out-of the box. Oh well
I assume that the composite application, which is going to be part of the AppFabric (CTPs planned sometime in 2011), will address this issue; meanwhile, we have to solve this problem ourselves (like the RoleManager I mentioned above).
* Stateless is a nice way to say that you've passed this hot potato to someone else and that the state is now its problem :)