Introducing the SharePoint 2013 Application Model
SharePoint 2013 introduces a new mechanism for custom code deployment known as "Apps". Mostly targeted at online solutions, the purpose of the App model is to overcome the severe limitations of the 2010 isolated execution model (also known as the "Sandbox") and provide developers with a way to run rich web applications in SharePoint without negatively impacting the underlying infrastructure. Much has already been made about this new model and a lot more will be written about it over the coming year as 2013 gets released and adoption spreads. Before we get too far off the beaten track into a debate about whether or not developers should or should not be using the new App model, it’s helpful to first understand why Microsoft chose this path and what it really means for both new application developers coming onto the platform and existing developers who need to support the next release.
At its core, SharePoint has always been an application platform. While it has been possible since 2001 to create custom components for SharePoint (does anyone even remember digital dashboards?), it wasn’t until the 2003 release of Windows SharePoint Services that developers really began to take notice of the capabilities that the platform offered. In those days, custom code was pretty much confined to web parts, with some limited interaction with deeper system layers. Due to the complexities of code deployment and lifecycle management, mostly due to lack of good tooling, custom production code in SharePoint wasn’t all that common. Nevertheless, it was at this point that some real weaknesses began to appear in the structure, namely that one bit of bad code could effectively bring the system to a standstill. In most cases, this was relegated to a single page being inoperable due to a misbehaving web part but in some instances things like malfunctioning event receivers could wreak havoc throughout an entire deployment.
The release of 2007 changed everything. Suddenly, developers were coming onto the platform in droves. Although tooling was still lagging far behind other Microsoft platforms (especially ASP.NET) there were enough third-party solutions and guidance from the greater community to get people going down the right path rather quickly. SharePoint rapidly grew from a niche Intranet application and started to take on the aspects of the rich middle-tier platform it would eventually become, with a deep set of API’s that offered developers access to nearly the entire application stack. It is also when things began to go horribly wrong for many customers. In some ways, Microsoft was a victim of their own success – people were adopting the platform far faster than the company ever imagined and the support systems, in terms of training, documentation, tooling, and especially infrastructure, simply weren’t in place to accommodate the massive amount of custom development taking place. Consequently, the 2007 release, while it drove adoption to stratospheric levels, also resulted in a tsunami of support nightmares as custom code ran amok in a multitude of deployments.
For the 2010 release, Microsoft was faced with a difficult paradox. On the one hand, the capabilities of SharePoint as a development platform made it irresistibly "sticky" – the more code that went into SharePoint the more it became a critical part of technology infrastructure and business operations. On the other hand, IT departments were being overwhelmed by the negative impacts of badly written and poorly performing code on their (often very expensive) SharePoint farms. This led to what seemed an acceptable compromise – execution of code in an isolated "sandbox" process with built-in monitoring and administrative controls. As it turned out, the Sandbox was really only beneficial to administrators – the amount of restrictions required to ensure limited impact on the farm infrastructure meant that there was very little functionality available to developers from the core API’s. To bridge this gap, Microsoft also introduced the Client Object Model – a set of API’s designed to supplant the existing web services and offer remote application integration. But this, too, was overly restrictive and failed to provide sufficient depth for serious application development.
So how has Microsoft addressed these issues in SharePoint 2013? The Sandbox taught us that platform integrity is of supreme importance (which we should have realized all along) but also that developers cannot be sidelined or adoption will wane. The new approach is to give developers the capability to create whatever applications they might dream up but they will have to run outside of the core SharePoint framework. Similar to the application plug-in model used by sites like Facebook, the SharePoint 2013 model allows the execution of full-fledged applications (in whatever language the developer prefers) while sharing some portions of the SharePoint UI. It also greatly expands the capabilities of the client object model and REST-based services, giving programmers a way to interact with SharePoint data remotely. Microsoft is obviously hoping that this will satisfy both constituencies and lead to renewed focus around creating rich applications that tie into SharePoint.
In order to understand the application model architecture, it is important to first get a grasp on the new terminology changes. In 2013, just about everything is called an app – lists, libraries, templates, custom components, and so on. The App Model, on the other hand, defines a particular type of deployment. There are three primary ways in which code can be deployed on-premise in 2013 – traditional full trust, the Sandbox, or the App Model. In the cloud, the full trust model is still off limits – only the Sandbox and App Model can be used. It is important to note that the Sandbox really only exists for backwards compatibility – it should not be considered as a valid deployment type for new applications.
Figure 1 – SharePoint 2013 Custom Code Deployment Types
The Full Trust model will continue to offer the greatest API depth and flexibility for on-premise applications. Essentially, nothing has really changed in 2013 for these types of solutions; however, customers should carefully consider whether or not their solutions really need the extensive platform integration of a Full Trust solution running inside of SharePoint or if an app running on a remote web server and only sharing the basic SharePoint chrome is more applicable. This is an important decision point. In the past, customers who adopted SharePoint as their intranet platform had to incur the costs of rewriting and migrating existing applications to run on the platform. This cost could be quite high, especially if they had no in-house development expertise or existing staff did not have any .NET or SharePoint training. There simply wasn’t any good way to preserve existing knowledge and code while running applications side-by-side with SharePoint that offered a decent level of interoperability.
The primary decision point for on-premise applications will be the capabilities of the client object model and REST services. Although greatly enhanced from 2010, they still only offer a subset of the full server object model functionality. Many higher-level API’s, especially those related to enterprise features, are simply not available to remote applications. And, perhaps even more importantly in the long run, app deployment on-premise is not a streamlined process. The pure simplicity of WSP deployment, even in a restricted Sandbox environment, has been supplanted by registrations, permission grants, catalogs, certificate authorization, metadata documents, app principals and token services. For non-Windows authorization methods, such as OAuth, there will also be Azure Connect to deal with and two-way authorization and data exchange through the firewall. Whether or not these are acceptable trade-offs for guaranteed operational stability will have to be determined by each individual customer.
For those who choose to adopt SharePoint online, there really isn’t much of a choice – the app model is how cloud functionality will be extended going forward. The same considerations for client object model and REST functionality apply but at least the OAuth and ACS pieces are already taken care of in Office 365. If CSOM + REST are insufficient then the customer will need to consider an on-prem deployment with full trust solutions or possibly even a hybrid implementation with some sites on O365 and some on-premise. The good news is that it’s fairly simple to preserve an app across the various deployment methods once it has been built. Solutions aren’t 100% portable but they come pretty close and can even be deployed to Azure with a little additional effort.
Figure 2 – SharePoint 2013 App Hosting
Which type of hosting to choose depends upon the purpose of the application, the type of deployment model and the authentication/authorization requirements. If the solution contains only classic SharePoint elements then no hosting is necessary and the app can be deployed directly in the target web. If the app has a simple, compact user interface and really only needs to retrieve data from an external resource (much the same as a classic web part) then an app part may be most applicable. A more complex, full-screen UI that can be contained within a single page and exchanges data with a remote resource may be a good fit for an app web. A full-on web application that needs maximum screen real estate and performs extensive data operations outside of SharePoint, or which has to support extensive multi-tenancy, is better suited to a provider-hosted app. There are, of course, many cases where the lines may be blurred or any of the hosting models will work, in which case the customer will need to dig deeper into the feature requirements to make a decision. An overriding concern will be authorization – if the app uses an authentication method other than Windows and is on-premise, it will require an internal OAuth implementation, which has a number of ramifications. This consideration alone may dictate the hosting model in many organizations.
The conversation will also continue around the capabilities of the client object model. It is more extensive than in 2010 but by no means does it offer parity with the server object model. The REST services, while much improved, are also not on par with legacy web services and they don’t offer a good solution for large data sets. And the implications of all the additional web traffic, much of it large blocks of JSON and XML, can’t be overlooked from an infrastructure perspective. As with the Sandbox, API limitations may cause some reluctance to adopt the new model but it will likely be the additional overhead of configuring and deploying apps internally that will push on-premise customers back to full trust solutions despite the platform stability concerns.
With regards to cloud solutions, it really comes down to a question of delivering a full or partial user interface, along with considerations of data access and transport. App parts will likely be popular where standalone web parts have traditionally been applicable or where external data was required that the Sandbox wouldn’t allow. The app web or remote web picture is less clear. There are cases for both, although the separate subweb concept will take some getting used to and just may not work for certain solutions. Full remote webs will require a complete ground-up rewrite to handle token authorization, chrome display and data transfer – it may be more applicable to retrofit existing apps for partial rendering in app webs and write new applications as remote webs.
What is certain is that SharePoint solution design and deployment has gotten a bit more complex in 2013. While we have gained some clarity around the online model we’ve also introduced some confusion for on-premise customers. Gone are the restrictions and limitations of the Sandbox, with its inscrutable points system and heavy-handed penalties for excessive resource consumption, replaced by a set of options that essentially drive customers to one extreme or the other. In 2013, code is either on the server or it’s not and there isn’t much middle ground. Only time will tell which path developers adopt and whether or not the app model strategy will pay off in terms of increased adoption and solution availability. One big advantage should be the ease with which developers with no previous SharePoint experience can adapt their solutions to work in a SharePoint context – that alone could potentially drive adoption in ways the Sandbox never could. The real question will be if, and to what extent, existing SharePoint developers embrace the new model. As with anything SharePoint, the answer is most likely "it depends", although what, exactly, it depends upon will likely be quite different this time around.