Multitenancy and SharePoint 2010
Before starting this blog let me define multitenancy to ensure uniform understanding. Multitenancy in this context mean isolation of data (including backups), Isolation of usage (what data and services are exposed to the users), isolation of administration (administration of sites, services, customizations), etc. If we consider a hosted environments like SharePoint Online it offers customers 2 mode of hosting
1. Standard: This is a shared infrastructure where multiple customers will be hosting their web applications/site collections (what we call as multi-tenant mode)
2. Dedicated: This is a separate infrastructure of the customer
Some of the biggest challenges that existed in MOSS 2007 for multitenancy include:
1. Where do we host a tenant.. Should we create a separate Web Application or creating a separate site collection will suffice... Of course both have their own pros and cons
2. Services were part of SSP and the alacarte model did not exists and one cannot keep creating a separate Web Application and SSP for each and every tenant
3. Other major challenge was around customizations as the 12 hive folder is a shared one
4. Ensuring the performance of customizations of one tenant does not affect others
So what is that SharePoint 2010 offers to overcome the above challenges
SharePoint 2010 has introduced a new concept called Site Subscriptions to group site collections based on the tenants even if all the site collections are part of the same Web Application. Site Subscriptions not only does externally separate out the Site collections but also the underlying data in the content database. This goes to the extent of one tenants data will not be seen as search result of other tenants data. The same subscription id also helps in grouping of features and services to the tenants.
The next of the problem is around customizations. SharePoint 2010 has introduced a new concept called Sandboxed solutions. What this means is that the tenant administrators (Site Collection admins) can now deploy features local to their site collections without affecting other site collections of other tenants in the same Web Application. This solves 2 purposes. Part of the administration is getting delegated to the tenants. However the central admin still has control and can ensure to big the feature down if it seen to show any performance degradation.