A few weeks ago I had the opportunity to be the keynote speaker at the SharePoint Summit in Toronto, Canada. Months before when I received the invitation, I was doing a lot of work and thinking around the new SharePoint app model. It wasn’t the typical technical aspects that had my attention, it was more along the lines of the business of SharePoint Apps, the messaging coming form Microsoft, confusion customs were having and the challenges many of us were experiencing when applying this new model to the real world business problems. I though this would be a great topic to talk about… and so I did. I got some good feedback from folks and committed to writing it up.
If you’d like to see the slide deck I used in this presentation, you can check it out here.
I’m not going to bore you with what we already know about the app model… there are plenty of posts on it. Good technical discussions from the likes of Ted Pattison’s app series, musings from Doug Ware and Chris O’Brien as well as many others. Even Microsoft has taken recently to starting a new video series that you can see here. Instead, I’ll side step the technical discussion and talk more about the implementation and challenges we are having.
If you look through the documentation on MSDN, you’ll see Microsoft is pushing apps as the best way to customize and extend SharePoint when you want more than what the browser gives you. For instance, consider these quotes from various pages on MSDN:
The most important guidance we can give you is to develop an app for SharePoint rather than a classic solution whenever you can.
MSDN - July 16, 2012
I tend to agree, and in fact I quite like the app model, however there are a clear number of things where you need a solution because apps can’t reach those answers. Microsoft agrees… and they offer the following list of things where you should consider farm solutions, such as:
- Custom Site Definitions
- Delegate Controls
- Custom Action Groups & Hiding Actions
- User Controls (*.ASCX files)
- Custom themes
Our recommendation that farm solutions be used primarily for administrative extensions [that] did not apply in SharePoint 2010.
MSDN - July 16, 2012
To most customers, when you look at this list you might think “that’s not so bad… that’s not stuff I’d want to do anyway.” Unfortunately this is very misleading as there are a great number of things you can’t do. Most of these things are due to the very nature of the app model and the way SharePoint isolates app installations within SPWebs. This means that you can’t do much within the host web (aka: parent site, or the site from where the app was installed). It is possible to interact with the host web, but if you do anything more than simple reads, your app needs to have full control on the host web and this is one of the things that will exclude you from being in the public SharePoint store. So simple things such as creating site columns, content types list templates or provisioning files within a site using an app are simply not possible in the public SharePoint Store without writing a lot of custom CSOM code. And even if you elect to use the apps in your own environment where you can have full control, this is quite a hard process, as Chris O’Brien shows on his blog in provisioning a file to the host web.
Customers are finding a lot of additional things that they can’t do within apps that they could have done the old way using solutions such as the following things to name just a few of them:
- No Client-Side Script in the Host Web
- Can’t Automatically Add Apps to Site Templates / Site Provisioning Process
- Frequently Apps Require Loads of Permissions to Do Anything in the Host Web (and that blocks them from the SharePoint Store)
They also are pushing people quite hard away from solutions, but at the same time creating some confusing messaging around the future of solutions. The only absolute they have put their foot down that we can’t use farm solutions in Office 365, which is understandable. But as far as sandboxed solutions are concerned, they seem to be hedging with the following statement that everyone interprets different ways:
SharePoint sandboxed solutions are deprecated in SharePoint 2013 in favor of developing apps for SharePoint, but sandboxed solutions can still be installed to site collections on SharePoint 2013.
MSDN - July 16, 2012
You have to make up your mind what this means. But from my point of view, sandboxed solutions aren’t going anywhere anytime soon. Maybe they’ll stop us from getting access to the Solution Gallery in our site collections which is how they are deployed, but technically, the product has these buggers built in pretty deep. It’s how the Design Manager exports/imports design packages. It’s how lists saved as templates are distributed. It’s how files are provisioned within apps (in fact, there’s a *.wsp within the *.app package). For me, I’ll use them when apps don’t give me what I need.
One challenge I find people have with the messaging from Microsoft around apps is technically focused and misses the mark when it comes to business. They do a lot of “why not solutions” and “why apps” and then go on to tell you “how to do apps”, but in my mind what they fail to cover is the business of apps and their role within SharePoint deployments. Unfortunately customers are left to figure this out on their own.
So what is the general story of the app model… what can we build? Like I said at the start of this post, I don’t want to restate what so many others have said about the different types of apps (SharePoint Hosted & the two Cloud Hosted options in Provider Hosted and Auto Hosted). Rather I want to just provide my thoughts on it. I personally don’t like the way that MSDN tells you what your options are. Their wording positions things as an either-or decision from my point of view and the customers I’ve worked with.
Specifically, they say you can build either a SharePoint-Hosted app or a Cloud-Hosted app. However when a developer cracks open Visual Studio, they don’t see cloud as an option. That’s because cloud is split into two other options: Provider Hosted and Auto Hosted. Provider Hosted is when you, the app developer, owns the external component (aka: the remote web) of the app such as the deployment, hosting, scaling, management & costs. Auto Hosted is when you include the remote web within the app and it is deployed to Azure when the customer installs your app, shifting the cost to them.
That’s problem #1 I have with this: cloud isn’t just cloud, it’s really two different, very different, things.
Problem #2 I have is that these all seem like explicit choices, but that is not the fact. That’s simply how your application starts. In the strictest interpretation, SharePoint Hosted apps are manifested within SharePoint and execute within the browser… no external references. Cloud Hosted apps on the other hand live and execute outside of SharePoint, either in Azure, some other cloud service like Amazon or Google, or even on your own IIS or WebSphere boxes. There’s another option, which I find to be much more common and that’s hybrid apps. You can easily turn a cloud hosted app into a hybrid by adding a list to the SharePoint project. Or you can turn a SharePoint Hosted app into a hybrid by adding a remote event receiver. So the big take away here: it isn’t an either or… it’s how you start.
Problem #3 I have deals with Auto Hosted Apps. Back when SharePoint 2013 was announced (July 2012) and this app model was being explained, Microsoft explained how the Auto Hosted model would only work on Office 365 at launch. This is going back to the summer of 2012. The reason it only works in Office 365 is because they handled the wiring up of things that needed to be done for SharePoint Online to create the Azure website and SQL Azure database. Microsoft has said, at that time and since, paraphrasing “We’ll provide guidance in the future on how to set this up for on-premises installations.” Sadly, there’s been zero on this since we first heard about it nearly a year ago. Even worse, they haven’t even said when we can expect to get details.
As such you are seeing a lot of people ignore this option all together. What company in their right mind would elect to build a product that can only be purchased by 50% of the population, and that assumes that it’s an even split of customers using Office 365 for SharePoint and those who are on-premises… which is a false assumption.
Before wrapping up this post, I’d like to touch on the Microsoft Store. The idea here as you know is to provide us with a marketplace to sell our apps… part of the Microsoft Mall - something I made up… on the first floor is the Windows Phone Store, on the 2nd floor is the Windows Store and the top floor is the SharePoint & Office Store… with the food court on the 3rd floor as these stores aren’t that big.
This is a great idea but it’s lacking two big things. First, there is no vehicle for subscriptions or in-app purchases… once you buy the app, it’s bought… end of the relationship with the customer. They said they would be adding subscriptions, but that was almost a year ago and we’ve yet to hear anything. I find that amusing as Microsoft shifts from a software to a services company trying to get us into recurring payments rather than one-time payments. However thankfully, unlike the Windows Phone or Windows model, we aren’t blocked from doing anything within our app, especially if it has a remote web component so we could provide our own place for transactions.
The other point of frustration is that the owner (Microsoft) of the market (Office 365 customer base) doesn’t provide any metrics on the demographics of those in the marketplace, so if you’re looking to build an app, you don’t know how big your market is. Recently Microsoft announced there were 1 million people on Office 365, but this only answers one question: what’s the upper limit of the possible customer base? I suspect those actively using SharePoint Online is quite small… I suspect the majority of those 1M people who have moved to Office 365 are taking advantage of the hosted Exchange support. Heck, I hear of many dissatisfied customers who are looking to move out of Office 365 than those who are looking to move to it. While they have access to SharePoint, I wonder how many are actively using SharePoint for their intranet solution…
There are a ton of questions app makers what answered about the market:
- Out of 1M users, how many organizations are there, and what’s the breakdown (small / medium / large businesses)?
- How many are actively using SharePoint and what’s the average size according to the small / medium / large businesses of the deployment?
- How many of these deployments have a corresponding on-premises deployment.
- How can customers / app providers communicate directly with the market?
After reading all this, if you made it this far, you can see what my take is on this brave new world we’re currently in. I hope in the future, and expect, the model will evolve and it will give me the ability to revise my thoughts. Until then, if someone from Microsoft was going to ask “so, what do you want?”, I’d say the following.
Don’t kill or block me from using the sandbox: At least don’t kill it until I you bring full parity between both the app model and what I can do in the sandbox, at least for those things that make sense (I’m not asking to have managed code on the server, I’m asking for provisioning things to the host web for instance).
Follow through on your promises… NOW: Give us guidance on how to configure an on-premises deployment for using auto hosted apps. At the very least, tell us when you’ll tell us how to do it. I understand there are possible limitations such as “you can only deploy Auto Hosted Apps on premises to local IIS installs, not to Azure” or something like that. Ideally it’s a provider model thing so we can rely on ISV’s to create the providers, similar to how SQL Server’s RBS infrastructure works. Follow through on your promise about subscriptions for the SharePoint Store.
Provide us demographics on the Office 365 market: Many of the questions above need answering. If none other than ammunition for app developers who can decide “yes, it will be worth my while to build apps for large-cap companies.” We get metrics on how many phones in people’s hands, we get the same for Windows deployments… same with devices. Ideally someone would contract a research firm to create a semi-annual report for us.
With all this being said, what would I tell someone exploring this new model. Well, here’s the conversation I’ve been having with the customers I interact with and with companies at conferences.
When engaging with a customer, what I’ve found that works best is to talk to them about why solutions should be considered the old way and apps the new and better way. However, one key thing I always ensure to enforce is that this isn’t an either or decision. You can use solutions today.
I always try to do my work using the SharePoint-Hosted App model over the cloud hosted. Why? Frankly, it’s less to maintain and more fire & forget with the app. I don’t have to worry about some other component breaking down or the complexities of app authentication. Of course, this isn’t for every solution and there are tons of valid reasons for using the cloud model. I’m just going to favor the KISS principles (keep - it - simple - stupid). With that being said, I’ve built my fair share of Cloud-Hosted apps… I just try to go SharePoint-Hosted first.
Considering the fact that Microsoft has been mum about the on-premises deployment option, and their history about going radio silent for long periods of time for things that are going to go away or die off (see: Silverlight), I don’t think this gives a good outlook for these types of apps. From my perspective, these age great for us to use in demos and to quickly show off the cloud model, but in the real world, these are utterly useless. I’d love to pivot 180 degrees on that statement, but after holding my breath for nearly a year, well… your move Microsoft.
And just like all other projects we do… stop and think… just take time and think through things when you start a new project. Proceed slowly if you haven’t done this before. You’re bound to bump your head many times along the way. Unless you are certain it can be done, test and try it out before committing to it. A lot of our old SharePoint development knowledge applies, but a lot does not.