This project is read-only.

Current Multi-Tenancy Architecture

Topics: General, Writing modules
Sep 19, 2011 at 5:43 PM

This is a bit of "what do people think?" post. 

We're beginning to use Orchard for commercial clients who have multiple brands. The initial direction I'm taking is to look at each brand as a tenant within a multi-tenant Orchard installation. This does give us the ability to easily allow for multiple content and separately maintained visual appearance for each brand site via Theming, etc. That's cool, but we also have a few problems if we take this approach.

Right now the tenants are essentially a "shared nothing" approach. They have entirely separate schemas, whether in the same DB or not (we'd probably run a DB per brand for performance, resilience, etc. reasons). However a client who is expecting to manage multiple brand sites would like a global administrative account with which they could administer each site. In fact, they'd like a model where users may be able to log in to one, some, or all sites, depending on their permissions. At the moment, this isn't possible, as the user storage is per tenant.

Additionally, you wouldn't want everyone having access to tenancy management. This isn't a problem with the current model as we just wouldn't give them access to logins for the Default site. But there may be instances where they would want *some* users to be able to manage tenants (suspend/resume, likely).

The Default site is also likely "wasted" in a situation like this. You wouldn't use it as a public facing site (one of the brands) as you don't want to enable access to tenancy management. So it's essentially a "dead" site in some sense. All it really needs to be in our model is essentially a tenant/site manager with no actual CMS site (and global user manager, in an ideal world).

So, what would people think of the following?

  • When installing an Orchard site for the first time, you select whether you want either a standalone site, or a multi-tenant site. If standalone, it works as now. If multi-tenant, it uses a recipe to set up a minimal site with only a secured area, configured as a tenant manager.
  • Users (only users for now, but I can see more in future sadly) becomes a shared data source, using a "common" database/schema. This would require changing users to have a composite key of name + site, or possibly something a little more complex as you would likely want a one to many relationship between users and sites.

It's not ideal, just some initial thoughts. Of course you would want to keep the ability to have users entirely sandboxed (logically) per tenant, but allow for cross-tenant users if required.

This would open up Orchard to some new use cases perhaps, but it is not insignificant as a change. I thought I'd see if anyone had any opinions to start with.

(I don't know what the committee process is yet to raise things with the members and benevolent dictator?...)

Sep 19, 2011 at 8:35 PM

Yes, this is actually a very common request. I think we should look at it.

As for process, we'll have a committee mailing list shortly, that will be public, for this sort of thing.