SaaS Multitenant ASP.NET 4.0 – Step 1 Introduction


This is the first in what I have planned to be a series of posts all about moving your application(s) to a multi-tenant architecture.

I have noticed that there really isn’t enough being done in the way of frameworks and tutorials in the area of multitenancy, especially using .NET and the Entity Framework. Please learn with me as I tackle the many problems I am facing right now moving our suite of products to a more Saas friendly environment.

Software as a service

I’m sure most have heard the buzz phrase “Software as a service (SaaS)”, I won’t go into too many details here about the model itself, a quick google search will find many articles that cover the concept much better than I could here. Basically it can be very cost effective for ISV’s as it pushes configuration over customisation, low running costs, subscription paid services and it fits perfectly in the cloud. I really like the concept as a developer because it means less custom coding for client specific functionality, makes it much easier to manage versions of code (when clients are on the same branch) and it is extendable by its nature so gives room for evolutions of the software’s purpose.

This series is aimed at the actual implementation of a multi-tenant architecture using .NET 4.0 technologies. This essentially means allowing multiple clients (or tenants) to run on the same codebase with their own custom fields, themes, workflows and other features.

When implementing this architecure some problems will be faced such as:

  • How many databases will we need? 1 per client, 1 database for all clients?, etc.
  • How will we manage custom client fields that need to persisted to that database?
  • How will the UI change to reflect those extra fields?
  • How do we manage custom reporting?
  • Where will we place business logic that will change per client?
  • How do we inject extra business logic and validation for client specific decisions?
  • How will we manage custom client workflows?
  • How do offer particular features to only those clients who have paid for them?
  • If a client wants to change a theme to suit their intranet’s theme can we allow for this?
  • How will we handle users, login/logout methods, roles and permissions so that the security aspect of the system is abstracted well enough to be easily defined per client? How will the our user’s manage their security roles and users?
  • Is it worth doing all this work, or should we just make client changes on their own versions of code? (Works for a certain threshold of clients to resources and for systems that don’t need much in the way of customisation)
  • How do we build this architecture in the most elegant way. And when I say elegant I mean without needing 20 layers of abstraction

If your still with me you’ll see that multi-tenancy poses quite a few questions and is not something that can be done overnight. The benefits are that you get to manage only one branch of code and can have quite a few clients on there happy without needing to do some serious customisation of the product and without needing to manage a seperate version of code for each client (headache!).

The cons are obviously the upfront cost in time and effort. I’m am facing this problem now and hopefully this guide and the relevant source will help those looking to solve this problem using .NET technolgies.

So stay with me and lets work through this headache together. Up next will be our data access layer and database design.