If you aren’t part of the solution, you’re part of the problem.
In this article I’m going to lay out my idea for how Microsoft can re-implement and re-launch the cloud app model option of creating autohosted apps for SharePoint 2013 and Office 365. Everything outlined in this article will work in both SharePoint 2013 on-premises installations and Office 365.
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.
Introducing my Proposal - Automated App Deployment & Hosting
This is the bulk of what I proposed at the MVP Summit. Essentially we bring back autohosted apps. I call my proposal the Automated App Deployment & Hosting… 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 & other related assets defined by the app developer. Who makes the deployment service? What I envision 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!
Key Concepts to Automated App Deployment & Hosting
There are a few key concepts to this idea:
- Full parity between Office 365 & On-Premises: Yup… this isn’t like autohosted apps that only worked in Office 365… this will work in all deployments.
- App package includes extra ‘widget’: More on this later when I get into the implementation, but this is a XML file in the root of the
*.appfile. - Allow customers to opt-in or opt-out: You don’t like it and want more control? Then at your tenant or site collection or site, you can elect to use or block this capability.
This concept also addresses some of the autohosted app shortcomings. For instance with autohosted apps, you did not have any control over the URL of the RemoteWeb but with this, since you can control the deployment service, you have full control over it. Also unlike autohosted apps that limited you to only ASP.NET technologies and Azure websites, you can use any technology or infrastructure you choose; this includes using the full Azure stack whereas before you could only leverage Azure websites and Azure SQL Databases.
Most importantly at least to me is that this will give customers control over their deployed instances. This is because a deployment service implementation could use the customer’s Azure management certificate (or AWS equivalent) to create the RemoteWeb in their own Azure subscription. Further, if Microsoft implemented their own deployment service for Office 365, they could also allow tenant administrators to provide the Azure management certificate so Microsoft could deploy to the customer’s Azure subscription.
Process Flow Overview
Enough marketing speak… how would this work? Here’s a little picture that explains it:
Proposed Autohosted Process Flow
Looking at the UML sequence diagram above, let me explain how this would work, highlighting the new pieces.
The process starts by SharePoint / Office 365 noticing there’s a special deployment widget XML file in the *.app package. When one is present (or contains a specific value), it will [1] issue an HTTP POST with some context information about the site it came from, similar to the context token sent to the AppWeb when clicking on the app launcher tile on the Site Contents page. When the deployment service gets the request, it [2] immediately responds with a HTTP 200 telling the caller “I got the message and we will get to work.” The deployment service needs to have a queueing process to handle load balancing. [3] SharePoint / Office 365 then puts the app install status into a new state called AppInstallPending.
At this point the deployment service gets to work. It can use the widget that was provided in the *.app package to [4] fetch any assets it needs to create the RemoteWeb and related assets and then use those to [6] to create the RemoteWeb such as using the Azure management APIs to create a website with a specific URL or Azure SQL Database or storage account or… you get the picture.
The way I’d make mine work is to create a website that contains a deployment slot connected to a GitHub branch so as I updated that branch, a web hook would notify Azure to execute a GIT PULL to get the latest codebase for all deployed instances of that app without going through the SharePoint update process.
Finally the deployment service would [8] notify SharePoint / Office 365 that the app has been installed and tell it the URL of the RemoteWeb it created. The process would conclude by [9] setting the state of the app to AppInstalled just like we have today.
How can Microsoft Make this Work?
I had a few goals in coming up with this solution. First there could be no external dependencies that the SharePoint / Office 365 team had to take… in this case there are none. They can leverage something like Azure, but the don’t need anyone to do anything to make this work.
Second, I wanted to come up with something that I thought would have minimal amount of work on the SharePoint / Office 365 site to get this working. As such, there are a few things we need:
- App packages support a new top-level XML file: Just like we have with workflows in app packages, we need the ability to have the package contain a new file that will hold deployment service info. This can include the URL of the deployment service (or a list of available ones) as well as a name-value property collection that is passed along.
- Ability to dynamically set (ala late binding) the app’s start page: Because the process of creating the RemoteWeb may take time, this might need to be set much later than when the app install was initiated.
- New event - AppInstalling: Today we have
AppInstalledbut not an event that fires on the front end. This needs to happen at that phase… on the start of an app being installed. - New state - AppInstallPending: We need this to tell the user what’s up.
- Ability to call back to the host: This is for the deployment service to call back into the host to tell it the RemoteWeb has been installed and the URL for the endpoint.
Still with me?
Deployment Service Implementation
What will this deployment service I keep talking about look like? The signature of this isn’t all that complicated… the real complex part will be using something such as the Azure Management APIs to create the RemoteWeb and other stuff. Here’s how I see it form my point of view.
How Do We Get There? I Suggest the Following…
So… how do we get to this point? Well I suggest we start with an MVP, a minimum viable product… I’ll call this P1. Let’s see Microsoft add the things to the Office 365 platform to support this. Simply give us the things we ask for above in the section How can Microsoft Make this Work?. Don’t spend any time investing in tooling or new UX. Instead, just get the platform to support this and let some partners create some deployment services to test it out. The load won’t be placed on Office 365, instead it will happen where the deployment services are hosted (I suggest Azure, but I’m biased).
Once we’ve seen that work, let’s move onto P2. Let’s get a sample deployment service published to the OfficeDev group on GitHub so others can start building their own by looking at a sample… and then let’s go public! Let’s see it on the Office blog, let’s hear about it in podcasts and let’s get some prototypes of tooling improvements going.
And now we move towards production. In P3 I want to see administration settings and controls for tenant admins, site collection and maybe even site administrators to enable / disable this for their tenant.I also want to see fields where I can plug in my own company’s Azure management certificate. Why? Because I also want to see the Office 365 guys offer up their own deployment service that will deploy to Microsoft Azure for you!
Last but not least, in P4 we care about those who are on-premises. Maybe this doesn’t get included in an update but rather in vNext… but you should have this same capability!
One Last Thing
I’m not naive to think I know everything how the inner guts of how the app provisioning process with Office 365 & SharePoint works. I’ve learned about some challenges since I gave this presentation in talking to engineering. As such, I’m sure some of this proposal needs to be tweaked and go through performance & security reviews. I don’t have nearly the experience that the Office 365 guys have at running a massively scalable & globally distributed SaaS product. But with that being said, I don’t think we’re too far off.
What do you think? Leave a comment and let’s start a discussion!
