App model – is it good or is it whack?
/I am going to rely on Ali-G's Good / Whack Symposium style for looking at the pros and cons of the app model. If you are not familiar with this modern twist on a classic Oxford Debate style check out
As a popular reason for apps Microsoft’s app model proponents often say(s) that "In a typical SharePoint solution, as shown on the left side of the image, your code executes within the SharePoint execution environment. This means that your custom code could have a negative impact on that SharePoint environment." What might appear as an obvious benefit upon initial consideration, might turn out to not be so beneficial in the long run:
- Why do I have a SharePoint environment in the 1st place? To do some things that are useful for the business: keep track of tasks, do whatever... These useful things will now be exposed as apps living on another server isolated from SharePoint.
One important consideration is that I HAVE SHAREPOINT INSTALLED for a purpose of doing these "APPS" based things. Industry news media can write all they want about users' thirst to get Social at work. The reason most places get SharePoint is to use it to do useful things. It is a little consolation that the SharePoint is still online even though my application went down.
SharePoint is there as a platform, if its "payload" is not working, it is little consolation that the mothership is still ticking. - Having isolated environment might sound all great and safe, however, when before I had one farm to babysit, now I have an additional environment based on whatever technology. I have double the HW, double the headache, and I might not be able to realize economies of scale with a uniform platform, because department was inspired to develop a custom CRM on iron python, ruby, or php.
App Model assumes additional environment, with related maintenance, licensing costs, etc... - "Client side" integration is great, however there are scenarios where there are significant performance penalties for adding network latency since the magic happens on the client now. There is no denying that there could be instances of a double trip over the network which will decrease performance in some scenarios.
There are scenarios where app model will reduce performance. There will rarely be a scenario of enhanced performance. - There is investment into things developed in Server Side SharePoint. App model introduction is somewhat of a carpet-pulling exercise from Microsoft’s standpoint.
You had people jump through all these hoops to build solutions using arcane, difficult to train for, bloated beast of a platform. Platform that produces plenty of opportunity for heroism in doing the simplest things, and then you tell them – “all this code you wrote, hmm it is no good anymore. Rewrite it as an app, next iteration around.”
Unconditional push for Apps (from Microsoft) as a new approach lacks recognition of existing investment into what was a difficult and expensive platform.
So what makes App Model Whack?
I will summarize conclusions listed above:
1. SharePoint is there as a platform, if its "payload" is not working, it is little consolation that the mothership is still ticking.
2. App Model assumes additional environment, with related maintenance, licensing costs, etc...
3. There will be scenarios where app model will reduce performance. There will never (rarely) be a scenario of enhanced performance.
4. Unconditional push for moving existing solutions into apps (from Microsoft) as a new approach lacks recognition of existing investment into what was a difficult and expensive platform.
5. Expense, headache, and complexity of hosting the beast is such that Office 365 move, is almost a no-brainer. One could conclude that the plan was all along to introduce this headache of a platform, promote it beyond its natural scalability and then once companies are tired of distractions of hosting, offer a lifeline locking in a lifetime hosting client.
It can’t be ALL whack - Is App model good for anything?
- Yes, it is good for surfacing already developed apps with minimal change in context of SharePoint. What is the upshot? If you believe in any combination of the following:
- You need some way to expose your applications in the enterprise.
- You think that SharePoint UI once learned can lead to long term leveraging of such skills by employees to learn new applications written on the same platform.
- Spending big $$ on licensing makes you feel more supported.
- App model moves development to the client, exposing opportunity to take advantage of recently client side development technologies. (You could do it before with 2010, however you had to rely on some 3rd party components to make it humanly consumable (SPServices).
So what is an alternative to it all?
As alternative corporate IT departments should focus on the stack that they have learned over the years. Stack that is mature, stack that has a fathomable learning path and is easy to learn: ASP.NET, C#, Windows Services, AD, IIS, etc… It pains me to see newly minted developers that think the only way to run a scheduled repeatable task is SharePoint timer job.
Windows / .NET Platform is mature, it is inexpensive, it has a rich service offering matching SharePoint’s w-out unnecessary complexity in many cases. Solutions are portable and scalable and you don't need million $$ infrastructure to run them.
| SharePoint Platform Service | Corresponding Plain Vanilla Windows Offering |
| Security - Windows Auth | IIS Windows Auth |
| Security - Claims (aka WS Federation) | Claims are super-easy to consume in .NET |
| Search | Lucene.NET |
| Lists | A multitude of data frameworks |
| etc.. | |