by Dan Naselius, CorasWorks COO
(This is Part 1 of a multi-part series, read Part 2 here.)
Are you confused by what Microsoft is doing with SharePoint? Are you thinking about what might happen to your current implementation as you consider SharePoint 2013 and/or Office 365? If you built/configured solutions on SharePoint 2007 and/or SharePoint 2010, you will have to make strategy and direction decisions as you consider your move to SharePoint 2013.
With SharePoint 2013 there are opportunities for revolutionary ways of working through cloud-based scenarios. We have exciting possibilities for building out new solutions. However, as with any change, there are positives and negatives, and the new SharePoint 2013 is no exception. You will eventually need to consider whether you’ll continue in the current programming model (with some likely limitations) or adopt Microsoft’s new programming model.
The current programming model utilizes the web part framework and creates fully trusted solutions on SharePoint front-end servers. This approach has been in place since SharePoint 2003. Microsoft has incrementally expanded the features and functions of this model up through SharePoint 2010. Many customers and vendors have invested heavily in building solutions and products using this model. You’ll have the option to migrate these solutions into SharePoint 2013 (thus, preserving your investment); however, the new programming model—the App Model—is clearly the future Microsoft is pushing. Note that none of the solutions built using the current model were ever allowed into Office 365 (previously known as SharePoint OnLine).
So, while it is possible to continue down the same path of installing fully trusted solutions on the SharePoint front-end servers, it is not the only option available now. If fact, it is not even Microsoft’s preference. They would much rather you move to the new App Model that Office 365 (previously known as Office Online) uses, even if you’re staying in an on-premise environment. I believe the mostly likely strategy will be to migrate current solutions to SharePoint 2013, and then begin to figure out how to use the App Model approach in 2014/2015 (I’m assuming most people will wait until Service Pack 1 to do anything serious on SharePoint 2013). This scenario is called a hybrid strategy and I’ll discuss this more in a separate blog.
What is the New App Model?
In a nutshell, the new model is a typical web-based model. It differs from 2010 development which was a “farm” based model, where server-side code/web parts were installed on the front-end web servers. Instead, SharePoint segregates the App by what level of trust it has and where it is installed. While there is a bit of confusion around specific language to describe the scenarios, we are going to use what seems to be the most used vocabulary.
Farm Solution App (fully Trusted App) – This is the model for SharePoint 2010. The SharePoint admin installs a WSP on each front-end web server, which is registered in the Global Assembly Cache (GAC) and writes entries into the web.config. This allows the resulting solution to leverage the server-based Object Model. An important note: Microsoft has not committed to supporting this approach in future versions of SharePoint.
High Trust App – This uses a server-to-server protocol between the server that is hosting an app and the front-end web server(s). This gives the app developer an ability to perform actions that would not be allowed by the app directly. An example of this would be migrating items from one list to another. A high trust app would result in the app being able to populate the “created by” and “modified by” columns as the current user. The setup for high trust apps is involved and as a result will be something you only want to do when it is really needed.
Low Trust App – This is the standard Office 365 App. It does not require the server-to-server setup and is the easiest type of app to build and deploy.
Why are Low-Trust and High-Trust Apps Different than Farm Solutions?
This obviously has some advantages and disadvantages that must be understood. In addition, because it is a new set of skills for many SharePoint developers, it is being met with excitement, confusion, push back, etc., and it will take a while to sort out the best practices. An example of the completely different points of view are the following blog articles.
Support of the new App Model: http://www.elumenotion.com/Blog/Lists/Posts/Post.aspx?ID=175
Skeptical about the new App Model: http://blog.furuknap.net/sharepoint-2013-app-model-solves-non-problems-only
Both of these author’s make very valid points so I’m not suggesting there is a right or wrong answer. In fact, it really points out that it will take a bit of time to determine when to best apply each model based on the need of the business solution that you are trying to solve. But it does show there are real decisions that need to be made. If you don’t make these decisions you will have decided that the Farm-based Solution is the best one for you.
If you decide to move to the new 2013 App Model you will not be able to simply migrate your previous apps, solutions, web parts, etc. In fact, it will require them to be rebuilt using a whole new set of technologies. This is a big decision and one that needs a real understanding of the cost of rebuilding those solutions if you want to make the right decision. For this reason, I believe that organizations with a great deal invested in SharePoint already will want to either keep their Farm solutions and move to a hybrid model where they leverage all of the models for the appropriate business needs. This allows for companies to transition to the new App Model over the next three years.
There are many more details about how and when to consider Microsoft’s App Model. I do not feel those details can be covered in one blog post. If you are interested in further discussion please feel free to comment to this post, or send me an email at email@example.com .
In future blogs I’ll cover this new model in more detail and share what we are learning about 2013.
Until next time,