Introduction

Microsoft SharePoint has long been offered as a customizable, extensible enterprise solution. For many users, SharePoint is their main platform for custom application development. In my opinion, this is one of the greatest strengths of the product.
The customization story has changed with every major release of the product. We've gone from template manipulation to managed code solutions, to the Sandbox and Client Object Model, to the advent of Apps for SharePoint in 2013. This evolution marks an attempt to respond to challenges associated with balancing reliability of a standalone product with the need for that product to be customizable and extensible.
In this article, I will give my professional assessment of the suitability for use of the 2013 App Model. My assessment is based on my use of the App Model since the preview versions of SharePoint 2013 were released.


Background: What is the App Model?


SharePoint 2013 allows you to integrate managed code in two main ways:

1) by deploying code directly into the SharePoint farm (most common model used in 2007 and 2010),

2) by building Apps that run as standalone solutions and are loosely integrated with SharePoint.

The integration of Apps occurs by registering the App with SharePoint (via a manifest file) that tells SharePoint how to locate the app and when/where it can be used. They run in different application domains (depending on how they are hosted), and interact with SharePoint through web or service calls. Apps are treated like Features in SharePoint, and can be added directly to pages in some cases. In the most basic case, when you browse to a SharePoint page that contains an app, SharePoint makes a request to the App's server, which then responds with some HTML to add to the page or wrap in an iframe.

This concept is somewhat similar to Sandboxed solutions and the Client Object Model. One of the differences with the App Model though is that Microsoft has been pushing it as the primary approach for custom development, and has published guidance saying that developers should default to apps and only go to other approaches when absolutely necessary. Should you follow this "App First" guidance?


Should you Build Apps:

The short answer is that while this model is great for the cloud, I rarely recommend it for on premises deployments.

Apps make perfect sense for situations in which SharePoint is being consumed as a service, and/or hosted by a provider. In these cases, we cannot reasonably expect to be able to put our custom code on those servers. The App Model is a great compromise that allows for customization of a hosted software solution. If you do not have an on premises installation, I definitely support use of the App Model.

For on premises deployments though, the App Model is not only unnecessary, but the complications that arise from its use can actually be detrimental to business objectives. In the following sections I will explain the challenges with the App Model and why I don't think that its stated benefits outweigh the costs for on premises installations.


The Challenges:


Below I will touch on a few of the most prominent challenges associated with the App Model. These are just the top few that I have experienced.

Security: This is the top challenge faced when implementing apps. The decoupling of apps from SharePoint comes at the price of not being able to easily share identity. In most cases, app code will want to know who the user is and what they are allowed to do. To provide this (at least in some hosting scenarios), the App Model relies on an OAuth implementation to pass identity. While OAuth is an accepted industry standard for this practice, it is inherently complex and difficult to implement, especially in "double hop" scenarios. This will add significant cost to solution development, and, if your developers do not understand the intricacies of OAuth, it may open up security vulnerabilities.

Backup and Restore: I am not impressed with the story on backup and restore. The issue is that because Apps are separated from SharePoint, their backup and restore paths are also separate, i.e. you will not manage them from the B/R utilities that SharePoint provides. In most cases, you treat your entire SharePoint environment as a single solution, and so piecemeal restoration is not considered adequate. You want to restore the entire system from the same point at the same time. To do this with the App Model, you need to customize your backup/restore processes to include the Apps. This is certainly possible, and not even all that difficult to implement, but it is challenging to maintain and makes B/R more complex then it should be.

Consistency/Integration: Because apps are separate entities, they are not fully integrated with SharePoint. SharePoint will know where your apps live, and give you some level of management via Site Settings and Admin screens. But, apps do not work like custom layouts pages or web parts developed using server side code and deployment. These artifacts are embedded into SharePoint, they adopt the look and feel, and are easily navigable using normal means. Apps live in entirely separate domains Your options for integration are to have SharePoint redirect the user to the App, or, to expose your App UI via an iframe in SharePoint. Note that in the latter case, SharePoint provides an App Viewer web part for this purpose, which essentially handles loading the app content into the iframe.
In the first case, you are going to a completely different site, so it won't have the same look and feel as SharePoint does. Yes, you can have your App use a modified copy of the SharePoint master page and css files. But, that adds a large maintenance burden for keeping them all in sync. Plus, it doesn't account for situations where users change the theme on the SharePoint side. Additionally, your app will not have the same top and left navigation bars that uses typically rely upon. Exposing the app through an iframe accounts for these issues, but introduces complexity in implementation. For example, if an app contains complex interactions with the user (forms, dynamic views, etc.) then your app must try to take into account not only its state, but the state of the SharePoint page as well. This is challenging and costly to say the least.


Is it worth the price?

So in reality everything is a cost benefit decision. So the question is, are the above costs outweighted by the benefits? For on premises deployments, I do not think so. Let me cover a few here:

Protection of the SharePoint Servers: The most commonly cited benefit of the App Model is that your SharePoint farms will be kept "pure" and will be less likely to have issues than if you deploy custom code. I'm not going to argue that custom code has not been the culprit for countless farm crashes. We all know it has. But I don't think that moving code to the side is a solution. For one, we know that users are not going to differentiate between an App and SharePoint itself. Can you imagine an end user calling the Help Desk and saying: "While SharePoint itself is functioning flawlessly, there seems to be an issue with loosely coupled application that is being exposed through SharePoint.." No. Users regard the entire platform as the solution, so if one part is down, the platform is down. Since bad code will fail regardless of where it is hosted, having Apps on separate app domains doesn't solve for failure. And, if I may step onto my soapbox for a moment, I feel that we should fundamentally reject the idea that the solution to a problem is to move it to the side instead of solving the root cause- which in this case is developers not writing code to standard. But that's a separate topic.

Offloading Server Resources: SharePoint is indeed a resource hog, so keeping applications off of its servers is a good thing. However, this will not necessarily lead to improved performance, because now we have to deal with the overhead in communicating with the external servers. SharePoint needs to call the App server to load, which in turn may need to round trip again to get security or data, and then send its response back to SharePoint. Your best bet for performance is to have well written code running on the same servers, and ensuring that those servers are properly spec'd to manage the load of SharePoint plus Apps.

Promoting Code Reuse: A stated benefit of this model is that apps hosted outside of SharePoint can be accessed and reused by non-SharePoint platforms. While this statement is completely accurate, it just does not apply very often. In the rare cases where both SharePoint and, say, PeopleSoft, need access to the exact same app, then I will recommend looking at the App Model (but also consider a shared web service consumed by both clients).

Conclusion:


In reality, I have a hard time telling my clients that they should take an "App First" approach to customizing on premises SharePoint deployments. Rarely does the cost benefit analysis work out in favor of apps. This is not a criticism of SharePoint though. I love SharePoint, and think it's a great product. This is not even a criticism of the App Model. Architecturally, it's a sound approach to achieving the goals of allowing customization without interference. This is just a disagreement that with Microsoft's recommendations to default to the App Model for all custom development. Maybe with some improvements I will be onboard in the next release. Until then, I recommend continuing to build full solutions. Just make sure that your solutions don't bring down the farm in the meantime.