Autohosted Apps are Dead…Big Deal!

  • Article

When Microsoft introduced SharePoint’s Application Model, they released a preview hosting option called "autohosting". Autohosted apps were exclusive to SharePoint Online and allowed developers automatically provision websites and (optional) databases in Windows Azure on-demand. Developers didn’t even need a Windows Azure account...everything is provisioned automatically in a Microsoft-owned Azure tenant. In my early app work, I made heavy use of autohosted apps. I even presented the very first autohosted apps session at the 2012 SharePoint Conference. However, it didn’t take long for me to gravitate to provider-hosted apps and abandon autohosting completely. Last week, Microsoft announced an end to the autohosted app preview. As such, I thought I’d provide my top-10 list for why autohosted apps are inferior to provider-hosted apps:

  1. Preview Feature
    Autohosted apps were always offered as a preview feature for SharePoint Online. Some preview features eventually become "official", but all are subject to change or sunset with little notice. Autohosted apps ultimately didn’t make the cut. After June 30th, developers will not be able to create new autohosted apps in SharePoint. Developers are encouraged to convert existing autohosted apps into provider-hosted apps, which is extremely easy to do.

  2. GUIDs for URLs
    All autohosted apps are deployed to a Microsoft-owned Azure tenant. Each autohosted app is assigned a GUID host-name under the o365apps.net domain. You cannot pick a host-name…you get a GUID. Seriously, who wants an app URL that looks like https://8e3b69b8-afe2-4b9a-a290-9c82cac2a050.o365apps.net???

  3. Tenancy Isolation
    Unless you leverage centralized app deployment, each install of an autohosted app will provision an isolated website and optional database (see figure below). This isolated tenancy might make sense for many apps, but other apps might need data to persist across sites (ex: Helpdesk tickets). Although not impossible in autohosted apps, it can be difficult to achieve given the default tenancy and scalability of autohosting.

    Figure 1: Default Autohosted Tenancy

     

  4. Not Scalable
    Autohosted apps are provisioned as small websites in a Microsoft-owned tenant of Windows Azure. You have NO ability to manually tweak these websites, including scaling them for more users/traffic. As such, Microsoft has been clear that autohosted apps weren't ideal for high-traffic or organization-wide solutions. They were designed to deliver team solutions for up to ~250 users.

  5. Painful Upgrades
    The remote web in an autohosted app is deployed automatically when the app is installed into a SharePoint site. Developers do not have direct access to this Azure website. Upgrading an autohosted app can only be achieved by deploying a new version of the app through the app catalog. Once the user accepts the new app version (required to get the update), a background process will take a full backup of the website (and database) and TRY to apply the update. The lack of upgrade transparency and flexibility is a big pain point of autohosted apps (imagine database schema updates). With a provider-hosted app, I can update my web project in seconds without my tenants having to do anything (they might not even know an upgrade occurred).

  6. Online Only
    Autohosted apps have always been an exclusive hosting option for SharePoint Online. Targeting only SharePoint Online customers greatly limits the reach of an app and neglects numerous potential on-premises customers. With very little effort, the same provider-hosted app can target both SharePoint Online and SharePoint on-premises.

  7. Developer Flexibility
    Autohosted apps offered no flexibility in hosting. You get a small Azure website with no ability to configure or manage it. This greatly limits the flexibility of the developer in using other platforms (ex: PHP, Ruby, etc) or even advanced .NET technologies. For example, Vesa Juvonen recently wrote a great post about delivering connected app parts using SignalR. Unfortunately, SignalR requires a special setting on the Azure website that you cannot configure with autohosted apps.

  8. Heavy Packaging
    An autohosted app package (.app) contains a compressed zip file with the entire web project (including all project assemblies and assembly references set to copy local). SharePoint uses this package to "auto" deploy the web assets to Azure each time the app is installed into a SharePoint site. Although this isn’t horrible, I’m not a big fan of uploading assemblies (read: intellectual property) to an app catalog that the entire organization likely has access to.

  9. Questionable Licensing
    Since autohosted apps have always been in preview, their licensing has always been in question. They are hosted in a Microsoft-owned Azure tenant, so what do they cost me as a SharePoint Online customer? How many autohosted apps do I get in SharePoint Online? Will it be licensed by the app, the app install, or the user? Too many licensing questions for me to be confident doing any significant development with them.

  10. False Sense of Ease
    Many people (including me) were attracted to autohosted apps given their (perceived) ease of hosting. Right-click project > deploy > DONE! You never had to mess with Azure or a hosting web server. However, Azure websites (which were also in preview when autohosted apps were announced but now "official") are incredibly fast and easy to provision and deploy to. In fact, I can create a new Azure website and publish a provider-hosted app in about 15-30 seconds. Ultimately, a provider-hosted app deployed to an Azure website is about as easy as autohosting promised. However, the provider-hosted option doesn’t have all the limitations outlined in this article.

Hopefully this top-10 list will make you feel better about autohosted apps going away. Provider-hosted apps provide the ultimate in flexibility/scale and are the way to go for SharePoint extensibility!