Skip to content

Many mistakes in my previous post? (more on Azure worker role)

I’ve got a comment from a user calling himself “AzureBizAndTech” to my previous post . Unfortunately the comment was deleted in in DDJ’s move to a new blogging platform over the weekend. The person, who apparently works in Microsoft (per his first point- see below) posted the comment with the title “Many mistakes in this post”. Below are his points and my reply

1) VMRole is not IaaS. This is not my opinion. It is Microsoft’s (my employer) stated position.

Sorry however, whether an offering is IaaS or PaaS or anything is determined by its capabilities not by the label some marketing person put on it. The VM role is more IaaS than PaaS. It is true that it isn’t a realy IaaS since it has a limited support of VMs (e.g. you can’t run Linux on it)

2) Yes, it is a good idea to allocate one service per role. How else are you going to scale?

First off, scale is not the only reason for moving to the Cloud, probably not even the major reason to do so. Reduced IT costs, right-sizing hardware needs, flexibility are some of the other reasons to move. From a pricing perspective this can prove to be a poor choice. Let’s do the math. The particular client mentioned in the post has 4 web sites (variations on the product) and some 20 services. If you have an IO bound application (which they do) than you should probably use  a medium instance (smaller instance have moderate or low IO performance). You’d want to run 2 instances per role (to get the 99.5 uptime guarantee ). Yearly cost =0.24$ * 24 hours * 365 days * 24 roles *2 > 100K$ where we can probably pack everything into 2 extra large instances at 16K$ per year. Yep great idea indeed

3) Services (Web or REST) can be implemented on either Web or Worker roles.

It seems that by services you mean “web-services” but that’s not the only way to implement services. In any event I didn’t say you can’t. However Worker role (or VM) is where you can implement stateful services if you need them

4) The cost of a proper architecture in Azure is a business discussion not a technical one.

See point 2 above. Generally speaking architects who ignore the cost of their architecture are bound to fail. It is never just a business discussion (same goes for other “business” concerns like time-to-market etc.)

5) Worker roles are NOT where you put all of your stateful services. Worker roles are used to implement non-web tier services. Which also need to be stateless in order to scale.

Again the scale thing (it reminds me this :)) So basically you are saying that unless you are stateless you cannot scale? is SQL Azure Federation a hoax then? Or is Microsoft the only company with the smarts to build stateful scalable solutions?! or what?

6) CloudValue is attempting to use the Windows Azure Platform as a host. Cloud platforms are not hosting platforms That is a different paradigm.

Let me get that right – Are you telling me to advise my clients to move off of Windows Azure? Is this an official Microsoft stand???  Seriously, I know it is not as we are working with MS reps in Israel and UK to help get them to the cloud  but come on…

Don’t get me wrong. Azure has some really nice features and it keeps improving all the time. I think worker roles (or something on top of it) need to provide a higher level of abstraction from the mapping to an instance so that you can really right-size your IT spending. Not every solution needs to scale to Google or Facebook size

Published inBlog


  1. Jesse Ezell Jesse Ezell

    The real problem is Microsoft understands the cloud about as much as they understand all their online business.

  2. I really hope for them that you’re wrong. MS is facing a lot of challenges in a lot of fronts (cloud, mobile, search, tablets etc.) It is no longer obvious whether they are up for the task

  3. John Donnelly John Donnelly

    Sorry for the poor experience you’re responding to.VM Role is probably being positioned as PaaS rather than IaaS because grouping it with infrastructure offerings would cause more confusion for customers. Agree that this is a difficult area for categorization as this particular implementation is somewhere between the two but for me the key differentiator is not the ability to run a particular OS, but rather the intent to enable complex configuration scenarios that can’t be accomodated with startup tasks (it wasn’t intended to be IaaS even if it looks like similar) the availability of truly persistent local storage (worst case leading to innappropriate architecture where customers don’t realise we will dispose of the drive contents when the role recycles), and ability to engage in service topology. Together these make it easier for me to think of VM roles as an unusual form of platform as service rather than infrastructure.For a mature audience there’s possibly too much focus on “Web roles needing to be stateless”. However I still see a lot of smaller organisations (and departments in larger organisations who often partition the physical architecture to replicate the logical architecture) who never ran a clustered web server before, need server count to recieve the SLA, and need spelling out the implications of having more than one server behind a round robin load balancer. There are samples for a table based session provider and the new caching service looks interesting as a location for session data, or you can attempt to design the requirement out of the system. Pick what works best.The App Fabric (the technology not the marketing name) is probably able to do more useful monitoring of worker and web roles than it can of vm roles. If you’re not already, consider mitigating this by increasing the monitoring you perform of your roles and requesting a recycle if necessary. I’d love to hear a little more detail (blog please its not like I’m on the product team) about what extra services you’d like to see to support worker roles. There’s a few companies around who are interested in layering management over the capabilities in Azure so this may help create other products you’ll find useful.

Comments are closed, but trackbacks and pingbacks are open.