Multiple apps on Azure - one app-per-service or all-in-one?

Question

We are developing a large application that consists of several web apps (under separate domains) as well as a background scheduler (using Quartz.net) which would run on a Worker Role (currently it is a Windows Service but that doesn't make sense on Azure). I am trying to figure out what is the best approach for us: separate hosted service for each app or running all apps under a single hosted service/role. I guess there's a third option of running multiple web roles under a single hosted service but then I need to utilize ARR (app. request routing) which I'm not sure what benefit (if any) it will give me. Sounds to me like even more overhead but I could very well be wrong?

My projects are:

• Public facing website - low load
• Private dashboard - moderate load
• Tracking (analytics) app that tracks impressions, clicks, etc. - high load - 5+ million clicks/month
• API - also high load as the Tracking app relies on it
• Quartz.net scheduler (worker role)

The public website and dashboard probably should be on a single web role but I am unsure whether the tracking and API projects should be using their own cloud services so they can scale independently or whether I should run everything on a single web role using host headers (except the scheduler of course) and scale everything at once. All hosted services will be running multiple instances so I'm not worried about things going down during deployment (as Azure transitions one instance at a time).

Also, is running on a single role going to give me better latency between the client apps (web, dashboard, tracking) and the API or do affinity groups and virtual networks make that point irrelevant?

I have been searching for the best answer for a while but haven't found anything conclusive enough.

My primary concern is raw performance and scalability. Price is not a deciding factor for us.

Thank you

Answer 1

It depends...

There are a couple of dimensions to your question that you need to consider.

• Deployment and versioning - Do you wish to be able to version and deploy parts of the system separately? There is an added cost to maintaining separate deployments, but the benefits are increased flexibility and ability to deploy changes in isolation. This is the most important aspect of your decision.
• Team structure - Do you have multiple teams working on the system? I would highly recommend separating deployment and versioning along team lines.
• Scalability - Both options are equally scalable from a performance perspective.
• UI performance - This shouldn't be a primary concern of your deployment design.

How we have approached this problem:

• Each system/sub-system has its own deployment and its own storage account. This allows for easy versioning and operational management.
• Our systems/sub-systems are designed to perform a number of highly cohesive responsibilities.
• Inter-systems communication is message based (Azure queues for example).
• Each backend worker role's responsibilities (what we call "Role Services") can be easily moved between different Azure deployment roles via configuration depending upon the required performance characteristics.
• All backend work should be performance on a worker role. IIS is a terrible host for background processes.
• UI performance is achieved by materializing all views (either into blob storage or memory). A cache could be used as well.

Answer 2

There can not be one single answer to your question ever.

As your tracking app is basically based on your API, so i am assuming that there is no direct outside traffic coming to your API and its only used by your tracking app. So in this case i will have both of them in a single web role.

However, if you are expecting huge load on your API other than from you tracking, considering that there may be some external clients of your API, then better to have it on a separate web role.

Regarding you other 2 web apps, as they don't have much load, you can actually combine them with either of your tracking or api roles. Else, if you really dont care about pricing have a third role to host you public site and dashboard.