Hosting options for apps for SharePoint

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.

SharePoint-hosted apps for SharePoint are installed on a SharePoint 2013 website, called the host web, and that have their resources hosted on an isolated subsite of a host web, called the app web. This approach enables you to reuse common SharePoint artifacts, such as lists and Web Parts. When you take this approach, you can use only JavaScript and you cannot use any server-side code.

Benefit: This approach enables you to reuse common SharePoint artifacts, such as lists and Web Parts.

Consideration: You can use only JavaScript in the app, and you cannot use any server-side code.

See How to: Create a basic SharePoint-hosted app.

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: The provider-hosted app for SharePoint can be hosted on Windows Azure or any remote web platform, including non-Microsoft platforms. It interacts with SharePoint 2013 by using one of the SharePoint client object models or its REST/OData-based web service. Depending on the scenario it gains authorization to SharePoint data using either the SharePoint 2013 implementation of the OAuth standard or a JavaScript cross-domain library.

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

Provider-hosted with remote components inside the firewall

See How to: Create a basic provider-hosted app for SharePoint.

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.

Note
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 How to: Create a basic autohosted app for SharePoint.

You can also build apps that include both SharePoint-hosted and cloud-hosted components. If you choose to use this hybrid architecture, your design and approach must account for security limitations that are built into the model. Only JavaScript can be used in the code components that are hosted by the SharePoint 2013 app website, and the remotely hosted components must use valid OAuth tokens to interact with the SharePoint 2013 website. Figure 2 shows the communication methods that are available to app for SharePoint components that are hosted remotely and on a SharePoint 2013 app web.

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.

See How to: Create a cloud-hosted app that includes a custom SharePoint list and content type.

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:

• Important aspects of the app for SharePoint architecture and development landscape

• Apps for SharePoint overview

• Host webs, app webs, and SharePoint components in SharePoint 2013

• Authorization and authentication for apps in SharePoint 2013

• OAuth authentication and authorization flow for cloud-hosted apps in SharePoint 2013

• SharePoint apps vs. classic SharePoint solution

• How to: Create a basic provider-hosted app for SharePoint

• How to: Create a basic SharePoint-hosted app

• How to: Create a basic autohosted app for SharePoint

• How to: Create a cloud-hosted app that includes a custom SharePoint list and content type