A lot of my customers lately to the Microsoft Technology Center have been interested in the new App Model of SharePoint 2013. This should not be a surprise given that the new App Model is one of the big additions to SharePoint 2013. What is interesting is that these customers are not going to the cloud any time soon and see SharePoint as an on-premises enterprise service. Most of the material out there on the new App Model emphasizes Office 365 and Auto Hosted solutions where the remote web is running in Azure. I thought I would start this series of blogs posts with why the App Model is something you should consider in an on-prem deployment.
Product or Platform?
Over SharePoint's history, it has struggled with the product or platform question. Ultimately, SharePoint provides a lot of out of the box functionality that enterprises are looking to deploy. Things like content management, search, workflows, business intelligence, etc are all quite functional out-of-the-box with some configuration. This would be the product side of the equation. However, ever since SharePoint was based on the .NET framework (SPS 2003) developers have been looking to extend it. This shouldn't surprise anyone either since for a good quantity of line of business applications, SharePoint is an 80% solution. Developers and enterprises both see it as a platform that if they build on will shorten the development lifecycle substantially since they only have to build the 20% that is specific to their application. Enter event receivers, custom web parts, application pages, custom workflows, etc.
The problem comes when these SharePoint applications are deployed to production and are now the responsibility of IT to maintain. Focused on keeping the lights on, this group is change adverse. Any custom code deployed onto the SharePoint servers complicates things. Does it change the way they do backup and recovery? How well was the code written and will it bring down the farm? Does it change the capacity planning activities that were done for out-of-the-box functionality? For these reasons there is a struggle as to how to effectively support these types of applications that are built leveraging SharePoint.
Build On or Build Alongside?
It is important to realize how developers have usually built SharePoint applications in the past, some of the fundamental problems with the model and why things are changing so drastically with SharePoint 2013. Prior to SharePoint 2013, developers looked at SharePoint and saw it almost like a stack of lego blocks they can use to build an application. Things like lists, libraries, versioning, search, calendars, workflows, etc were all pieces to lay the foundation for their application. To build the whole "solution", developers would build custom components that when deployed to the SharePoint server, fill the gap. These were things like custom web parts, event receivers, custom code workflows, application pages, and so forth. The end result was that SharePoint + the Customizations = The Solution. I have coined describing this as the "Build On" solution. See this rough picture:
What is the problem of this model? It is the model that all prior SharePoint development likely used and even most of the SharePoint developer training teaches. The problem is that the customizations are literally extending the product on the SharePoint server. Once this has been done, all bets are off in terms of performance. It could complicate your IT staff's ability to meet their service level agreements. And remember this was done to keep cost low - however, now every time you "upgrade" SharePoint, you have to retest all of this additional work. You got a big bang up front, but are paying later when it comes to moving to new releases. This is the most costly part of upgrade/migration conversations I have had with customers.
Enter SharePoint 2013 and its new App Model. Before we get started, it is worth noting that using the App Model on-premises is an option. You can still continue to Build On SharePoint, but you are still subject to the disadvantages of that model. The new App Model changes the game considerably with a fundamental rule change. Thou shall not put custom server-side code on a SharePoint server. SharePoint can still be used as an application platform, but we are going to keep the farm's servers from being burdened with running your customizations and require you to host them somewhere else. Where you say? Anywhere you want (Azure, another web server, etc). In fact this separation of the out-of-the box SharePoint product functionality and your customizations opens up tons of benefits. First the obvious ones:
- Your app won't have compiled code on the server complicating the hosting and management of the SharePoint farm
- You can separate responsibility for hosting the SharePoint enterprise service and the line of business app functionality
- In fact developers could use even non-Microsoft tools and languages to build the remote functionality
- Lastly, it drastically reduces the upgrade hurdle since it is easier to keep interfaces backward compatible (you are not strongly coupled to SharePoint's server assemblies)
History of SharePoint Development Models
If you are new to this, hopefully at this point I have you scratching your head. You might be wondering how this fits into the developer methods you already know. So let dive in a bit to clear things up... If you were familiar with SharePoint 2010, I'd argue that your development efforts probably fell into one of these three buckets:
That's it for now. I plan a part two where I go into more detail on the types of apps in SharePoint 2013's App Model and how to change your thought patterns of what it is you need to build for that last 20%. Possibly another post where I give some advice for those of you who are trying to build this on-premises. And possibly some web demos. Let me know what you think in the comments and what direction I should take for the future parts.