This is How I Think Autohosted Apps for Office 365 and SharePoint Should Work

A few weeks back at the MVP Summit, Microsoft carved out an extra day for SharePoint & Office 365 MVPs to flip the table on the traditional format: rather than have marketing & engineering present to MVPs, we [MVPs] had the opportunity to present back to engineering. Microsoft ensured that the right people from marketing & engineering were in the room to hear what was important to the presenters & how it related to different areas of the product.

This was a very cool opportunity. Some presenters did their own thing and presented what was important to them. Others solicited feedback form the community at large and presented on behalf of them. I presented on a topic that I was passionate about and had an idea on how to address & implement it.

DISCLAIMER Everything at the MVP Summit is wrapped up under a nice tight non disclosure agreement (NDA) which is very much like fight club: you don’t talk about what you see or do there. Think of it as a safe place where everyone can be very honest. I did receive an OK that I could write about my session, but I am going to leave out the Q/A, the discussion that stemmed form my fellow peers (also MVPs) & Microsoft engineers. That falls in the gray area of NDA, but even if it was ok to post, I would view that as a compromise in the spirit of the day so I’m not going to share those conversations. Hopefully those in the room will comment on the article and we can have an open discussion!

BIGGER & FATTER DISCLAIMER This is strictly my idea and should not be interpreted as insight into what Microsoft is thinking or doing. I came up with this idea in a vacuum with no insight form Microsoft… the first time I presented this was the first time I had a conversation with Microsoft about this topic. This post & article is based solely on my presentation.

Looking Back

As most of us know, Microsoft shipped SharePoint 2013 & the current generation of Office 365 with a new extensibility model called the SharePoint App Model. Developers could create two types of apps: SharePoint Hosted & Cloud Hosted. The latter came in two flavors: provider-hosted & autohosted. Both involve deploying a remote website and related assets external to SharePoint. The difference in the two is that with provider-hosted, the developer was responsible for deploying those assets. However autohosted deployed those assets automatically for the developer & user of the app to Azure.

Without getting into the details, Microsoft decided that the autohosted model was not the way going forward so they elected to discontinue it. Why? It really boiled down to not being viable in the long run or being able to deliver on what customers need & want today… or tomorrow!

So where did that leave us? If you wanted to do an app that was 100% client-side, you could create it as a SharePoint hosted app where all app related resources were deployed to SharePoint. But if you wanted to have some sort of a server-side footprint, you had to build a provider hosted app using the cloud app model that had a RemoteWeb. This RemoteWeb would be the remote website that lived outside of SharePoint. The developer, or provider of the app, is be responsible to configuring, managing and paying for the hosting of the RemoteWeb.

But every install of the provider hosted app would use the same remote web so the developer had to account for multi-tenant solutions. Auto hosted apps gave us the ability to have a RemoteWeb for each and every install.

What was wrong with Auto-Hosted Apps?

There were a few challenges with auto-hosted apps though. First, the way they were implemented is Office 365 would spin up a new Azure Website & Azure SQL Database for each installation of the app. These would be created in the Office 365 managed & owned Azure tenant. The Office 365 team assumed all management, deployment, scaling, configuration for this Azure subscription. But most importantly, they also assumed all costs associated with this Azure subscription.

This was also an Office 365 only thing… no chance for this working in an on-premises installation.

The biggest challenge for customers though was that they had zero visibility into the deployed assets. Even though the website & database were in Azure, they weren’t in the customer subscriptions rather they were in the Office 365 subscription. This meant that we couldn’t increase the size of the website or scale it out.

As such, these challenges were simply too much for Microsoft to continue with the preview program known as auto-hosted apps.

Where are We Today?

Office 365 & on-premises SharePoint deployments support two types of apps today: SharePoint-Hosted apps and provider-hosted apps, but not auto-hosted apps. Today, Microsoft has not shared any plans to bring back auto-hosted apps… but I have a proposal.

Introducing my Proposal - AAD+H

This is the bulk of what I proposed at the MVP Summit. Essentially we bring back auto hosted apps. I call my proposal the Automated App Deployment & Hosting or AAD[+H]… that is until marketing gets involved.

Essentially with a few improvements to the app provisioning process, when an app is installed, it calls this new thing I propose called a deployment service. This deployment service would be responsible to provisioning the RemoteWeb. What’s great about this option is that we can have 3rd party deployment services that customers or ISV’s own, provisioning resources to Microsoft Azure, AWS, the Google Cloud, IIS on-premises, Apache… you name it. But even better, Microsoft could implement one for Office 365 to bring back the exact same functionality to Office 365!

How Was the Proposal Received?

Like I said above, the context of the event was wrapped up under an NDA because it was at the MVP Summit. The discussion that came out of this is questionable if it’s NDA or not… so I’ll play my cards safe here and just say the following: I walked away very excited that the level of interest (not lip-service) that I had with the SharePoint & Office 365 guys after this discussion and in the emails that have followed over the last few weeks.