Modern Applications and the Maturing of Microsoft SharePoint

This is a summary of a more detailed article on Bob German’s VantagePoint blog.

In its youth, Microsoft (like other microcomputer software vendors of the time) thought little about isolating applications and controlling what they could do. Applications under Microsoft’s MS-DOS and early versions of Windows (as well as early versions of Apple’s Mac OS) could take over any part of the system and could interact with other applications as they wished. There were no rules in the playground.

 In the early days, Microsoft operating systems didn’t isolate
applications from the operating system. Most SharePoint
solutions are still like this.

By and large, SharePoint is still like this. An application or SharePoint “farm solution” can pretty much do as it pleases, and developers need to follow best practices carefully in order to avoid destabilizing the system. This is still true with SharePoint 2013 farm solutions, which is still the dominant approach to SharePoint development today.

Many a SharePoint administrator has held his or her breath when installing a new application, wondering if they’ll be spending the night restoring backups after it destroys their entire installation. One of my clients had a poorly written web part that would slow down their whole Intranet, and others have had to restart their web servers nightly due to memory leaks. If the damage is delayed, it can be really hard to figure out which customization was the miscreant. Hosted SharePoint services such as Office 365 won’t even run this kind of solution due to the risks and unbridled access they allow.

Meanwhile, the mobile phone industry figured out how to reign in applications with stricter isolation and limits on what they can do; these same principles are also present in the new Windows 8 App model, which we’ve done a lot of work with at BlueMetal Architects. These applications share certain attributes, including:

  • Complete isolation of applications so they can’t overstep their bounds or destabilize the system
  • Central distribution of applications so we can vet their quality (and, in some cases, boost profits by limiting distribution channels to a single “app store”)
  • Users and system administrators can effectively control what applications can do when they’re installed
  • The system can completely clean up after applications when they’re removed, rather than leaving this up the application developer, to ensure they don’t leave data or configuration changes behind

These factors result in a new level of reliability and simplicity. Applications rarely interact badly or destabilize the system, and when a user wants an application to go away, it doesn’t leave a mess behind. The new SharePoint 2013 app model provides this using three major strategies (these are described in greater detail in the full posting):

  1. App integration is provided in the browser, rather than in SharePoint. SharePoint uses IFrames to insert the app on a page, which means the app is running on a separate web page that’s showing in a rectangle on the screen. That separate web page is hosted in an isolated web site in SharePoint or elsewhere, and the web browser’s built-in security prevents the app from reaching over to the SharePoint site and web page directly.
  2. Apps are given limited trust. When an app is installed, the user is asked what permissions it should be granted (just as with many mobile operating systems.) Then SharePoint enforces access control based on the application’s identity, not just the user’s.
  3. Applications store their content in an isolated area which is provided as a separate SharePoint site. When the application is removed, the site is deleted, and all the app’s content goes with it.

To make this work, all app code must run either in the web browser, or on a web server outside of SharePoint. This is a serious limitation; web browser Javascript code can only go so far (but its limits are extended every day!), and setting up a place to host an external, non-SharePoint site is not always straightforward.


The new app model isolates apps, and contains their content
for easy and automated clean-up

While the new app model seems promising on the surface, it’s off to a slow start and has quite a number of “version 1” limitations, such as:

  • Unless you have somewhere to host an external web site, apps are limited to running in the web browser. So-called “auto-hosted” apps are only available in Office 365, yet as of this writing can’t be sold in the public app store [http://msdn.microsoft.com/en-us/library/jj938162.aspx].
  • Apps can’t modify the way SharePoint sites are presented; for example their script can’t interact with a regular SharePoint page, and they can’t brand a site or update its look with browser script.
  • Apps can’t access several anything in SharePoint unless it has a client API that’s aware of app permissions; this leaves out many administrative functions, the ability to add new kinds of fields, and even some new SharePoint 2013 features such as the design manager.
  • Apps can’t automatically be provisioned into new SharePoint sites when they are created, and are not included in site templates. So if you want an app in every project site, you’ll be adding it – and updating it – one site at a time.
  • For ISV’s, there is no way to charge a subscription for an app, or to push out updates.

To its credit, Microsoft has added a flotilla of new client API’s to support the app model (or other client-side development), so it’s chipping away at the task. It’s like going from Windows 95 to Windows 8… it’s not going to happen overnight, but it’s worth it. Microsoft might want to turn off traditional farm solutions, but is unlikely to do so any time soon.

So what’s an IT shop to do? Will Microsoft continue to invest in the new app model, or will this go the way of “sandboxed solutions”, which were Microsoft’s previous attempt to solve the problem that has been deprecated.

The answer is start moving toward the new model where possible, and fall back to the old way as necessary. Start each project as if you’re Office 365, and see if there are options for solving your problem without resorting to old-school farm solutions. Even if your implementation is entirely on premises, start to think as if you might be going to Office 365 someday. Select 3rd party applications that run on Office 365, and start writing your own solutions to run outside of SharePoint, ideally in Javascript in the browser, sticking with the services that are provided in Office 365.

You can do this even without upgrading to SharePoint 2013!  SharePoint 2010 provided enough services – especially when supplemented with client libraries such as SPServices – that you can start developing code that is much closer to the app model without waiting for SharePoint 2013.

The reason for this isn’t so much that you’ll have to go to Office 365; as much as Microsoft wants us to go there, I expect we’ll see many options for hosting SharePoint, including on premises, for a long time. The reason is because over time you should strive to make your on-premises hosting more like Office 365, for the same reasons that Microsoft hosts SharePoint that way:

  • The application isolation and clean-up make SharePoint more stable and easier to manage
  • Application distribution is controlled centrally, and users can install apps without IT assistance
  • Isolated apps make it easier to upgrade SharePoint; you don’t have to worry as much about how apps interact with the platform if they’re only accessing web services and not actually running on the server
  • The more granular permission model is more secure; there are limits on what a rogue app could do, and apps are never omnipotent

I’ll have a couple of different takes on how to do this at upcoming conferences. I’ll introduce the concepts next month at SPTechCon Boston 2013  and dive even deeper at SharePoint Connections in Las Vegas this fall. Both sessions will include demonstrations of how to develop solutions for SharePoint 2010 or 2013 which can easily be ported to the new app model. Following these practices, you can start preparing to adopt the new app model when you’re ready to, regardless of your hosting environment.

By moving toward the new model, you’ll receive the benefits of stability and manageability gradually over time, and will open up more flexible hosting options for the future.