SharePoint Dragons

Nikander & Margriet on SharePoint

SharePoint 2013: What to do? Farm solution vs Sandbox vs App

Time changes perspective on things. After the release of each new version of SharePoint, we look forward to find out via blogs, wikis, books, podcasts and what have you, what was fundamentally wrong with the previous version. One thing we did not anticipate was the premature end of the tale of the sandbox solution. Apparently, sandboxed solutions are deprecated in SharePoint 2013. Let’s recap for a moment, shall we?

For SharePoint 2010, the SharePoint team introduced an elaborate architecture model for hosting sandboxed solutions, which was provided to offer an attractive alternative to farm solutions. Farm solutions are deployed to the GAC or web app bin folder, and have the potential to destabilize the SharePoint farm. They require IT pros to have a working knowledge of Code Access Security (CAS) if you want to limit and/or understand the capabilities of a farm solution. In real life, this proved to be a challenge.

Sandboxed solutions changed all that. The sandbox is a separate process in which SharePoint solutions (so called sandboxed solutions) run in isolation in the User Code Service, running under a very strict CAS policy that, however, does allow you to make service calls on the client side or full trust proxy calls on the server side.  To top it all, there was a sandbox resource limitation mechanism, that allowed IT pros to specify resource throttling settings to prevent sandbox solutions from over expanding server resources. All of a sudden, sandboxed solutions suddenly became so important that almost every authoritative resource gave advice that dictated clearly that you should always develop sandboxed solutions unless forced otherwise. This was probably the most recommended development best practice for SharePoint 2010, and it was logical and sound advice. Or was it?

There’s a new kid in town, the App model. SharePoint Apps can be hosted in an isolated SharePoint site, or separate from the SharePoint farm, either on a dedicated self-hosted application server or in the cloud (Azure). SharePoint Apps then have to leverage the extended and improved client object model to connect back to the SharePoint farm if they want to do some work there (SharePoint server-side code is not allowed/possible for Apps). The major advantages of SharePoint apps are twofold:

  1. A separated app in itself doesn’t affect the performance of the SharePoint farm in any way, and doesn’t have to be managed from within the SharePoint farm. Having said that, do keep in mind that apps leveraging the SharePoint client object model of course impact SharePoint farm performance in an indirect way.
  2. As a developer/software company, you can distribute apps via the MS App Store which greatly facilitates finding an audience to redistribute your mind works, potentially making money doing that. Note: don’t get overexcited by this, estimates state that the average iPad app generates a revenue of $700, while typical development costs range between $20.000 and $30.000. Our advice is: keep it real, the only company which is sure to make money in these scenarios is the company owning the app store. Making money by selling software is actually hard work and takes considerable investments.

The new development best practice is to build SharePoint apps in situations where earlier, you would have chosen to build a sandboxed solution. Remarkably, some earlier advocates of sandboxed solutions have switched views 180 degrees, now claiming that sandboxed solutions obviously were useless from the beginning, since they were not allowed to do anything. That’s quite unfair. Probably, a more correct way of putting it, is that nowadays Microsoft feels that whatever you did with sandboxed solutions can also be done, in a better way, via SharePoint Apps.

When we first learned about SharePoint Apps, they seemed like a logical extension to the existing development options. The fact that sandboxed solutions are now deprecated, surprised us, nevertheless, it’s interesting to do a comparison. It’s still a bit early in the game, as SharePoint 2013 has yet to be released, so this overview is bound to undergo some changes. Check out this Wiki page for recent updates: http://social.technet.microsoft.com/wiki/contents/articles/13373.sharepoint-2013-what-to-do-farm-solution-vs-sandbox-vs-app.aspx . But for now, here goes:

Sandbox Apps Farm
When to use Deprecated. Therefore, it’s unadvisable to build new sandboxed solutions. Best practice. Create apps whenever you can. Create farm solutions when you can’t do it in an app. See http://www.learningsharepoint.com/2012/07/20/sharepoint-2013-apps-vs-farm-solutions/  for more info.
Server-side code Runs under a strict CAS policy and is limited in what it can do. No SharePoint server-code. When apps are hosted in an isolated SharePoint site, no server-code whatsoever is allowed. Can run full trust code or run under fine grained custom CAS policies.
Resource throttling Run under an advanced resource management system that allows resource point allocation and automatic shutdown for troublesome solutions. Apps run isolated from a SharePoint farm, but can have an indirect impact by leveraging the client object model. Can impact SharePoint server-farm stability directly.
Runs cross-domain No, and there’s no need to since code runs within the SharePoint farm. Yes, which provides a very interesting way to distribute server loads. No, and there’s no need to since code runs within the SharePoint farm.
Efficiency/Performance Runs on the server farm, but in a dedicated isolated process. The sandbox architecture provides overhead. Apps hosted on separate app servers (even cross-domain) or in the cloud may cause considerable overhead. Very efficient.
Safety Very safe. Apps rely on OAuth 2.0. The OAuth 2.0 standard is surrounded by some controversy (for example, check out what OAuth lead author Eran Hammer has to say about it here: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ .  In fact, some SharePoint experts have gone on the record stating that security for Apps will become a big problem. We’ll just have to wait and see how this turns out. Can be very safe, but this requires
Should IT pros worry over it? Due the the limited CAS permissions and resource throttling system, IT pros don’t have to worry. Apps are able to do a lot via the client OM. There are some uncertainties concerning the safety of an App running on a page with other Apps. For now, this seems to be the most worry-able option, but we’ll have to see how this plays out. Definitely. This type of solutions run on the SharePoint farm itself and therefore can have a profound impact.
Manageability Easy to manage within the SharePoint farm. Can be managed on a dedicated environment without SharePoint. Dedicated app admins can take care of this. Easy to manage within the SharePoint farm.
Cloud support Yes Yes, also support for App MarketPlace. No, on-premises only.
About these ads

2 responses to “SharePoint 2013: What to do? Farm solution vs Sandbox vs App

  1. Slowcoach April 3, 2013 at 12:48 pm

    Cloud support – why does App say NO?????? That’s the whole purpose of Apps!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 630 other followers

%d bloggers like this: