Structuring Azure solution with multiple roles

Question

I'm curious how others have structured (or suggest structuring) Azure applications that have multiple roles. In particular I'm curious about how you have them broken our between Subscriptions and Hosted Services.

In my particular case we have a web role hosting a webapp & API. That changes quickly, sometimes multiple times per day. We also have several different worker roles to do things like video processing, email sending, and reporting/analytics. The workers change rarely, sometimes less than once a month. We have this all running in a single Subscription. Each Role is in its own Hosted Service.

This setup lets us easily deploy one Role without affecting the others. It also avoids interrupting the Worker Roles unnecessarily, since they are sometimes in the middle of long (10+ minute) processing jobs that would have to be restarted.

So how do you guys do it?

Part of the reason I ask is that Microsoft seems to want you to put everything into a single Hosted Service. eg, the new Caching function that's in Preview is only visible within a single Hosted Service, which makes it nearly useless for the layout I currently have.

Answer 1

This is a bit of opinion, but I think you have the right of it. There are certainly advantages to deploying a single package for all roles (atomic updates, versioning, etc.). However, in more complicated scenarios, I have found splitting into different deployments and hosted services works well. If you want geo-redundancy, you have to have different deployments anyway.

If you are careful with your versioning (assuming your deployments communicate), you can easily have different deployments and get the benefit of quicker deployments. We found that our worker roles have a much higher deployment ratio than our web roles, so it makes sense to split the web roles out. With the new Windows Azure for Websites feature, we are seriously looking at splitting them out even more and simply running the web portion of our app from that. Our API could go there or even deploy to other dedicated instances.

The only thing we have not done is split between subscriptions. I don't think there is a technical reason to do this. There might be a business one to get around quotas, but the reality is that the subscription does not matter as much. It can be real pain later however if you use the Mgmt API to use different subscription IDs for different hosted services. I would also really hesitate to mix and match storage and hosted services from different subscriptions for management purposes. Probaby a good idea to keep it all in the same sub.