Hosting options for apps for SharePoint
Published: July 16, 2012
Learn about the different ways that you can host the components of apps for SharePoint.
Applies to: apps for SharePoint | Office 365 | SharePoint Foundation 2013 | SharePoint Server 2013
The SharePoint 2013 app model facilitates two broad approaches to hosting your apps for SharePoint: SharePoint-hosted and cloud-hosted. These are not exclusive categories: An app for SharePoint can have both SharePoint-hosted and remotely hosted components. Within the cloud-hosted approach there are two important subcategories: provider-hosted and autohosted. Each approach has key features you should consider when deciding how to host your apps.
Apps for SharePoint can be categorized in at least four important ways:
Where the components of the app are stored. The possibilities are:
Externally:Remote components are persisted in databases, servers, or cloud-based services, that are external to the SharePoint farm.
In SharePoint: SharePoint components, such as list templates, modules, workflows, site pages, Web Parts, and custom content types, are persisted within the SharePoint content database.
Mixed: An app can include both SharePoint and external components.
Whose hardware, or cloud service account, hosts the remote components. The possibilities are:
The developer's hardware or cloud account: The components are hosted on the developer's hardware or cloud service account.
The customer's hardware, private cloud, or Windows Azure Web Sites account: The components are hosted in a Windows Azure Web Sites account that is associated with a customer's SharePoint Online account, or in a private Windows Azure Web Sites cluster associated with the customer's SharePoint farm.
Whose logic controls the deployment of the components. The possibilities are:
Custom logic of the developer: When the developer is hosting the components of the app, the developer provides the deployment logic.
SharePoint installation logic: SharePoint components are deployed to host webs and app webs by SharePoint when a customer installs the app.
Autohosting logic: SQL Server databases and ASP.NET web applications can be deployed automatically to a Windows Azure Web Site in SharePoint Online, by using the SharePoint autohosting system. Developers need only include the appropriate Web Deploy packages and DACPACs in the app package and reference them in the app manifest.
Where the host website on which the app is to be installed is located. The possibilities are:
On premises behind a firewall
On premises without a firewall
In SharePoint Online
There are many possible combinations of these variables, but some combinations are unfeasible or unlikely, such as an app that contains only SharePoint components but is hosted by the developer. The following combinations are the most recommended and the ones that you are most likely to develop.
Cloud-hosted: Includes at least one remote component and may also include SharePoint-hosted components. Within this category are two important types of apps:
Provider-hosted: Apps whose non-SharePoint components are deployed by your—the developer's—logic and are usually hosted on your hardware or cloud account, but in some scenarios they are hosted by the customer. The SharePoint components are installed to the customer's SharePoint website, either on premises or in SharePoint Online. You are responsible for designing and enforcing a system of tenant isolation for this type of app.
Autohosted: Apps that are installed to a host web on the customer's SharePoint Online tenancy, with components automatically installed into a Windows Azure Web Site account. The Windows Azure Web Sites infrastructure manages isolation of tenancies.
SharePoint-hosted: Apps that include only SharePoint components and that are installed on the customer's own SharePoint Online tenancy or its own on-premises SharePoint farm.
Figure 1 summarizes the critical aspects of the hosting approaches. The rest of this article describes them in more detail and provides some guidance in deciding between them.
Benefit: This approach enables you to reuse common SharePoint artifacts, such as lists and Web Parts.
Provider-hosted apps for SharePoint includes components that are deployed and hosted outside of the SharePoint farm, usually by the developer, but in some scenarios by the customer. The provider-hosted app for SharePoint interacts with a SharePoint 2013 site but also uses resources and services that reside on the remote site.
Benefit: This approach enables you to use any hosting service you want.
Consideration: This option provides you with a great deal of flexibility, but it places the responsibility for creating the installation, upgrade, and uninstallation logic of the remote components on the developer.
Within the category of provider-hosted apps for SharePoint, there are important architectural differences between apps for SharePoint whose remote components will be installed outside the corporate firewall of the SharePoint farm where the app is installed and those whose remote components will be installed within that firewall. Let's look at the benefits and considerations for these two scenarios.
Provider-hosted with remote components outside the firewall
Consideration: This approach places responsibility on the development team for maintaining the remote site and for managing tenancy isolation among the customers that are using the app.
Provider-hosted with remote components inside the firewall
Benefit: This approach enables you to use any programming languages that you wish.
Benefit: This approach enables you to interact with a SharePoint 2013 site by using one of the SharePoint client object models or its REST/OData-based web service, and to use the OAuth protocol for app authentication and authorization.
Consideration: This approach places responsibility on the development team to provide a packaging and installation system for the remote components.
Autohosted apps for SharePoint are hosted on Windows Azure Web Sites, a kind of Windows Azure "lite." As with a provider-hosted app for SharePoint, an autohosted app for SharePoint interacts with a SharePoint 2013 website but also uses resources and services that reside on a remote site that is hosted by the Windows Azure Web Sites infrastructure.
The infrastructure for autohosted apps will remain in preview status for a period of time after SharePoint 2013 releases. Autohosted apps (which includes all apps that depend on Microsoft Access) will not be accepted by the Office Store during this preview phase. We will update dev.office.com with information about autohosted apps as it becomes available.
Benefit: When you deploy an autohosted app for SharePoint, all Windows Azure and Windows Azure SQL Database components are provisioned for you when the app for SharePoint is installed.
Benefit: The Windows Azure Web Sites infrastructure handles load balancing, multi-tenancy, and other important maintenance tasks for you.
Consideration: If you are using autohosting for your app, each installation of the app provisions its own Windows Azure Web Site.
See Authorization and authentication for apps in SharePoint 2013 for a description of how the OAuth standard works in SharePoint 2013.
Benefit: This approach leverages the benefits of the other two approaches.
Consideration: The more complex architecture of this sort of app for SharePoint will require careful planning about server-to-server communication and cross-site scripting restrictions.
As you can see, these approaches enable you to leverage the advantages of using both SharePoint 2013 and any hosting service that is convenient and useful to you. You can get secure access to SharePoint artifacts from code that is hosted in an isolated domain on a SharePoint 2013 website, and you can use OAuth, REST/OData web services, and the SharePoint client object model (CSOM) to get secure access to SharePoint, plus other technologies and programming languages that are available to you on a remotely hosted site. See Important aspects of the app for SharePoint architecture and development landscape and Host webs, app webs, and SharePoint components in SharePoint 2013 for more information about isolated domains and other important architectural components of apps for SharePoint.
For more information, see the following resources: