Static websites on Azure as a market penetration strategy

This article was originally published on PumpITup blog.

Following advice of several Microsoft employees on how to save money by hosting a static website in Azure almost for free, I discovered the depths of vendor-lock / market penetration strategies in public clouds (Azure is just an example, same patterns can be applied everywhere).

Initial idea

I have been hosting websites for more than 20 years and until now it has always been cheaper to have the smallest VM in whatever datacenter with some web server, preprocessor and database. 20 years ago it was either Apache, PHP or MySQL. Lately, Apache has been replaced replaced with nginx and MySQL with MariaDB and “only” PHP survived.

There are two reasons why I’ve decided to move on to a static website in Azure:

• Website architecture has shifted: instead of preprocessing on server side, things are either done on client-side or in regular backends (usually wrapped using some bff layer).
• My last provider Wedos did not offer me a discount for a renewal. Also, it appears that for the first year in history, their prices for IaaS are higher than 3 years reservation on Azure (did not check all tiers, talking about the smallest ones). Sad story.

I’ve also compared Azure with AWS, Google and Blue Ocean; Azure offers lowest costs for simple VMs (without any enterprise discounts).

Microsoft push using bloggers

There is a number of tutorials on how to host static websites on Azure (almost for free):

• Hao Luo — 2017
• Tomá? Kubica — 2019 in Czech only
• Vuka?in Terzi? — 2020
• Rolf Schutten — 2021

And, the official tutorial!

I was confident, following their step-by-step guidance, I’d be finished in 15 minutes.

I surely didn’t think I’d end up writing an entire blog post about my experience.

The blob storage trap

It strikes me that Microsoft promotes the idea of using Blob storage for static web hosting so much when only after a few minutes anyone must discover that Blob storage alone does not work at all:

• The website is published under some crazy subdomain
• Redirection from other domains is possible but only for http ??
• Files might be served without the right content-type ??
• Azure blob storage alone does not service index.html as index files ??

Luckily, all these issues have an easy solution: I need to purchase an Azure CDN service that allows custom domains, solves the index files and the content type.

I’m checking the price and it’s not for free ??. But it’s acceptable, so, let’s go.

The CDN trap

CDN is usually not needed for presentation sites where you do not care about latency that much. But it’s an interesting idea to try out if costs remain below the VM solution.

After purchasing the CDN, the next step is to bind some custom domain to the target blob storage host. And boom, a new blockers appears:

• Configuration of the CDN is done on something called external portal that really looks like a low-cost firewall appliance and Terraform will never talk to that ??
• Even when digging through the external portal it appears that Azure CDN does not allow url-rewrite using regexp ??

Why do we need url-rewrite with regexp? It’s to handle the issue with index files (index.html) not being served automatically; you don’t want to create a separate rule for each subfolder.

Luckily, there is a way around it: using the Azure Verizon Premium CDN that allows regexp in url-rewrite.

I’m checking the price and it’s not for free ??. But it’s acceptable, so, let’s go.

The Verizon CDN trap

At this stage, we are a little further from the initial idea to host a simple static page, but it does look professional, so I decide to continue. It comforts me that I haven’t been completely alone in this:

• Anthony Butcher
• Stackoverflow

While the Azure CDN external portal was a surprise, this time it’s a full escape game. They say it’s version 4, so I guess we need to wait until version 12 at least, to get something that would not make me write a dedicated paragraph here.

I find a field that looks like the url-rewrite pattern, I put my magic regexp from Stackoverflow: [^?.]*(\?.*)?$ and…

Error: Does not respect the mandatory format xyz (basically an url prefix).

Then I see the magic sentence:

To activate regexp in url-rewrite please contact sales.

??+??

It’s clear: Microsoft basically does not want you to use blob storage for static websites. So what is next.

I re-read carefully their tutorial, and then it all makes sense now:

(…) if these features are important for your scenario, consider using Azure Static Web Apps.

So basically all my previous effort was just to get up to speed, and now we can start over. The only real solution is to use Static Web Apps.

You know the drill by now. I’m checking the price and.. magically it’s free ??, let’s go.

The StaticWebApp traps

To use StatucWebApp you just need to upload the site with some metadata but using tasks in Azure Pipelines or in GitHub Actions does it for you. The good point is that the same task also allows to build your static site. It even auto-discovers the used framework (in my case Hugo) so it’s almost zero config.

After a few minutes of creating and tweaking the pipeline, it’s all uploaded and published.

We are done!

Well, not just yet:

You do not know the IP address of your app, and DNS CNAME is not possible at root level, so you need a 3rd level domain. ?? ???

Ok, I hate enforcing www.*. Wasted effort??

Microsoft has again the right solution. You buy another service to host your DNS on Azure, and then they can handle (probably using the A/AAAA records).

I’m checking the price and.. well, it is not free ??, still acceptable though, so, let’s go.

Is there any other trap?

I must admit that integration between the DNS Zone and Static Web Apps is great. You can directly select your app in the DNS configuration. As if somebody has thought of that.??

After moving the DNS records and binding the root record to the Static Web Apps instance, everything finally works.

Finale

I’ve spent 3–4 hours on this. Compared to the initial estimate of 15 minutes it remains in the range of a “typical IT project estimate accuracy”. That’s great!

Even though there’s unexpected costs, it’s still acceptable: the content is basically free and DNS records hosting will be about half a buck per month. This is still 4 times lower than a custom VM.

So, where is the catch? Well: you are hooked. Look at that, did you see the 2 other charts about services you have not purchased yet?

Would you like to look at empty charts for the rest of your life? Or will you try Azure Functions with the first form2email webhook needed for your newsletter registration form?

Only then you will have all what you need for any size of app:

• Static content including e.g. some frontend javascript app
• Deployment pipeline that does it all
• BFF with Azure Functions
• Monitoring all-in-one

Did I mention that each of those features is going to be another service with a price tag?

A bit of philosophy

For long, the fundamental theorem of software engineering has been:

We can solve any problem by introducing an extra level of indirection.

With public clouds it becomes:

We can solve any problem by purchasing an extra cloud service.

And this is where we are going… vendor lock in all cases.

Bloggers paid by vendors are just part of the game.

Conclusion and additional notes

To be clear, Azure proposal for static web hosting is, in fact, excellent.

At the same time, it’s obvious that Azure product managers have worked hard as a team to direct any newcomers from the LAMP era to the right services. We can guess that the same applies to any other areas. At the end, it’s just about money.

Just a few notes:

• This is not a sponsored blog post. It’s part of our PumpITup marketing to write about what we do and how we think ??
• There are generic ways how to limit any vendor lock mentioned above, let’s discuss it another time.