Multi-Tenanted SharePoint 2010 Platforms
Since the emergence of the cloud, more specifically ‘Software as a Service’ or SAAS, applications which may once have been deployed locally in the corporate data centre are now being delivered via an externally managed shared infrastructure, the services of which are acquired via a subscription providing the already well documented benefits, Office 365 provides a market leading example for cloud delivered mail, communication and collaboration services.
There are new capabilities embedded within the SharePoint 2010 product which provide additional options for developing SAAS platforms which support a high number of tenants, again Office 365 collaboration services is a good example of the type of proposition which could be developed.
There is a huge amount of interest and active initiatives towards developing multi tenanted SharePoint 2010 platforms, many of which are time critical as organisations attempt to capture the market; and as trusted advisors we regularly discuss the differing approaches for architecting multi-tenanted SharePoint 2010 platforms with our customers. This blog post is aimed at dispelling a common myth that the multi-tenanted features of the SharePoint 2010 platform are mandatory for implementing a multi-tenanted offering.
SharePoint technologies have pretty much always had a multi-tenanted hosting capability, for example a MOSS 2007 server farm could host multiple types of differing applications targeted at completely different user groups, exposed via the internet all utilising different authentication mechanisms, examples include;
- Group wide global intranets
- HR / Marketing / Partner / Supply Chain Portals etc.
- Team Collaboration Sites
- Subsidiary Public Facing Websites
This approach is still valid for SharePoint 2010 and for the sake of this article we’ll refer to it as ‘Standard Mode’; the core advantage of standard mode is that all the components and features of the SharePoint 2010 platform are available as are the extensibility points. Traditionally this mode of deployment is adopted for serving multiple internal clients within an enterprise; however this is also potentially a viable approach for delivery to external commercial customers. A high level example of a SharePoint 2010 ‘Standard Mode’ logical architecture is depicted below:
This example assumes each client would be assigned an application pool capable of hosting multiple web applications. There are multiple variations on this theme which could be adopted, but whichever logical / physical topology you opt for make sure you are within the products supportable boundaries and your client’s security, functional and non-functional requirements are met.
This approach to multi tenancy can become expensive to scale, difficult to operate and maintain as the number of tenants increases. The scale path typically involves provisioning additional server farms as the supportable number of tenants per farm (Derived from the specific architecture selected) is lower than a server farm where the multi-tenanted features have been enabled.
The core driver for enabling the multi-tenanted features within a SharePoint 2010 server farm is scale, aka support for a high number of tenants (1000’s) with segregated data. In ‘Standard Mode’ operation the number of supportable web applications and application pools per server farm, and ability to segregate service application data become limiting. Enabling the multi-tenanted features referred to as ‘Hosting mode’, provides a method to overcome these limitations, a high level example SharePoint 2010 ‘Hosting Mode’ logical architecture is depicted below:
There are concessions with this approach as both the platform feature set and available extensibility points are reduced, however these concessions can lead to a more robust and scalable platform, simplified operations, data segregation and functions to help inform or develop a charging model.
The following matrix shows the characteristics of both modes of operation, note this is not to scale but hopefully portrays the message that mode selection is not always a simple or trivial decision:
A valid question, “at which point do I enable hosting mode?”, and the answer is very much “It depends” and here’s a few (Not exhaustive!) reasons why:
Functional Requirements
Let’s take a basic example; a feature of FAST search could be fundamental to differentiating your SAAS offering in the marketplace, a USP! however as a FAST service application cannot be partitioned you’d need to determine either another viable approach for provisioning required functionality within hosting mode or designing a standard mode architecture which scales in line with operational processes and the cost model. It’s imperative therefore to design the platform architecture against a ratified set of requirements or service level specification.
Data Security and Regulatory Compliance
As the cloud evolves more and more business data will migrate from corporate data centres into the cloud, data security especially in heavily regulated industries is fundamental to the decision making process. Providing a secure service to meet a specific regulation could be the USP, even if not, it’s imperative to ensure the design selected mitigates risk of a customer’s data being comprised. Hosting mode will not allow worker process isolation or isolated data storage therefore understanding the services data security requirement becomes a core design decision, i.e. if either of these configurations are required, hosting mode is not suitable.
Cost Model
Developing a successful SAAS proposition is a fine balancing act; the proposition must provide the required service to compete within the market at the targeted price point, and in addition revenue must exceed initial and on-going costs to make the service a viable investment. It’s critical to understand the boundaries of your design and the associated costs to scale the service, for example the hardware costs alone could be very different across the modes of multi-tenancy discussed within the article.
The SharePoint 2010 platform provides a myriad of options for architecting SAAS solutions, to succeed we believe a detailed requirement and workload driven architectural design process is fundamental to success. In MCS within the UK, we’ve gained extensive insight into the SAAS design process and could add significant value to you programme of work, please get in touch if you’d like to discuss further.
 |
Jay Goodison - Senior Consultant Microsoft Consulting Services |