Sharepoint 2013 : Understanding SharePoint app model architecture (part 3) - Understanding app hosting models

4. Understanding app hosting models

The SharePoint app model actually defines three app hosting models, not just two. Any time you create a new SharePoint app project in Microsoft Visual Studio 2012 you must pick from one of the following three app hosting models.

A SharePoint-hosted app is simply an app that adds its start page and all its other resources into the SharePoint host environment during installation. Now, it’s time to explain the differences between the other two app hosting models.

A provider-hosted app and an autohosted app are just two variations of the hosting model for a cloud-hosted app. Both types of apps have an associated remote web that is capable of hosting the app’s start page and any other resources the app requires. Furthermore, both provider-hosted apps and autohosted apps can and often will host their own custom databases to store app-specific data. The difference between these two different app hosting models involves how the remote web and its associated database are created when an app is deployed and installed.

It makes sense to begin by first examining the hosting model for a provider-hosted app. Imagine a scenario in which a developer has just finished testing and debugging a provider-hosted app that has a remote web with its own custom database. Before the app can be installed in a SharePoint host environment, the developer or some other party must first deploy the website for the remote web to make it accessible across the Internet or on a private network.

The custom database used by the remote web must also be created on a database server and made accessible to the remote web as part of the deployment process. Once the remote web and its custom database are up and running, the provider-hosted app can then be installed in a SharePoint tenancy and made available to the customer’s users, as demonstrated in Figure 3.

Figure 3. Provider-hosted apps are deployed in their own infrastructure including any required databases.

Once a provider-hosted app has been deployed, the company that developed the app usually assumes the responsibility for its ongoing maintenance. For example, if a company develops a provider-hosted app and deploys its remote web on one or more of its local web servers, it must ensure that those web servers remain healthy and accessible. If it deploys the remote app for its provider-hosted in a hosting environment such as Windows Azure, it must pay a monthly fee for the hosting services. Furthermore, it will be responsible for backing up the app’s database and then restoring it if data becomes lost or corrupt.

Keep in mind that a provider-hosted app can be installed in more than one SharePoint site. Furthermore, a provider-hosted app can be installed in many different SharePoint sites that span across multiple customers and multiple SharePoint host environments. This is a common scenario which is known as multi-tenancy. What is critical to acknowledge is that multi-tenancy introduces several noteworthy design issues and deployment concerns. Let’s look at an example.

Think about a scenario involving multi-tenancy in which a provider-hosted app has been installed by many different customers and the number of users is continually growing larger. All these users will be accessing the same remote web through a single entry point, which is the app’s start page, as shown in Figure 4.

Figure 4. A provider-hosted app in a multi-tenant environment must be designed to scale and to isolate data on a customer-by-customer basis.

As you can imagine, a provider-hosted app in this type of multitenant scenario must have a way to scale up as the number of users increases. Furthermore, this type of app should generally be designed to isolate the data for each customer to keep it separate from the data belonging to other customers—you would never want one customer accessing another customer’s data. Depending on the customers’ industry, there could even be government regulations or privacy concerns that prevent the app from storing data for different customers within the same set of tables or even within the same database.

The important takeaway is that multi-tenancy introduces complexity. The development of a provider-hosted app that will be used in a multi-tenant scenario typically requires a design that isolates data on a customer-by-customer basis. As you can imagine, this increases both the time and the cost associated with developing a provider-hosted app.

Now that you have seen some of the inherit design issues that arise due to multi-tenancy, you will be able to more fully appreciate the benefits of the hosting model for autohosted apps. Autohosted apps offer value because they prevent the developer from having to worry about many of the issues involved with app deployment, scalability, and data isolation.

The first thing to understand about autohosted apps is that they are only supported in the Office 365 environment. Although this constraint might change in future releases, with SharePoint 2013 you cannot install an autohosted app in an on-premises farm. The reason for this is that the hosting model for autohosted apps is based on a private infrastructure that integrates the Office 365 environment with Windows Azure and its ability to provision websites and databases on demand.

The central idea behind the hosting model for autohosted apps is that the Office 365 environment can deploy the remote web on demand when an app is installed. You can also configure an autohosted app so that it creates its own private database during app installation. Once again, the Office 365 environment and its integration with Windows Azure is able to create a SQL Azure database on demand and then make it accessible to the remote web.

Autohosted apps offer value over provider-hosted apps because the Office 365 environment transparently handles the deployment of the remote web and potentially the creation of a custom database, as well. Autohosted apps also transfer the ongoing cost of ownership of the remote web and its database from the developer over to the customer who owns the Office 365 tenancy where the app has been installed. Therefore, the app developer doesn’t have to worry about babysitting web servers, backing up databases, or coming up with a strategy scaling up the remote web as the number of users increases.

The benefits of an autohosted app over a provider-hosted app also extend into app design, which can serve to lower development costs. That’s because each customer receives its own private database whenever installing an autohosted app, as illustrated in Figure 5. The benefit is that the developer isn’t required to add complexity to the app’s design and implementation to provide isolation because each customer’s data is isolated automatically.

Figure 5. An autohosted app creates the required remote web and any databases automatically during deployment.