Azure Worker Role is not there yet

Microsoft’s furray into the Cloud service providers (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 in and  in Windows Azure it is comprised of a lot of services like Azure SQL, ServiceBus, Web role (to host web sites) 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’s 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* than 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 their former crippled web host was a mistake, but that’s another story). Full IIS means you can host multiple services with out worrying about i. 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 were we’d put our non-stateless, ie. stateful services – and that’s too costly if we go by the book (service per Role) and costly when we cram them all together since now we have to develop quite a lot of infrastructure

Here’s a real-life example : We (CloudValue) are  currently working with a client in the forex market that want to port their 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 build 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 move 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 do 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… :)

---

Illustration by Laura Leavell