If you’ve been reading my blog over the last several years you know that I’ve got a ton of technical posts including posts about both infrastructure issues (like claims, Kerberos, and performance) as well as development concerns. However, lately I’ve left the technical blog posts to some of my contemporaries. While I’ll occasionally blog (or log) my technical issues, their root causes and resolutions, I’ve been much more focused on the business and organizational issues of SharePoint. However, this post has to unify those views. Customers are coming to me and asking whether they should be doing SharePoint App development – and when. (Complicating the matters are that Microsoft has renamed SharePoint App development to Add-in development and has released another model for development for Office 365 applications.) While the answers are simple in some cases, they get complicated fast. However, there are answers to the questions.
In the Beginning
On the first day of SharePoint there was the SharePoint 2001 based on ASP (not ASP.NET) and it was not so good but we customized it to make it acceptable. On the second SharePoint Day we got SharePoint 2003 and the ability to use ASP.NET (and the SQL based file engine). It was good because we could customize it and add our .NET goodness to it. On the third SharePoint day we got SharePoint 2007 and the package solutions and it was too good. Suddenly everyone wanted to be able to develop their applications on the SharePoint platform. As a result many of the support calls Microsoft received were because of poorly performing code that customers had written. On the fourth SharePoint day we got SharePoint 2010 complete with its Sandbox for code we didn’t trust. The problem with this is that while it worked for corporations who had rogue development organizations internally that weren’t controlled by corporate IT, it didn’t work at the scale of the cloud. There were some things which couldn’t be protected against. On the fifth day of SharePoint we got SharePoint 2013 and the brand new model of development – Apps. From a hosting perspective, Apps are great. No code ever runs on the server and therefore it’s not possible for applications to bring down the server. (Again, Microsoft recently renamed this type of development to Add-ins.)
All would be good if Sandbox solutions and Apps could use the same skills the developers already had, the same coding styles, and could solve all the same problems. The problem is that this isn’t the case. Sandbox solutions had a set of limitations based on how they were implemented. For instance, you couldn’t access the page object to include script you needed. Apps are substantially different than solutions development – either full trust or sandbox. And that’s where the rub comes in.
Smart car or Semi-trailer Tractor
The problem is that the SharePoint solutions were a Semi-trailer Tractor. You could do anything with them. You can pull along branding, custom solutions, recurring timer jobs, configuration, etc. However, if someone fell asleep at the wheel it caused a multitude of problems from performance to stability and even in some cases data integrity. That’s why the Sandbox solution was designed. What if we could get folks into a big pickup truck? They couldn’t carry as much, they wouldn’t be able to do as much – but at least if they fell asleep at the wheel – or if they were malicious – they couldn’t do as much damage. The problem is that the available damage wasn’t tolerable at scale.
On the other end of the spectrum is something like a Smart car. When I see them on the street I tend to comment that there goes half a car. They’re efficient, small, and are quite capable of transporting two human beings from one location to another. Federal census data from 2009 indicates that 76% of American workers drive to work alone. If 3/4ths of the time you don’t need to have any passengers – let alone carry cargo, why would you drive around a big Semi Tractor and Trailer?
The way that you drive a Semi-tractor trailer is different than the way that you drive a half a car.
The car to semi analogy breaks down when we start to think about how they’re actually technically different. Certainly the capabilities are different and they’re optimized for different things. When used for what they’re designed for they’re both great answers. However, in that analogy both drive fundamentally the same way. There’s a steering wheel, gas, and a break. The Semi might have manual shifting and the Smart car an automatic transmission but fundamentally they behave the same. However, the way that Apps (and Add-ins) are designed and the way that traditional solutions were designed are substantially different.
Consider that there are two ways to balance a budget. One way is to increase your income from another job, a second job, or working more hours. The other way is to downsize your house, replace your car with a less expensive solution, cut out cable, and eat less expensively. Which approach is right? Both. They’re just two sides of the same coin. Both of these aren’t really equal, however, because it takes a disproportionate change in income compared to the same reduction in expenses. Said more plainly you have to change your income more dramatically than the same amount of savings. Why? Because of taxes and other ways that making more money doesn’t return 100% of the gain to your bottom-line budget.
Apps are a similar situation. There are some great new benefits but they come at a cost and they create new limitations.
Provider hosted applications can be built in whatever technology you want so in that sense there aren’t new skills to learn to build the application. However, the challenges exist in managing the communication with SharePoint which requires a deeper knowledge of Public Key Infrastructure (PKI), certificates, encryption, and identity management than most developers (SharePoint or not) have.
SharePoint is a portal platform. Though portal was dropped from the name many editions ago, it remains a product that’s designed to bring resources from disparate sources together. On the super easy side this is done by placing links on the SharePoint page to the other applications that users need. However, in many cases this isn’t sufficient to get the kind of view that users need of their environment. In the past SharePoint web parts have been the windows to the information stored in other systems. Some amount of code would fetch information from a back end system and display it on a page. Several different web parts could be added to retrieve data from multiple back end systems. That’s great but it required code running on the server.
In the App world where this is no longer an option, you can’t directly fetch the information and add it to the page on the server. You can use client-side techniques to inject that content into the page but this has potential side effects. Or you can use technology we tried to eradicate in the 1990s – that is the humble IFRAME. IFRAMES are inline frames and have been a part of HTML for a long time. IFRAMEs have their own set of issues when used in a portal including communication between the host page and the IFRAME content, getting the consistency of look and feel, etc. Look and feel is interesting because IFRAMEs are outside of the processing for CSS and styles that are applied so it’s necessary to get the CSS into the IFRAME.
SharePoint App Parts are designed to handle some of these challenges including providing to the application the CSS used at the server. However, the problem of messaging to the host page of an app part isn’t fully resolved by the framework. As a result for dashboards and other situations where multiple parts on the page need to communicate and react to each other – like our old web part connections – App parts are problematic.
For provider hosted applications, you also have to make sure that the applications are accessible to the user wherever they are. If you’re hosting your own applications and users access SharePoint from outside your network – you’ll have to make the applications available.
What benefits to Apps offer? Besides the obvious advantage of not having untrusted code running on the server, there’s the advantage of being able to develop in any language you want. Sure there may not be a pre-made Python or Ruby library for connecting to SharePoint as an application but it’s technically possible to do. If you’ve got an army of developers who write in Java and need applications to plug into SharePoint, Apps are the way to go.
If you’ve got a Java based system that you need to connect to and you have developers that understand that system the effort to make the app work in SharePoint may be less effort than trying to teach .NET SharePoint developers how to access the data and functionality in the Java system.
Which Way Do You Go?
Right now if you want to use office 365 you have to write a Sandboxed Solution or an App. Microsoft has said that the sandbox will be deprecated from Office 365 “soon” so it’s not an area to make further investments in. However, all of these statements apply to Office 365. If you’re going to be running SharePoint on premises then you can use full trust solutions, sandbox solutions, or Apps. So when you’re in an on premises environment it doesn’t matter which way you go. Leverage apps where you need to get cross-platform support.
Complicating this are Office 365 Apps which only work on Office 365 but provide a unified API across the Office 365 services. If you’re doing Office 365 these Apps are fundamentally similar in technology to SharePoint Apps – or add-ins – but use different APIs and are published differently. They’re published into the Azure AD that backs Office 365.
One of the complicating factors for deciding to develop Apps is that the application lifecycle management doesn’t really work. For SharePoint Apps (Add-Ins) you can’t migrate the configuration and data from environment to environment with Apps enabled. You have to reconfigure the apps in each environment. This can be problematic no matter how you manage your configuration. For provider hosted applications there’s the added issue that you compile an App package and it has a fixed URL endpoint so all of your SharePoint environments will point to one target provider application – in development, quality assurance, and production environments.
The work around to this is to leverage a build server that creates separate packages for each environment on the SharePoint site. However, this is more sophisticated than most software development organizations I’ve seen.
Office 365 Apps have some tricks that can be done with Azure hosted apps and deployment slots that allow you some level of control over which environments point to which versions of the App. However, these controls are still relatively minimal.
So basically this creates a fork in the road. If you’re going to be on premises you’ll want to continue full trust code. If you’re on Office 365 you’ll want to create Office 365 applications. If you’re walking the fence you may want to deliver SharePoint Add-ins that can run both on premises as well as in Office 365 – but this is a somewhat unique case – that I wouldn’t generally recommend.