Multi-tenant website with high security requirements - possible configurations?

Question

We are building a multi-tenant system for hundreds rather than thousands of separate tenants, with high data security requirements. At the moment, the plan is to go for:

• Isolated databases (one per tenant)
• Website and application pool (one per tenant), running under a unique identity, which is the only identity with access to the corresponding database.
• Separate physical directory structure per tenant

Obviously rolling out updates will need to be fully automated to keep on top of this, probably using MS Deploy + PowerShell scripts, and deployed one tenant at a time.

Are we creating a maintenance nightmare going this route? Are there other possible configurations we should be evaluating in this scenario, that might minimize our administrative overhead without sacrificing the security aspect?

Thanks!

Answer 1

What you are describing would indeed be a very secure way of doing things, but it seems like there would be a lot of overhead involved. One thing to consider is how to deal with logins. Is each user required to specify TenantId, UserName and Password? Or were you possibly going to assign each Tenant a unique sub-domain?

As far as maintenance is concerned, the best way to handle things is to cram as many teneants into a single web server / web farm and shove all of their data into a single relational db / db cluster. That way, when you upgrade one customer, everybody gets upgraded. At some point, you will have to buy another web farm / db cluster to put more tenants on, but you would be suprised how far 1 instance can go.

The exception to this rule is of course the sites like Google and Facebook who have too many users and too much data for the traditional relational dbs. But for 95%+ of sites, I belive this model can work.

As far as security goes, you can add a TenantId to each and every table in your db and filter by it on every query. Yes, this is non-trivial, but neither are the maintenance routines you describe.

Answer 2

What you describe is indeed a way to do Multiple Tenants, but as already mentioned above that isn't the same as Multi-Tenant. See the IBM Developerworks article http://www.ibm.com/developerworks/cloud/library/cl-multitenantsaas/index.html?ca=drs- for factors to consider.

1. Please consider how many tenants you will have and how many users each tenant will have on average.
2. If you are going to have a large number of tenants, then your model might become too expensive to maintain. Ten Thousand Tenants, each with its own database, filesystem structures, etc. well good luck.
3. True Multi-Tenancy like Success Factors, SalesForce.com, NetSuite, etc. are successful primarily because they are Multi-Tenant, one code base, one database model, etc. All Tenants access one large scale system and see isolated data.
4. An alternative to True Multi-Tenancy is virtualization, and with Virtualization such as VMWare you can have your cake and eat it too. Each vmware image has all you need and can be instantiated on demand. You can make one update to the code and deploy it when the image is instantiated. It is going to be much more cost effective than the silos you envision now, but less so than True Multi-Tenancy.