5 minute read

Azure has several options for hosting your web application. We’re going to use an Azure Static Web App because we just need a simple website without a lot of bells and whistles right now. This post will go over Static Web Apps but also do a quick explainer of why we’re picking this one and what other options we’ll use down the line.

What Is a Static Web App?

An Azure Static Web App is a web hosting service designed for hosting your static web applications. For our example, we’ll be deploying the most literal understanding of a static website, which is just a plain old HTML file.

One cool thing about a Static Web App is that it comes with a free API backend using Azure Functions. We won’t be using the Azure Function part in this deployment, but I want you to know it’s there.

If you’re not a web developer, terms like “static” and “API” can be confusing, so I tried to untangle it here.

Why Use a Static Web App?

Good question. Azure has several options when it comes to hosting web services. We’re using a Static Web App for the following reasons.

  • It’s free as hell!
  • It supports HTTPS and we want to look professional here, folks.
  • We’re not deploying a container, so we need a solution that supports containerless.
  • We don’t need (that is, we’re not willing to pay for) high-availability at this time.
  • We’re deploying a static website and don’t need the complexity of the other offerings (I mean, Static Web App does have “static” in the name).

How Do I Upload My Web Content to This Site?

It doesn’t work that way, buddy. This is the year 2024 and we don’t upload things anymore. We’re going to deploy our code directly from GitHub. It’s going to be so much fun!

This is what I like about this workload as the first project in our guided tour: it hits all the highlights of DevOps. We’ll be deploying the infrastructure and then deploying our application to it. We’ll even make a change to our app and deploy that. Most of our future projects will be infrastructure-only (meaning no applications), so this one is pretty meaty to start out with.

Here’s a high-level overview of what we’ll be doing:

  1. Deploy an Azure Static Web App resource (infrastructure)
  2. Push our website code to a new GitHub repository (application)
  3. Deploy our application code from GitHub to the Static Web App with GitHub Actions (CI/CD)
  4. Update our application code and redeploy (general DevOps)

You’ll notice that we’ll deploy the website code after we create the Static Web App resource. So you may be wondering what is on that website before we deploy our app to it. Azure puts up a temporary website that looks something like this:

initial temporary Azure Static Web App website
This is the default Static Web App site as of 2024. If your customers see this, they’ll know you’re an amateur.

You may also be wondering what the URL is for this site is. Well, Microsoft makes one up for you as a subdomain of azurestaticapps.net. That’s why this example has the silly URL of delightful-rock-088a1930f.5.azurestaticapps.net. You can’t change that, but you can add your own custom domain that you own, which we’ll do in the next service, so stay tuned.

What Other Web Solutions Does Azure Have?

Here are the other web services that Azure offers, in case you’re interested.

Service Description
Azure Blob Storage Azure Blob Storage is a way to store digital objects (aka, files). If those files happen to be static web content, you can turn the blob storage container into a website.
Pros: very easy to configure
Cons: charge for storage (usually inexpensive); cannot use custom domains for HTTPS; must use advanced reverse proxy services for anything beyond the most basic site
Azure Static Web App An Azure Static Web App is a web server for static web content. No code is executed on the web server, so this is generally used for front-end web services, but it includes an Azure Functions instance for a back-end API.
Pros: free for non-commercial sites; reasonably-priced for production sites; includes Azure Functions for API; no reverse proxies needed if redundancy not required
Cons: not usable for server-side rendering
Azure Virtual Machines Like almost any Azure service, you can always run your workload on a virtual machine. You can spin up a Linux or Windows VM and install your choice of a web server (Apache, Tomcat, IIS) and away you go!
Pros: full control over your web server’s compute environment
Cons: more difficult to manage
Azure Spring Apps* If you are a Java developer using the Spring framework, you can deploy your apps to the Azure Spring Apps service without having to manage the infrastructure. (Full disclosure, I probably won’t ever do a post on this, even though I was a Spring developer for my first year out of college.)
Pros: no need to manage server infrastructure
Cons: only supports apps developed using Spring (not really a con, but I need to put something for “cons”)
Azure App Service* An Azure App Service is a full web hosting service for websites, web applications, and REST APIs. If you’ve developed your web application as a container, it supports hosting your containerized app, too, known as Web App for Containers.
Pros: can be used for front-end and back-end web applications; can integrate into your private network for access to resources such as databases; support for almost any modern language; support for containers
Cons: more complex than static web solutions; limited control over container management
Azure Container Instance* If you’ve developed your web application as a container, you can deploy your app to an Azure Container Instance. This offers the least amount of container orchestration and is designed for deploying a single container without much in the way of high-availability. This works best for low-priority internal apps that can tolerate downtime.
Pros: easy to deploy container
Cons: designed for general-purpose containers, not specifically web applications
Azure Container Apps* Azure Container Apps is a service to host your container application without having to know Kubernetes. This uses Kubernetes under the sheets, but provides a simpler management layer. You can think of this as “Kubernetes-light.”
Pros: no need to manage Kubernetes
Cons: cannot fine-tune container orchestration
Azure Kubernetes Service (AKS)* If you’ve developed your web application as a container and require more management than is offered by Azure Container Apps, you can use AKS for the full Kubernetes experience.
Pros: can allocate more resources to your containers
Cons: more complex and requires knowledge of Kubernetes

* Supports containers

For more information about all these confusing offerings, Microsoft has comparison pages for web services and container services.

Let’s Get Started

To start working on this service, head over to the first procedure to set up and clone the repositories you’ll need. If you’re new to all this, check out the the Things to Know About This Project explainer for some helpful background.

Updated:

Comments