A Perspective on SharePoint 2013's App Model - Part 1

  • Article

A lot of my customers lately to the Microsoft Technology Center have been interested in the new App Model of SharePoint 2013. This should not be a surprise given that the new App Model is one of the big additions to SharePoint 2013. What is interesting is that these customers are not going to the cloud any time soon and see SharePoint as an on-premises enterprise service. Most of the material out there on the new App Model emphasizes Office 365 and Auto Hosted solutions where the remote web is running in Azure. I thought I would start this series of blogs posts with why the App Model is something you should consider in an on-prem deployment.

Product or Platform?

Over SharePoint's history, it has struggled with the product or platform question. Ultimately, SharePoint provides a lot of out of the box functionality that enterprises are looking to deploy. Things like content management, search, workflows, business intelligence, etc are all quite functional out-of-the-box with some configuration. This would be the product side of the equation. However, ever since SharePoint was based on the .NET framework (SPS 2003) developers have been looking to extend it. This shouldn't surprise anyone either since for a good quantity of line of business applications, SharePoint is an 80% solution. Developers and enterprises both see it as a platform that if they build on will shorten the development lifecycle substantially since they only have to build the 20% that is specific to their application. Enter event receivers, custom web parts, application pages, custom workflows, etc.

The problem comes when these SharePoint applications are deployed to production and are now the responsibility of IT to maintain. Focused on keeping the lights on, this group is change adverse. Any custom code deployed onto the SharePoint servers complicates things. Does it change the way they do backup and recovery? How well was the code written and will it bring down the farm? Does it change the capacity planning activities that were done for out-of-the-box functionality? For these reasons there is a struggle as to how to effectively support these types of applications that are built leveraging SharePoint.

Build On or Build Alongside?

It is important to realize how developers have usually built SharePoint applications in the past, some of the fundamental problems with the model and why things are changing so drastically with SharePoint 2013. Prior to SharePoint 2013, developers looked at SharePoint and saw it almost like a stack of lego blocks they can use to build an application. Things like lists, libraries, versioning, search, calendars, workflows, etc were all pieces to lay the foundation for their application. To build the whole "solution", developers would build custom components that when deployed to the SharePoint server, fill the gap. These were things like custom web parts, event receivers, custom code workflows, application pages, and so forth. The end result was that SharePoint + the Customizations = The Solution. I have coined describing this as the "Build On" solution. See this rough picture:

What is the problem of this model? It is the model that all prior SharePoint development likely used and even most of the SharePoint developer training teaches. The problem is that the customizations are literally extending the product on the SharePoint server. Once this has been done, all bets are off in terms of performance. It could complicate your IT staff's ability to meet their service level agreements. And remember this was done to keep cost low - however, now every time you "upgrade" SharePoint, you have to retest all of this additional work. You got a big bang up front, but are paying later when it comes to moving to new releases. This is the most costly part of upgrade/migration conversations I have had with customers.

Enter SharePoint 2013 and its new App Model. Before we get started, it is worth noting that using the App Model on-premises is an option. You can still continue to Build On SharePoint, but you are still subject to the disadvantages of that model. The new App Model changes the game considerably with a fundamental rule change. Thou shall not put custom server-side code on a SharePoint server. SharePoint can still be used as an application platform, but we are going to keep the farm's servers from being burdened with running your customizations and require you to host them somewhere else. Where you say? Anywhere you want (Azure, another web server, etc). In fact this separation of the out-of-the box SharePoint product functionality and your customizations opens up tons of benefits. First the obvious ones:

  • Your app won't have compiled code on the server complicating the hosting and management of the SharePoint farm
  • You can separate responsibility for hosting the SharePoint enterprise service and the line of business app functionality
  • Your developers don't have to be as SharePoint savvy since they will just interface through client side object models, javascript, rest end points, etc.
  • In fact developers could use even non-Microsoft tools and languages to build the remote functionality
  • Lastly, it drastically reduces the upgrade hurdle since it is easier to keep interfaces backward compatible (you are not strongly coupled to SharePoint's server assemblies)

I have coined the term "Build Alongside" as the way to describe this model. Basically SharePoint + your Customizations = Solution still applies. However, we separate the customizations from the product. Now in order for this to work and work well, SharePoint 2013's support for remote code to interact with it has been vastly improved over the prior versions. We get client side object models (CSOM) for javascript and .NET managed code. We also get lots of REST endpoints, ODATA feeds, and OAUTH for application level authentication. All built on industry standards so as to open up this development model to more developers.

 

History of SharePoint Development Models 

 If you are new to this, hopefully at this point I have you scratching your head. You might be wondering how this fits into the developer methods you already know. So let dive in a bit to clear things up... If you were familiar with SharePoint 2010, I'd argue that your development efforts probably fell into one of these three buckets:

  • Visual Studio customizations whose code ran on the SharePoint server inside the IIS worker process
  • Often deployed to the GAC on SharePoint’s WFE. Required Admin
  • Unlimited trust model. Access to SharePoint server-side OM
  • Usually unmonitored
  • Wide availability – Feature shows up everywhere at the appropriate scope
  • Poor clean up if uninstalled
  • Solution upgrade, maintenance required additional coding or scripting
  • Increases ramp to upgrading product version

  • Visual Studio customizations whose code ran within the a User Code service
  • Deployed by a site collection admin uploading the wsp to a site collection’s Solution Gallery
  • Partial trust model. Limited access to the SharePoint server-side OM.
  • Support for proxies to widen the trust model often resulted in the “expensive” operations being fully trusted.
  • Monitored by the farm using resource counters
  • Difficult to distribute widely and track usage
  • Poor cleanup if uninstalled
  • Solution upgrade, maintenance required additional coding or scripting
 
 
  • Content that contained code which ran client side in the user’s browser
  • Silverlight, JQuery, JavaScript, etc
  • No trust model. No access to the SharePoint server-side OM.
  • Leveraged Client Side OM, Web Services, ODATA, RSS, REST, browser’s DOM
  • Could be deployed by user with little admin rights
  • Not monitored
  • Difficult to distribute widely and track usage
  • Solution upgrade often meant manual adjustments

Now in SharePoint 2013, each of these techniques still exist. However, with the additional of the App Model things change a bit. First, farm trusted solutions become something only for adding administrative extensions, not user applications. The Sandbox service is still there, however mostly for backward compatibility. The new App Model supersedes it. It has the same goals of isolation and monitoring but a lot less limiting in what developers can do when using the model. And lastly, the client side option is wrapped into the App Model as well. These would be applications where there is no remote component (called SharePoint Hosted Applications). These apps only have SharePoint out-of-the-box functionality, SharePoint pages, and javascript. So redoing the above table for SharePoint 2013 turns into this:

 

  • No longer recommended for extensions that are primarily used by end-users
  • Should be used for customization of administrative functions (timer jobs, PowerShell, central admin)
  • No longer support being deployed with Custom Access Security Policies

  • Deprecated in SharePoint 2013 Preview
  • Service remains primarily for backward-compatibility
  • The goals of this model along with many improvements have been incorporated into the new SharePoint Apps model
 
 
  • Formalized into the new SharePoint Apps model.

That's it for now. I plan a part two where I go into more detail on the types of apps in SharePoint 2013's App Model and how to change your thought patterns of what it is you need to build for that last 20%. Possibly another post where I give some advice for those of you who are trying to build this on-premises. And possibly some web demos. Let me know what you think in the comments and what direction I should take for the future parts.