I've always been a huge advocate for (and fan of :) ) serverless apps. People often misjudge the concept: serverless doesn't mean that there is no server. I mean, what else would serve requests for the relatively primitive client side? There is a server. Maybe there is even a web server like IIS or Apache involved (but if you want a cool solution, there isn't, or it is abstracted away so far that you can't see even signs of it). And to be clear, no means no. Not just like in a PaaS setting where everything is made easier.

How is this possible? Well, just look at all the amazing Azure services that can help you with that: Azure Functions can give you a really nice platform to run a piece of simple C# code (to be fair, there is a web server behind that, but it is abstracted away pretty well). Azure blobs can help you store assets, CosmosDb can store business data and gives you a ready-to-be-used API that goes very well with Javascript. Other things like Azure Redis or Azure CDN can help you with caching, there are all sorts of crazy network-configuring services. You can add e-mail sending with Azure Functions and SendGrid, you can solve authentication with Azure App Service Authentication. Note that none of these requires you to write any infrastructure code, you just have to write the basic business logic. And this is awesome :)

But there was one thing that you couldn't do before: the actual hosting of web applications. Even if you put everything that needs a runtime to PaaS services and all that's left is static html, css and js, you have to host it somehow. Sure, you can upload it to an Azure Blob account. But for blobs, there is no "default document", like for web server based sites. So if you want to view the index.html of a site, you have to explicitly make that part of the url. And this is not cool. Or at least, it wasn't :) (Note that you have to specify the container also, but there is a special $root container that can be addressed by the url of the Storage Account itself).

This summer a new feature was introduced to Azure Storage Accounts: Static site hosting, aimed at solving this issue. Note that the blob storage had already been well-suited to host static sites before with the exception of the "default document" problem (and there's no automated error handling, like there usually is in web servers, but since you are only serving static content, that's not a big deal). You can simply enable this feature from the portal:

When you enable this feature on a Storage Account (it has to be a general purpose V2 account), three things happen:

• A special $web container is created.
• You can specify a default document and a 404-page for this container.
• A special url is created that refers directly to this container.

And that's it :) Now you can upload any content to this container and it will be served from the storage account serverlessly. Nice.

Note that the feature is still in preview and there are some things that are not so comfortable compared to an App Service Plan. You cannot assign custom domain names directly, you have to setup a CDN first. There is no built-in continuous delivery or backup like there is for App Services. But you can also use the built-in blob features, like snapshots, so that's a plus. There is no built-in scaling, but you have some control over how fast content is served with the usual blob settings (Standard vs Premius, Hot vs Cool). All in all, it is not an all-inclusive way of hosting a website, but given it's low price, I'd say it's definitely worth looking into when deciding on a hosting solution for static content.