Implementing Multi-tenancy Infrastructure with SharePoint 2013 (SAAS) – Part 2: Planning for Deployment

– The Step by Step Guidance for Creating SharePoint 2013 Based Multi-Tenant Infrastructure,   Part 2 Planning for Deployment –   

Planning Your Deployment

Seems you are continuing to read from Part 1 of my Article Series.

For sure you will need few days to test the entire Multi-Tenant functionality properly. All the below perspectives are entirely depends on the Product Knowledge and the past experience. Performance is ofcource a major concern as this isn’t a generic setup where a single Web Application and few Site collections will serve requests. In this case we are talking about a Hosting Vendor who will be Providing a Stable, reliable and well performing SharePoint online service for its Clients.

It’s also goes more deeper when we think of Intranet Scenarios. Customer may host their Web Portal or may be Intranet Portal. Intranets needs robust environments as it will be heavy with lots of Services and content. Performance, Storage and Security is a big concern here.

However, there’s no environment stays static so you might need to scale up-out based on the utilization of resources. Specially the storage you won’t be able to stick to the initial when it becomes popular. So the improvements has to be done for sure.

You need to read more on SharePoint Hosting Guides given by Microsoft as I stated in the Part 1.

Test (POC)

Prior to the Production Deployment, It would be a great idea to run this and try out in a POC (Proof of Concept) Setup. A Single Server would be sufficient but multi-Server environment is ideal so you get the real world experience. Unlike generic SharePoint Farm deployment, Multi-tenant Farms are more tricky. You need to Plan a lot which is extremely goes in to the deep dive as down as Hardware, Software, SharePoint Services Allocation, Service Segregation across Servers, Performance Considerations such as Storage (IOPS), Security Requirements (Publishing Through Proxies) etc..

Hosting Tenants – Where the customer Tenants (site Collections) will sit on.

A Single Web Application for all the Site Collections (Tenants) ? Or a dedicated Web Application for Each ?. Well, This thing is entirely depends on how far you will go. Microsoft Does not recommends to Host more than 20 Web Applications per farm. This is a threshold not a Limitation. Yet it is considerable since you are not supposed to exceed the recommended level in these kind of critical real world scenarios.

Planning Backend for Tenants

Basic Idea of this is, whether we are isolating our customer’s site collections Databases or not.

Single Content Database for all ? Not a good idea. Data isolation is a prime concern when we talk about Multi-tenancy and a Dedicated Content DB per tenant would be ideal. When it comes to the scaling perspective, Isolated DB is ideal.

Site Collections and Database Limitations and Recommendations

Isolation is all about Site Collections and Databases. You have to go through Software Boundaries and Limits for SharePoint 2013 during your planning.

Active Directory Perspective

The Isolation also comes from Active Directory side when we talk about Security. Tenant A (Customer A) should not be able to see the users of Tenant B (Customer B). When a user of Tenant A trying to Search another user through the People picker, he should be only able to see the result within his tenant. This is a Security practice which will be implemented via Active Directory Organizational Units (OU).

Users

Where we store our Users is not a matter here. Yes you got it right ! We can use the Active Directory as I have shown in the diagram above. You could use somewhere else to store the users but you got the best place to store them, why somewhere else is depends on your requirements. I would straight go with AD through dedicated OU Concept which is too easy and centralized. I will only need to look after the AD Objects so the windows authentication is way smarter.

URL Considerations

The other Key point to make decision is, URL. How you are going to let your customers to access the site. There are two choices as 1. Ordinary Addressing and 2. HostHeader Site Collections.

Also there can be below possibilities. In this scenario we have to consider that we will provide all these for our customers.

1. Allowing Customers to Create Site Collections under their root
2. We Will provide Content Type Hub, My Sites, Tenant Administration Site

E.g. scenario – Above features may depends on the level of Subscription (feature packs you are setting for the tenant). Yet you need to make sure how these sub site collections are addressed. Take below sample scenario to get an understanding.

Web Application – Root (http://HostingProvider.com/)

Tenant URL – /TenantA

Other Sub Site Collections

/TenantA/CTHUB

/TenantA/MYSites

/TenantA/MySites/Personal

/TenantA/Admin

/TenantA/Sites

Per Tenant There going to be Lots of site collections where each stands there for a specific purpose. This is a hassle to manage with path based concept isn’t it ?. And the critical point is, Performance. Having lots of Managed Paths in a single Web Application will give you performance overhead. The recommended number of Managed paths per Web Application is 20. we can ofcource exceed the number and go for more in here but more you have will more overhead on performance.

Host-header Site Collection is the ideal way to achieve this point. Except few minor drawbacks, it gives excellent capability over the each site collection you can have multiple managed Paths. Even though the Site Collections sits on a single Web Application, doesn’t matter the number of Managed paths (in terms of Web Application wise) per web Application because you are dealing with a separate host-header Site Collection. I would recommend to go with Host Header Site Collections at this point.

Custom Stuff

Why Not !. having a Centralized service portal which allows users to visit and create a tenant themselves will be a handy thing just like Microsoft’s O365. having an armed super-duper backend to run the provisioning of tenants through automated scripts etc.. There’s lot more to talk on this thing so for now let me finish what I started under this topic.

 

Stay Tuned for Part 3 – 6 soon to be Published !

—————— Part 3 – Functionality Tech Preview (What It Really Gives You) ———————————-

—————— Part 4 – Deploying Core Infrastructure (Platform) ————————————————–

—————— Part 5 – Creating Partitioned Service Applications ————————————————-

—————— Part 6 – Creating Tenants and Do some real stuff ————————————————-