SharePoint 2013’s Cloud App Model: It’s What You Wanted All Along

By Mike Fitzmaurice

Be careful what you ask for; you may get it. – Unknown

I’m seeing a lot of resistance to SharePoint 2013’s Cloud App Model. I’ve seen a few industry pundits decry its architectural requirements. I’ve even been invited to join social media groups that serve as a support group for developers who don’t want to let go of trusted code.

I’m very sympathetic. Heck, I’m even empathetic. But I’m also extremely amused.

What’s the Cloud App Model (aka the New App Model)?

Up until SharePoint 2010, if you wanted to add your own features to SharePoint, you installed code directly onto SharePoint’s servers. The server, and IT, had no choice but to trust that your code would not only work as advertised, but that it would do no harm.

SharePoint 2010 introduced sandbox solutions, where we were offered a way to write code as if it were trusted, but SharePoint would restrict what it was allowed to do so it couldn’t hurt anything. Unfortunately, those restrictions were so severe that we ignored it and continued with fully-trusted code anyway.

Well, in SharePoint 2013, we have the Cloud App Model. These applications are expected to live somewhere else (on another server, in Windows Azure, anywhere), but SharePoint provides a way to:

It’s also not only for SharePoint in the cloud (e.g., Office 365). The name “Cloud App Model” has emerged because “new app model” has too short a lifespan and because many apps for other cloud platforms (e.g., Facebook) also work this way.

Why I’m Amused

What’s so funny? The story has come full circle.

I’ve lived in SharePointLand for a long time.

I didn’t give birth to the baby, but I was in the delivery room when it happened, and I was one of its first wet nurses.

I was the first technical product manager hired by the SharePoint team, and at the time, it involved a lot of knocking on the doors of developers and asking them to have a look at things like Web Parts.

It also involved approaching IT pros and asking them to think of having SharePoint farms offer more than de facto web-based file shares.

There was resistance.

To be specific, developers and IT had a certain way of thinking, and it wasn’t immediately portable to the way SharePoint worked.

At the time, we thought of SharePoint as a portal platform that contained content, collaboration and search services. We wanted developers to create, and IT to allow, lots of Web Parts that could be installed into sites to aggregate applications.

That idea caught on to some extent, but we evolved to what you wanted (as it should be). You told us you wanted branding options, better handling of list data, richly customizable views, workflow, forms and ways to deploy those things as features.

Web Parts never went away, but they haven’t been the star of the show for a long time.

The Cloud App Model will change that.

Developers: You Asked for This on Day One

ASP.NET developers would look at SharePoint and ask, “You want me to stick my custom website inside of a window in your portal?”

I’d respond with, “No, we want you to break the UI up into mix-and-match components, and let users insert them into their own sites as they see fit.”

Even later on, we were saying, “No, you don’t really develop a finished site in SharePoint. You develop a description for a type of site, or a feature for a site, and we’ll use that when users ask for them. You’re not so much building your app as you are modifying the behavior of our server.”

It required rethinking a lot of things. Mercifully enough, it caught on with enough people that SharePoint is a thriving community.

But you know what the Cloud App Model lets you do? Build your own site and surface it inside of SharePoint.

You can even use any language or framework you want. You’re in control of every aspect of the app as long as you follow the contract it makes with SharePoint.

IT: This Protects Your Number-One Priority

Getting IT to allow custom code (like Web Parts) on shared SharePoint farms was never easy.

In fact, in Microsoft’s IT division, it wasn’t even possible. Too much fear about custom code destabilizing its carefully-maintained servers. Didn’t we have a way of pulling in custom content from remote locations?

Yes, over the years, IT got more comfortable with allowing some trusted code on their servers, provided they found it to be trustworthy (Nintex Workflow, to name one of several).

But it doesn’t mean they don’t still like the idea of keeping custom code off of their servers.

Well, the Cloud App Model means custom apps run off-box. They can’t destabilize your server because they don’t run on your server.

Pundits: This Provides the Best Parts of WSRP

Back when portals were all the rage, there was a great deal of pressure from industry analysts, some enterprise architects, and some vendors to support a standard call Web Services for Remote Portals, or WSRP. The idea was to deliver UI components inside of SOAP web services.

It was a nice idea, but it suffered from several issues, not the least of which was to make a portlet vendor-independent.

If you wrote a nice piece of functionality, it could be called from many vendors’ products. The problem with that was that it had to descend to the lowest common denominator to do so. Even vendors that supported WSRP had better ways to provide portlets using their own product-specific frameworks.

In other words, remoting the UI has a lot of merit, but doing so without any knowledge of the target platform has limited merit at best.

Well, the Cloud App Model gives you that first part, remoting the UI, but does so using more modern standards (REST and OAuth instead of SOAP) and allows the app to be aware of the place it’s going to be displayed.

Everybody Wins—But Everybody Complains

Developers build whatever they want, however they want, and it can be shown in SharePoint.

IT gets custom functionality without risk.

Everyone gets plug-and-play, mix-and-match functionality that’s standards-based.

So why the pushback?

Well, for IT, it means buying, deploying and maintaining extra servers.

And if they try to pool several custom apps on a common server and those apps aren’t stable, they won’t affect SharePoint but they’ll affect each other.

For developers, it requires again rethinking the way apps are built. What’s more, the remote APIs don’t provide everything. Microsoft left behind some trusted code functionality that hasn’t been implemented in either the REST API or the client-side object model.

The branding-and-customization crowd is particularly affected by this. Some of that was deliberate, but much of it was a matter of running out of time before the ship date.

These aren’t insurmountable problems. The APIs will improve. App servers can consist of multiple virtual machines that are kept isolated from each other. It’s already good, and it’s going to get better. It is getting better.

And ultimately, it’s going to be moot. In multi-tenant environments such as Office 365, this is the only real option. Welcome to the future—it’s what you asked for in the past.

Mike Fitzmaurice is the vice president of product technology for Nintex, the world’s leading workflow software company with more than 5,000 customers in 90 countries.