Knocking on Azure's Front Door

The ability to create global scale web applications using Azure infrastructure and services has existed for quite some time, but has traditionally been complex to setup and manage with creation of both global, and region resources. With the go-live release of the Azure Front Door (AFD) service, this just got a whole lot easier.

In this post, we will walk through the key features of AFD, compare to pre-AFD approaches, and deploy an interactive example to demonstrate the core functionality and highlight the simplicity in which the service can be configured.

Before Azure Front Door…

Before we jump into Azure Front Door let’s have a quick re-cap of the key global and regional services that are traditionally used to create a globally distributed application.

A Global Service is something that spans all Azure regions. A Regional Service is something that must be provisioned in each region the functionality is required.

In the pre-AFD world, a global deployment may look something like below, with Traffic Manager providing the global traffic management, Application Gateway performing SSL offload and WAF capabilities, Kubernetes for hosting, and Multi-master CosmosDB as the global data store.

For this post, we will not cover the CosmosDB or Kubernetes parts of the above, instead focusing on the network, security and routing based components. As a quick summary, below are some of the core Azure services used to create a globally distributed application.

Azure Traffic Manager (Global)

Traffic manager is a DNS based global load balancing solution that utilises DNS resolution to distribute traffic across multiple back end based on configured profiles. Since it is a DNS based solution application / path-based routing is not possible.

One of the key limitations to this service is that the failover time for a client is at worst the Time-To-Live (TTL) for the DNS record. Typically, this is set to around 5 minutes, but in some cases may be configured to a much higher value.

Azure Application Gateway (Regional)

Application Gateway is a Layer 7 HTTP reverse proxy, with optional in-built basic Web Application Firewall (WAF) and SSL offloading capabilities. Because the service runs logically as a virtual appliance, there are some limitations such as, they must be deployed within a virtual network, and therefore must exist within one region (version 2 enables zone-based support).

Azure Load Balancer (Regional)

The Azure Load Balancer core to the Azure Network functionality, and supports both internal and public IP based endpoints. The functionality runs at Layer 4, meaning it can support any workload that runs on TCP or UDP. This also means that application / path level routing is not possible.

So, what is Azure Front Door?

In simplest terms, the Azure Front Door is service that provides pieces of the above functionality (and more), all managed within the one product. The AFD service also moves functionality that has been traditionally deployed at the Regional level (application routing, WAF, etc) to the Global level, significantly simplifying deployment configurations in each region your application exists, and avoiding a lot of the complexity in keeping configuration across multiple disparate replicas / deployments in sync.

AFD also utilises the Microsoft Wide Area Network (WAN) to accelerate and route your traffic from the closest of 130 AnyCast edge nodes around the world to an instance / replica of your service based on routing rules. What does this mean? Your application should get a network level speed boost out of the box! Not bad for starters!

Taking the same application we discussed above, and swapping to an AFD based architecture, the simplification to the deployment architecture is evident with the removal of the Application Gateway. Also of note is that AFD is inline to the request, that is, requests travel through it, compared to Traffic Manager which performs its function at the DNS resolution stage of the request. This inline approach is one of the reasons that Front Door can perform the tasks of what was traditionally solved by multiple components.

The following is a high-level mapping of the Azure Front Door capabilities to the traditional approach for comparison purposes. It is worth noting that the choice of approach is not always one or the other, for example, in some scenarios it may be valid to have Azure Front door use an Application Gateway as a backend pool.

What’s the catch?

With the AFD service being a new public offering, there are a few things to note in deciding if and when to make use of the service, some key points are:

1. Back end pools (i.e. where front door sends traffic to) must have a publicly accessible IP address or DNS name. To access non-public end points, an Azure Load Balancer / Application Gateway / API Management instance etc will need to be utilised to act as a gateway. Guidance for locking down access to only Front Door traffic is documented here.

2. Custom error pages are not yet supported. In the event that no back end pools respond, generic errors will be displayed, this may be an issue for brand sensitive organisations. The good news is that it is a planned feature, but please up vote it if you need it.

Let’s try it out

The following demo has been designed for you to follow along with, the only thing you need is an Azure Subscription (or trial).

We’re going to use Azure Container Instances to deploy a simple website into three different Azure regions (Australia East, West US and West Europe). The website deployed is the http-echo container, configured to return the location the container is deployed into. The use of container instances is to simulate each deployment / replica of a deployment across regions in a simple way for demonstration purposes.

ARM templates for the demo can be downloaded or deployed from here.

To get the URL for the Azure Front Door, navigate to the Front Door instance in the list of resources, and take note of the ‘Front End Host’ value, this will be unique for your deployment, but will take the form of https://<AFD Name>.azurefd.net.

You can now navigate to the front door you have just provisioned, and see a result of where your request has been served from, as an example:

Hello from australiaeast

You may notice if you refresh a few times initially the result you will see returned change, then stabilise to one region. This is typically related to the original health checks being performed to calculate performance characteristics of different routes.

Try using https://www.locabrowser.com/ to test requests being sent from various locations around the world, and see how the AFD routes those requests, or try stopping the container to simulate a region outage see the time it takes for Front Door to route to a different end point (should be less than a minute with the demo configuration).

Don’t be afraid to try out different scenarios and routing configuration for Front Door in the portal, you can always delete the resource group and deploy the demo again if things stop working!

Wrapping Up

We’ve seen how the new Azure Front Door service compares to, and complements the existing Azure services to help you deliver performant web applications at a global scale. The elevation of resources from Regional to Global scope is one of the key benefits in using the AFD service, and as seen through the demo, can simplify the application architecture and ongoing environment management.

AFD looks to be key platform of choice in the future, and we look forward to hearing and seeing what you achieve with it!