What should have a fun night between friends, ended in a long and weary discussion about SharePoint 2013 Apps, Multi-Tenancy and what it all means. And to be honest, I’m still not sure whether I hold the right end of the stick. So feel free and leave any comments helping me better understand everything there is about SharePoint 2013 Apps and what they really are.
I guess (one of) the shortest answers to my question “So what is a SharePoint 2013 App?” would be something like: “A website or service that can be found by navigating to a sub website of a specific SharePoint Tenant (called the App Tenant) in your current SharePoint Tenancy”. But I’m not sure whether anyone would understand that. So let’s first try and understand what an App Tenant is. For this you need to know that a Tenant is a Site Collection in a SharePoint Farm that has been added to set of Site Collections, known as a Tenancy. And maybe at this point it also would make sense to toss in the term Multi-Tenancy that refers to the situation in which more than one Tenancy can be configured within one and the same SharePoint Farm. The beauty of Multi-Tenancy is that each Tenancy is a fully isolated set of Site Collections. Fully isolated means that each Tenancy has its own unique user base, its own unique data (but on a Content Database/Tenancy level but much more granular permitting the allocation of Site Collections to Tenancies) and its own set of unique data stored in each of the SharePoint Service Applications (that require data uniqueness in the first place). Let’s assume for now that I have not lost you.
So let’s stop and review my definition of an App briefly against the backdrop of the previous paragraph: A website or service that can be found by navigating to a sub website of a specific SharePoint Tenant (called the App Tenant) in your current SharePoint Tenancy. So does this mean that in a SharePoint 2013 (on-premise) Farm you will find a Site Collection that is a Tenant specifically for Apps? No. To understand this, we need to explore two concepts: Firstly we need to understand how SharePoint isolates data between Tenancies. Secondly, we should at least understand at a very high level how browser requests are routed to Tenants (Site Collections) in a Tenancy in a SharePoint Farm.
Ok, let’s start with a quick look at how each Tenant is registered with a Tenancy in SharePoint. This is in fact, from a a conceptual point of view, nothing really special. It’s done using the Site and Subscription Service. Think of this as some kind of labeling machine putting Tenancy specific labels on all kind of data stored in SharePoint (e.g. Site Collections in Content Databases, data in Service Application Databases, users etc.). So basically you’d start by creating a new Tenancy in your SharePoint using this very service.
Now let’s see how it’s possible to access a subset of Site Collections (Tenants) using a browser? Well, at least not by using a Web Application with a Host Header. Why not? Because this wouldn’t scale and it’s difficult to balance load. If you consider Office 365 to probably be a very large Multi-Tenancy example then it’s easy to see that creating a Web Application on a per Customer basis is very inefficient. Also the usage of Managed Paths isn’t scalable enough (due to the restricted number you can create per Web Application). And besides, it’s also insecure. Because all different Tenancies would basically be created within a single domain e.g. http://office365.microsoft.com/tenancy1, http://office365.microsoft.com/tenancy2 etc. and this would allow all kinds of cross-site scripting vulnerabilities. No, it seems to be much more efficient and secure to use Host Named Site Collections e.g. http://tenancy1.office365.microsoft.com, http://tenancy2.office365.microsoft.com etc. But wait a minute: That would reduce the number of Site Collections per Tenancy to exactly one, wouldn’t it? Because if http://tenancy1.office365.microsoft.com is a Tenant (Site Collection), it would you from creating a normal Managed Path like http://tenancy1.office365.microsoft.com/sites and then add additional Site Collections “below” the Managed Path, e.g. http://tenancy1.office365.microsoft.com/sites/sc1, http://tenancy1.office365.microsoft.com/sites/sc2, right? Wrong! New with SharePoint 2013 you can create so-called Host Named Managed Paths that do exactly that. They help virtually grouping Site Collections within or below) a single (sub) domain. Having all this in place, it’s easy to see that this would scale virtually unlimited by adding as many Web Front Servers to handle the load and as many Content Databases needed to hold all the data in all the Site Collections that make up for all the Tenancies in the Farm.
Ok, so what is the App Tenant if it’s not simply another Site Collection that has been registered with a SharePoint Tenancy? Well, exactly that! It’s a Tenant because it’s registered as such in the Site and Subscription Settings Service and it has it’s own path URL browsers to navigate to. However, the path is not pointing to the root website of a Site Collection because it was never created. It’s basically pointing into the void! But as soon as you’ll install and deploy your App, SharePoint will take the App Tenant’s URL and dynamically pre-fix it (actually, create a sub domain for it) with some abbreviations and unreadable GUID. So whatever an App is: SharePoint has made sure it will always have a URL and restricted the availability of the App to a single SharePoint Tenancy .
So what’s an App? An App is a website or web service that seems to run as if it were installed as a sub website of the App Tenant in your current Tenancy. But in reality, behind the scenes there is a lot of http re-directing, permission checking and request interception going on. Eventually requests to your App are redirected to the actual location of the website or web service that makes up for the technical implementation of your App. And here you have basically three choices: 1) a client- and serverside software that running in some cloud; either a) azure or b) some other 3rd party cloud) or 2) clientside software that runs somewhere in SharePoint. SharePoint is “simply” using its Tenancy-Infrastructure (and additional App Management functionality) on the one hand side to control (but also to ensure) that the App can access Tenancy specific data e.g. Users, Documents, List Items etc. (according to permissions granted during App deployment). On the other hand side SharePoint uses this infrastructure to know the URL of the App. And hence it can intercept all request to the App, which allows SharePoint to apply a comprehensive permission model.
Probably at this point you are wondering when you ever explicitely enabled (Multi-)Tenancy whilst installing SharePoint 2013 on-premise. Most likely you didn’t! This is because a SharePoint Tenancy is automatically created and configured for you by default if you didn’t configure Multi-Tenancy yourself. In fact, SharePoint created a so called Default Tenancy for you. And without you realizing, you’ve been adding new Tenants (Site Collections) to your (Default) Tenancy all along. Why? Because without it, you wouldn’t have been able to create the App Tenant. So without the Default Tenancy automatically configured for you, you wouldn’t be able to host Apps in your SharePoint 2013 environment; Ever! So fact is, if you like it or not, your SharePoint 2013 on-premise installation is a Tenancy. However, this doesn’t mean that you now can add more Tenancies to your Farm. In other words, Multi-Tenancy would still require manual configuration (see the last paragraph for some thoughts on this).