Structuring an Azure Multi-Role Solution

Question

I'm curious how others have structured (or suggested structuring) Azure applications that have multiple roles. In particular, I am curious how you violated them between subscriptions and hosted services.

In my particular case, we have a web role that hosts the webapp and API. It changes quickly, sometimes several times a day. We also have several different work roles for tasks such as video processing, sending email and reporting / analytics. Workers rarely change, sometimes less than once a month. Everything works for us in one subscription. Each Role is in its own Hosted Service.

This setting allows us to easily deploy one role without affecting the rest. It also avoids unnecessarily interrupting work roles, as they are sometimes in the middle of long (10+ minute) processing jobs that need to be restarted.

So how do you guys do this?

Part of the reason I'm asking for is because Microsoft seems to want you to put everything in one hosted service. for example, a new caching function, which in Preview is visible only within a single hosted service, which makes it almost useless for the layout that I currently have.

Answer 1

This is a little opinion, but I think you have the right to do so. Of course, there are advantages to deploying a single package for all roles (atomic updates, version control, etc.). However, in more complex scenarios, I found that splitting into different deployment options and hosting services worked well. If you need geo-redundancy, you should still have different deployment options.

If you are careful about version control (assuming your deployments are communicating), you can easily have different deployment options and benefit from faster deployments. We found that our work roles have a much higher deployment rate than our web roles, so it makes sense to split web roles. With the new Windows Azure feature for websites, we are seriously looking to break them down even more and simply launch the web part of our application. Our API can go there or even deploy other dedicated instances.

The only thing we did not do was split between the subscriptions. I do not think there is a technical reason for this. There may be a business challenge to get around quotas, but the reality is that subscribing doesn't matter. This can be a real pain later, however, if you use the Mgmt API to use different subscription identifiers for different hosting services. I would also hesitate to mix and match repositories and hosted services from different signatures for management purposes. Probaby is a good idea to keep it all in the same unit.