Correct approach for deploying a content management Web Application for different accounts on Azure platform

Question

I develop a commercial Asp.Net MVC Web Application. The application is standard, runs on IIS Web Server and utilizes SQL Server database. Our business model is such that we deploy our application on-site in our customers’ Intranet or data center. That is, for each such customer (account) we supply the complete setup, usually installed in a dedicated standalone server. Each such account has its own private content, users, configurations and so on.

We wish to expand and offer our service on the WWW (public Internet). After some research, I’ve chosen Microsoft’s Azure cloud platform to host our application. With some minor efforts (mainly teaching the application to work with Azure’s File Storage using blobs) I’ve managed to fully deploy to the cloud, using three cloud services: Web Site, Data base and File Storage.

Please note that I employ the same code base for the two deployment types (Intranet and Cloud), by using different configurations for Debug, Release – Intranet, Staging – Azure, Production – Azure.

However, the application (as is it written now) can serve only a single customer account, while I need our cloud version to serve numerous accounts (hopefully a lot ;) … each with its own private data set.

Question: which of the following strategies should I employ here?

1. Change the application so it will support multiple accounts. This means changes both in the data model (adding an Account entity in the data layer, bind it to all content types, etc.) and in the business logic.

2. Create for each Account its own site on the cloud (web site + data base + file storage services). This means deploying several times the same application to different Azure services.

It’s obvious that the amount of development needed for the 1st approach here is very large as is the risk in stability of the system, while the 2nd approach requires much less effort.

However, im not clear about how to manage a set of many identical services (applications) each serving a different customer account. I’ve started looking for some tools to help me here (e.g. Red Gate), and would love to hear of more.

Another question is the cost – is such a solution, using many cloud services instead of only few, more costly that the more standard “one application for all accounts” approach.

thanx,

Answer 1

I would recommend (1). It is a higher short term cost in terms of development effort, but will be better for two reasons long term:

1. Cheaper. The costs will go up quite a bit by adding more cloud services. I suppose you could pass this cost on to your client though?

2. It does become harder to manage releases across many clients.

I would say you can either spend your time refactoring existing code you know - or - you can learn how to do dev ops against Azure to manage releases. Probably easier to refactor what you know instead of learn something new.

As a note there are many great SDKs to automate deployments, scaling cloud services, etc.

Answer 2

Found some good reading about this issue:

MSDN: Developing Multi-tenant Applications for the Cloud, 3rd Edition

Provides good comparison between the two approaches:

• Single Instance, Multi-tenant (my 1st option)
• Multi Instance, Single-tenant (my 2nd option)

As it looks i will go with the Multi-tenant approach. All things considered it looks like it will require less development effort and will need less effort in maintenance. Also, my expertise lies in application development and less in system administration (which is required for truly implementing multi-instance solution).

Other reasons: there's a need to share some of the content between accounts (tenants), and this will be more easily achieved when using a single database. Also, there are future plans for the product which can utilize this solution.

Segregation of data will be done (high level):

• File storage (blobs): use a separate container for each tenant (account).

• Database: use tenant unique key to associate content to tenant

• Cahce: use tenant unique key to generate cache keys for cached data items.

Scalability: it is easier using one instance to simply scale up its capabilities, or even move the Web Site to a dedicated virtual machine. In the future can also enhance the system to a Multi-instance, Multi-tenant structure, creating new separate instances for large tenants.