SharePoint Dragons

Without getting into much detail,  there are several host models for Apps in SharePoint 2013, namely:

• No-hosted
• SharePoint-hosted
• Provider-hosted

Again, without getting into details, provider-hosted Apps can be hosted on dedicated application servers or in the cloud (Azure). We want to take a moment to reflect on the provider-hosted Apps on dedicated application servers… Those Apps are stand-alone applications that run completely outside of your SharePoint farm, and SharePoint is completely technology-agnostic as far as these Apps go. This means, Apps can be hosted on application servers running, for instance, using any technology on the LAMP stack (Linux, Apache, MySQL, and PHP).

This particular feature was hailed enthusiastically by lots of SharePoint bloggers. We don’t share the sentiment. Although in itself it’s great to have the flexibility to use any flavor of application server you like, in reality we’ve found that this type of platform independence is almost never an issue (Roger Sessions once did some, unscientific, research about it, wrote about it, and found that this is a factor in less than 1% of the IT projects). If you’re an avid Java or PHP developer planning to build Apps, you’ll find that you still have to have intimate knowledge of SharePoint technology and development models. What’s more, developing these types of solutions will be a lot easier using the Microsoft dev tools. We’re convinced that the share of skilled Java and SharePoint developers is pretty limited and we’re betting it’ll stay that way for times to come. In addition, some SharePoint bloggers have even predicted the end of the era of SharePoint developers, since now every ASP.NET developer will be able to create Apps as well. We think this is nothing more than a wrong conclusion, for exactly the same reasons. If you want to develop SharePoint solutions in the form of Apps, you need the knowledge about the platform. You simply can’t do that while you’re avoiding becoming a “SharePoint” developer.

Your thoughts?

We’ve never seen a version of SharePoint where so much information was already available during beta release. We did notice though that a lot of articles contrasting farm solutions, sandboxed solutions, and Apps use the terms farm solutions and full trust solutions interchangeably (even so in MSDN documentation).We  don’t think this is fair, because it implies that farm solutions can’t run without full trust. The opposite is true, farm solutions can run under very fine grained security policies. We do know where the confusion is coming from, a new change in SharePoint 2013 is that now, the default CAS policy that is used us Full Trust, instead of wss_minimal:

<trust level=”Full” originUrl=”” legacyCasModel=”true” />

In effect, this will mean that by default, a SharePoint 2013 farm solution will run under full trust, which makes it a full trust solution. Things didn’t use to be like that, and we feel this is definitely a step backwards for the latest version of SharePoint. At this point, all we know that this change is caused by the fact that the full trust is needed by .NET 4?! We don’t have more specifics, and we don’t know if SharePoint  2013 is able to run under a different trust model without breaking.

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: