The Future of Full Trust SharePoint Solutions

Home » SharePoint Development » The Future of Full Trust SharePoint Solutions

The Future of Full Trust SharePoint Solutions

Posted on

With the release of the app model in SharePoint 2013, and all the subsequent marketing hype surrounding Office 365 and the determination of Microsoft to push their customers into the cloud, many have predicted that the end of full-trust farm solutions was nigh. For a while, especially if the rumors swirling within the greater SharePoint community were to be believed, it even seemed as if on premise deployments were going to become a thing of the past. Thankfully, after thoroughly confusing the market with mixed messages and an over-emphasis on all things cloudy, Microsoft has finally put these rumors to rest and, with the announcement of the impending Service Pack 1 release for 2013, made it clear that SharePoint as we know it is not going away anytime soon.

So what does this all mean for developers? Should you continue to invest in full-trust, on-premise solutions or move to the new app model? The answer, of course, is "it depends". It all comes down to your requirements – there are some scenarios where apps are the right answer and others where full trust solutions will be more appropriate. But let’s be clear about one thing – isolated code execution via remote interfaces is the future of SharePoint development. Period. That doesn’t mean you need to throw out all your existing code and start over from scratch but it does mean that you need to start thinking about, and planning for, a new way of doing things. Getting a head start on it now will pay dividends in the long run so there’s no reason to delay – if you’re not yet familiar with building SharePoint apps, then now would be a good time to get started.

But the question still remains – if both models are viable then how do you determine which is the right one? The first step is to understand the direction your organization is heading. If you are a small, nimble company with a significant investment in cloud technologies already, then odds are you will soon be moving to Office 365 for core collaboration features. This means you should start designing all your future solutions as apps, since that will be the only model available to you in the cloud. However, if you are a larger organization that doesn’t move as quickly, or you have good reasons for keeping your collaborative environment in house (either on your own hardware or in hosted by a managed service provider), then you have a lot more to think about. Knowing that you will continue to have an on-premise deployment of some sort makes it easier to chart a course for supporting existing full trust solutions but what about green field projects? It’s easy to keep doing what you already know how to do but what if the organization adopts a hybrid approach sometime in the near future? How would that impact your solution architecture? Could you refactor into an app without causing massive delays or cost overruns?

In many cases, the application requirements themselves dictate which model to use. One of the most powerful aspects of SharePoint (and, arguably, one of the key reasons why it has been so successful) is the rich API’s which provide seemingly endless opportunities for customization. As a middle-tier platform for enterprise web applications SharePoint stands alone in terms of flexibility and extensibility (not to mention the enormous set of features available right out of the box). If you are tasked with creating a web-based line of business application with integrated authentication, data storage, social interaction and collaborative capabilities, you would be hard pressed to find a better framework to build upon. Depending on how deep you need to go into the SharePoint stack, you may find that only the server-side API’s will suffice – typical scenarios include public-facing web sites, scheduled task execution via timer jobs, web or enterprise content management functionality, integration with highly-secure backend systems, extensive interface customizations, long running operations on large content-based data sets, email-enabled lists, custom workflow actions, service applications and so on. If your application requirements fall into any of these categories, or you simply need access to a set of API’s not covered by the provided remote interfaces (CSOM/REST), then a full trust solution is the correct – and only – option. Design and build it with confidence that, at least for the time being, you’re on safe ground in terms of future supportability.

Before you sign off on the final design spec for another big batch of server-side code, though, stop and ask yourself this question: How much of the code actually has to be in SharePoint? After more than a decade writing custom solutions for SharePoint, I’ve found that less than 20% of the code I’ve written actually uses the SharePoint API’s. The vast majority of it is just standard .NET components and classes. Sure, there have been a few SharePoint-centric solutions that have required deep integration with the dark inner workings of the platform, but by and large that’s not the case. Try this – revise your application architecture, separating the core functional elements from the desired integration points and see what you are left with. Based on my experience, I would suggest that in most cases the result would be a blueprint for a provider-hosted app; that is, most of the functionality doesn’t require SharePoint at all and the bits that are left can possibly be achieved via the remote API’s. Look back on the last few SharePoint solutions you have built and you might be surprised how many of those could run quite happily on IIS somewhere with just a bit of CSOM to facilitate authorization, perform CRUD operations, etc. Now think about how many standalone .NET apps you have in your organization and how they could be benefit from all the SharePoint goodness with minimal code revisions if they were to be repurposed as a provider-hosted app instead of rewritten from the ground up as a traditional SharePoint solution.

Please note that I said "in most cases" and "possibly" – I am certainly not suggesting that all full trust solutions can or should be converted to apps. Far from it. But if you start your application design with an app in mind, then move to a full trust solution later out of necessity, you haven’t done yourself any harm and, more importantly, are preparing yourself for the future. Sure, the app model is new with its fair share of bugs, has plenty of challenges in the enterprise, is a pain to configure on-premise, and only offers a subset of the full server-side API’s, but it is the way forward. Stability will improve (hopefully – Microsoft still has a lot of lessons to learn regarding iterative release cycles in the cloud), API coverage will expand, and configuration is already getting easier with better developer tooling in the latest Visual Studio releases. If nothing else, learning to build apps will change your mindset from traditional multi-page, postback, page-bound .NET programming to asynchronous, client-side, HTML/Javascript development, which is the direction everything is moving in at the moment. Learning those skills sooner rather than later can only benefit your career while struggling with the early iterations of the app model will make you a much more valuable SharePoint developer when we get to the point where the tools obfuscate much of the underlying configuration details (in much the same way that those of us who struggled with 2003/2007 development had a leg up when 2010 came around).

The truth behind the marketing hype is that no matter how much the cloud providers want to push you into their service offerings most organizations, especially larger ones, aren’t prepared to make such drastic changes so quickly. Even if they want to move wholesale into the public cloud many organizations aren’t ready yet and some never will be (finance, defense, healthcare, government, transportation, etc.). Full-featured, on-premise SharePoint is too valuable and too deeply ingrained in many organizations to simply be swapped out for a much more limited feature set in the cloud, no matter how attractive the pricing or outsourced infrastructure may be. For those customers, full trust solutions will continue to be an integral part of the SharePoint story, even if they end up deploying some sort of hybrid architecture (which, in my opinion, is the most likely scenario). This is as it should be – customers who make that kind of investment into a platform should be able to take advantage of its full capabilities (within supportable boundaries, of course). But that doesn’t mean full trust is the only option – the app model offers a solid value proposition for certain scenarios and has the added advantage of being portable to the cloud if and when that move happens.

In summary, my advice is to build apps when you can, full trust solutions when you must, and get on board with the current programming trends. It can’t hurt and you might be surprised how much you can accomplish with the 2013 app model. Plus, the more SharePoint developers we have building apps, the more we can guide and influence the future direction of the platform. And that’s a good thing!



SharePoint is Talking.  Are you Listening?  
Improve service levels and avoid downtime with
SmartTrack Operational Intelligence for SharePoint