Jurgen
Jurgen

Reputation: 1

ASP.NET MVC on Azure: combine or separate web roles?

I'm working on an ASP.NET MVC 5 web application, hosted on Azure, which currently has the following setup:

These web roles are combined in 1 Azure Cloud service, including a SQL Azure database for data storage. Web role 2 uses in-role caching to cache most used entities. The reason for using the Cloud service, is that the in-role cache is shared between all instances of web role 2, inside the Cloud service.

My initial reason to seperate UI from the actual 'work' over 2 web roles, was to optimize performance, by not having cache and data handling interfere with presenting the UI. Also, when needed, I can configure extra instances for any of the roles in Azure, and can specify maximum cache size to use for role 2 without having it take memory from role 1. This all actually works well.

Now for the question... it can be a pain to maintain and update these 2 roles. Also, client-side can be a little tricky with CORS HTTP POST not working well in all (mobile) browser over https etc. So I was thinking of combining the 2 applications into 1: 1 project in 1 web role, with both the MVC and MVC web api stuff. Would this perform as well as the separate setup? I could configure the web role to use more instances/memory in Azure. Would that be as good as having 2 separate roles with their own instances, especially on high loads with a lot of async calls going on from client to server?

On a side note: I was playing around with ASP.NET 5 (vNext), with MVC 6, which has eliminated the differences between 'normal' MVC controllers and Web API controllers. This also tempts me to make my 2 separate projects into 1 ASP.NET 5 project. There's no support in the Azure SDK/Visual Studio to deploy an ASP.NET 5 project in an Azure Cloud Service, but that's probably a matter of time.

Upvotes: 0

Views: 358

Answers (2)

Paul Fryer
Paul Fryer

Reputation: 9537

To keep things simple combine your website and api in the same app. Just make sure the whole thing performs and scales, this implies a stateless architecture that can auto scale. Your MVC pages can serve in all the routes they usually do, then group all your WebAPI controllers under "/api".

Upvotes: 0

Francesc Castells
Francesc Castells

Reputation: 2857

What exactly is your concern about the Web UI role? If it's a single page application, it will only server the index.html file and a few static files (very few and relatively small if you bundle everything). This shouldn't have much impact if you put it in your API role.

On the other hand, I use a different solution. I deploy all the SPA files to blob storage. I have only one role with the API and a single Index action method which goes to blob storage, gets the Index.html, injects the blob storage base url where is needed (basically css, js and images paths) and serves it to the client. So the web role handles only a single very light browser call every time the SPA is loaded in a browser. The rest of the load goes to the blob storage (and it's not a lot anyway).

I hope this helps.

Upvotes: 0

Related Questions