Full trust computing. That was the plan under Microsoft’s old application development model. But now, with all the moves Microsoft has made to jumpstart business, the question has become: Can developers trust Microsoft?

“The SharePoint Cowboy” Eric Shupps is a Microsoft MVP whose company, BinaryWave, delivers products and consulting to users of SharePoint Server on-premise. He sees customers worried that the sand beneath their feet is shifting.

“We told people in 2010, ‘Use the Sandbox first, and go for full trust second.’ Today, it’s ‘Apps first, then full trust only if you must,’ ” Shupps said. “Developers wonder, ‘Is this going to go the way of the sandbox? Will it only last one revision, when I know the full trust environment will last?’ ”

In his SharePoint Cowboy blog, Shupps wrote:

“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.”

Perhaps a larger question, though, is how much of what developers build has to be in SharePoint? “In Office 365, it’s only apps. It’s time for developers to get educated on that,” Shupps said. “If you understand REST and OAuth, you’ll have a comfort factor.”

Again, he wrote:

“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 APIs. 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 APIs.

“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.”

Eric Shupps will be presenting developer training sessions at SPTechCon San Francisco, June 22-25. Learn about his sessions here.