Multi-Tenancy is Hard: ASP.Net Boilerplate Makes it Easy

If you're liable to start a new web project that even might need multi-tenancy, you should probably use ASP.Net Boilerplate (ABP).  As I've blogged about previously, ABP will save weeks of dev time on new websites, even without multi-tenancy.  However, as soon as you bring on a second customer, I'd estimate you'll eliminate over a month of development time (extrapolating from my 2 ABP project data points, solid math).

But what even is multi-tenancy?  What are typical solutions?  And how does ABP save so much dev time?  Fortunately, I just released a new episode of Code Hour to answer these questions:

If you don't have 35 minutes to invest right now (less at chipmunk speed, even less if you stop after ~6 minutes when I switch to live coding) then let me tl;dr (tl;dw? ?):

Multi tenancy is a software architecture in which a single application is shared between multiple customers.  Each customer only sees their own data and is completely unaware that there are other customers.

There are several ways to approach the problem, as described in ABP's Multi-Tenancy Documentation.

1. Multiple Deployment - Multiple Database

This is the less work up-front approach.  There's no need for a framework, you just deploy your app multiple times, once per tenant.  This offers the best performance (because tenants can be scaled independently) and best data isolation (e.g. database backups will never contain other customers data).

In exchange it requires the highest maintenance cost and most challenging deployments.  The maintenance challenge is you'll need to pay for an app and database for each customer, and if you're passing those costs on, it could be detrimental to smaller customers.  The deployment risk is you'll have to be extremely structured in deployments of app and database script to all environments and carefully consolidate error logs.  

But there are three other common solutions, and in these scenarios ABP brings huge benefits to the table:

2. Single Deployment - Single Database

This is my favorite approach because it's simplest and least expensive to maintain.  In this solution each database table contains a foreign key to a tenants table.  All database queries must filter to retrieve items for the current user's tenant and insert records with the current users tenant.  When doing it by hand it would be a pain to apply these filters to every single query.  Enter ABP.

By inheriting from the IMustHaveTenant interface, ABP give all entities a foreign key to a Tenants table.  Then, silently in the background, ABP figures out the tenant of the currently logged in user and for all queries only returns the records from that tenant.  If a user creates an entity with IMustHaveTenant, then ABP additionally automatically sets the correct foreign key.  No code is required and all database queries pick up this filter (just like the soft delete I described in Be a Hero On Day 1).

The downside to this approach is that one tenant with a lot of data could affect the performance of other tenants, and some users might worry about security since all data lives in the same database.  So there's another approach ABP provides:

3. Single Deployment - Multiple Database

When a user from the host (host = a singleton tenant that can create other tenants) creates a tenant, they can specify a connection string specific to that tenant.  ABP even offers a cool solution to data migrations that I explain in the video (at ~12:55).  But the end result is much better data isolation, great performance, but still a potentially high price tag since you could be paying for one database per customer.

4. Single Deployment - Hybrid Databases

ABP offers the best of the last two solutions by allowing some tenants to live in shared database instances and others to live in their own databases.  This offers data isolation and performance to tenants that need it (or will pay for it), and value for tenants that don't (or won't).  

What's awesome about ABP is that it works identically from a code perspective for all of the above multi-tenancy approaches.  The only difference is whether a tenant's connection string property is provided or not.  The filtering, permissions, and migrations are otherwise all identical.

Summary

If you've interested in more details (such as how to disable tenant filtering) please check out the video (and like and subscribe and all that).  Also, hit me up on Twitter if you have any questions, comments, or threats.