Multi-Tenant Use Cases
The use of multi-tenancy in the
traditional hosted services scenario should be clear at this point. For
example, suppose a hosting company decides that it would like to be
able to sell SharePoint services to its customers. All the customers
will be different individuals or companies that want assurance that
their information is kept separate from the other sites hosted on the
common infrastructure. Windows SharePoint Services (WSS) 3.0 included
mechanisms to keep a customer’s content separate from other customers’
data, but it lacked the capability to separate processing and data from
additional services such as Enterprise Search.
These customers would need to be provisioned using an STSADM
command and be given site collections that would be held in shared web
applications. The hosting company was also bound to using WSS because
of the common shared service provider (SSP) found in MOSS. One of the
challenges that the SSP created in this specific scenario was with
Enterprise Search. Enterprise Search was designed to index all content
associated with that SSP. The query service would then provide results
to users when requested. The challenge specific to this scenario is the
very real possibility of exposing customer A’s data to customer B via
Enterprise Search, as MOSS lacked the capability to segment the data
based on site collection. Adding SSPs was not an option because the
number of SSPs that can be provisioned in a single farm is limited.
The newer service application architecture fixes
this through service application partitioning as discussed throughout
this section. Partitioning creates secure boundaries between
information and processing based on site subscriptions, making it
impossible to expose customer A’s data to customer B. As previously
mentioned, partitioning must be done when the service application and
proxy are created. Now let’s apply the concept of partitioning to the
enterprise.
Partitioning in the Enterprise
Just as it would in a hosted scenario,
a large enterprise needs to handle data and services in a manner
similar to the hosted world. Consider, for instance, managed metadata.
There are terms within the organization that need to be controlled by
one central group and consumed by the entire organization. Other terms
ought to be defined and managed by individual corporate divisions or
departments. The same holds true for Enterprise Search. A partitioned
Enterprise Search service application would enable content from one
department to remain wholly separate from content in other divisions,
as depicted in the general council example shown in Figure 2.
The capability to segment this data and to create
feature packs gives both the multi-tenant hoster as well as the
Enterprise customer an opportunity to offer different tiers of services
to their customers. The hosting company can provision a single farm and
provide SharePoint Foundation, SharePoint Server Standard, and
SharePoint Server Enterprise products. To take things one step farther,
they could also layer on additional third-party tools to enhance their
product offering and more easily manage the provisioning and billing of
those services.
From the Enterprise customer’s point of view,
they can provide multiple versions of SharePoint to their users on a
single farm. For instance, only half of a company’s 10,000 employees
may need SharePoint Foundation capabilities. The remaining user
community may need SharePoint Server Enterprise features. Individual
SharePoint farms can now have multiple licensing schemas associated
with them in a way that is easier to manage and control. In this case,
only 5,000 users would need SharePoint Server Enterprise licenses,
while the remaining users would use SharePoint Foundation licensing —
and this solution would be perfectly acceptable to Microsoft.
The additional capabilities provided by the
service application architecture, as well as the partitioning features,
provide additional scalability previously not available in SharePoint.
For instance, as Enterprise Search grows in content size and usage, it
can now be segregated into its own SharePoint farm created for the
purpose of providing Search services to the content farm(s). These
types of farms, known as service application farms, provide services and data to other SharePoint farms; they are not directly consumed by users. Figure 3 shows an example.
FIGURE 3
