With Serverless computing you are only charged for services when you are using them unlike PAAS and IAAS where the cost is a flat monthly amount for the reserved compute power. This can provide a significant cost savings for many scenarios. Up until recently, serverless services in Azure were only available for Azure Functions and Logic Apps which are essentially for back end services. Typically when provisioning the Azure infrastructure for the application, we deploy the web app to an Azure App Service Web App that is PAAS. This provides a number of advantages over IAAS but still requires reserved compute power while it is running.
Single Page Applications (SPA) have grown in popularity due to the rich desktop like experience they can offer. These applications are simply downloaded to the client and completely run within the local web browser. Essentially the Azure App Service web app resource is used to download the application but nothing is run server side and simply is used like a blob storage container. Workarounds have been used over the years to try to use a blob storage container to host these but lacked a couple key features to truly provide this functionality.
Microsoft just recently announced the public preview of the Static websites feature in Storage accounts. This provides the ability to host static web applications in storage accounts that now offers serverless capabilities to host these SPA applications without requiring a full server side resource hosted. This provides us the option to choose serverless for the front end and back end.
Static websites include a number of key features that are important for hosting your SPA application
- Custom Domains
- VNET support
- Default page setting
- Can be combined with Azure Function proxy to take advantage of additional hosting features (see below)
There are some limitations of this feature that require specific configuration and hopefully additional capabilities will become available as it gets closer to GA.
- Requires GPv2 standard storage accounts
- Only one static web site per storage account
- The VSTS Azure File Copy task doesn’t support the static web sites yet. This will be available soon. (see below)
To use static websites, create a Storage Account using Storage V2 (general purpose v2)
Next enable the static website feature and configure the static website container and type in the default page (usually index.html). Notice the primary endpoint is your public URL.
Upload the static “dist” output files from your favorite SPA framework like Angular or React through the portal or using the Azure Storage Explorer.
Deploying through VSTS
As I mentioned above, the Azure File Copy task doesn’t yet support the $web container. The change has been made and will be deployed out to the accounts over the next couple weeks. I’ll update this as soon as it is available.
UPDATE – 8/15/2018 – Azure File Copy task has been updated and the example below works in VSTS.
By default the static website has different fully qualified domain name than the backend azure functions. By using a custom domain, the two can share the domain name but have different subdomain like
https://app.myapp.com and https://api.myapp.com
However, they can’t have the exact same domain.
In my example, the web app is
And the API is
With Azure Functions Proxies, the proxy can route the traffic to the two different backend URLs. Both entries required or the “web” route would get all of the traffic.
The Azure Function can provide more functionality that just routing to the storage account. Many of the features available in Azure Function Apps can be leveraged for the static website through the proxy. Azure Functions features like IP Restrictions and EZ Auth are now supported, all serverless.
So if you are using serverless Azure Functions already with your SPA applications, this is a great addition and should provide significant cost savings for hosting your static websites. I’ll continue to update this post as the feature advances during the preview. If you have any questions or comments, reach out on twitter at @mikedouglasdev.