Increasing Performance and High Availability of Web Apps with Azure Front Door Service

If we are developing a global(multi-region) web application on the cloud and also want the application should have better performance, scalable and highly available, so we need a good application entry point.

In this context, Azure Front Door Service, is a web application entry point that Microsoft has been using for a long time in topics such as scalability and security, meets our needs.

For Azure Front Door Service, we can say that is a global web application acceleration platform that performs routing operations together with capabilities such as WAF(Web Application Firewall) and CDN by considering the concerns of our global web applications such as performance and high availability.

So, how does it help the application performance?

Azure Front Door minimizes the round-trip time that the end-user spends on the network while trying to access the application and directs the end-user to the nearest and fastest backend pool. To do that, it uses the Anycast protocol.

Front Door directs incoming traffic to the fastest and most available point in a resilient way same like how a CDN directs incoming traffic to the closest point.

To provide these, it uses the Microsoft Global Network infrastructure. In this way, it provides better network performance and reliability.

NOTE: Microsoft has a high capacity private global network that it is using among its own datacenters.

Some core features

• As we mentioned above, it significantly increases the application’s network performance.
• It provides automatic and fast failover by monitoring the application in terms of latency and availability with smart health probes.
• It supports microservice architecture with its URL-based routing feature. It allows us to perform the routing operation of the traffic according to the path of the request easily.
• With SSL termination capability, it saves application backend from the encryption and decryption cost.
• It allows us to keep the user session in a specific application backend if we need it.
• It also provides custom Web Application Firewall (WAF) rules and DDoS protection to ensure security.

So, how can we use it?

To be able to demonstrate Azure Front Door, first, let’s create an Azure Web App in “West Europe” and “UK South” regions as follows.

Then, let’s create and deploy a simple ASP.NET Core Web App project, which contains the information on which location the application is located, to the related Web App.

If the deployment process has been successfully completed, we can pass to the Front Door creation step.

First, let’s go to the Front Door creation menu through Azure Portal and select the relevant resource group in the “Basics” tab, then switch to the “Configuration” tab.

In this tab, first, we need to create an entry point to our application. To do that, let’s create a host like below by clicking on the + symbol in the “Frontend hosts” section.

Now we need to create a backend pool. To do that, let’s go to the screen below by clicking on the + symbol in the “Backend pools” section.

In here, let’s give a unique name to the “Name” section. Then let’s click to the “+ Add a backend” button, which takes place under the “BACKENDS” header, to be able to add relevant backends.

Here we need to select the “App service” option as a “Backend host type“. Then, in the “Backend host name” section, let’s select the relevant App Service we have created before.

NOTE: We need to perform this operation one by one for each relevant App Service that we want to add as a backend to the host we have created.

The parameters that we need to pay attention here are the “Priority” and “Weight” parameters.

• With the “Priority” parameter, we can specify which backend we want the traffic to be directed.
• With the “Weight” parameter, we can specify what percentage of traffic we want to be directed.

At this point, if we set the “Priority” parameter to the same for all backends, the traffic will be directed between the backends according to the “Weight” parameter.

After configuring the parameter, let’s complete the add operation by clicking the “Add” button.

After adding the backends in both regions, let’s leave the “HEALTH PROBES” and “LOAD BALANCING” sections with their default values.

• In the “HEALTH PROBES” section, we can configure the interval time of the probe requests which required for the Front Door to check whether the backends we have added are healthy.
• Also in the “LOAD BALANCING” section, we can specify extra parameters to support health probes.

Now we can start to define routing rules. To do that, let’s click the + symbol in the “Routing rules” section and configure it as follows.

In this screen, basically we are performing the route mapping operation. With the above values, we have provided that every request, that will come to the root URL, will be directed to the backend pool which is named “mytodoapp-bpool“.

You can find more detailed information from here.

After these operations, let’s complete the creation of the Front Door operation by clicking the “Review + create” button.

Test and Conclusion

To be able to perform an example with Front Door, we have deployed two Web App on Azure to “West Europe” and “UK South” regions. Then we have created an Azure Front Door service, which will be an entry point to these Web Apps.

As an example, our expectation from the Front Door is that it directs us to the nearest, fastest backend pool, and also to perform the failover operation in case of any errors. Of course, this failover operation is also important for regional maintenance operations to be able to perform it with zero down-time.

Let’s access the application via the Front Door address in order to test it. Since I’m living in the “West Europe” region, Front Door must direct me to the backend which located in the “West Europe” region.

As expected, FD directed me to the closest point.

Now, let’s change our location to the “UK” region with any VPN tool and enter the site again.

As we can see, this time FD directed me to the backend point which located in the “UK South” region. Just like using a CDN for assets.

Now, to test the failover scenario, let’s turn off the VPN (if you are in the “West Europe” region) and then stop the Web App we created in the “West Europe” region.

This time, FD must direct us to the “UK South” region which is healthy.

It directed us to the healthy “UK South” region as expected.

Apart from these, it is also possible to watch live metrics with Application Insights service. In addition, by configuring the WAF feature, we can also perform operations such as rate limiting or geo-based access control.

References

https://docs.microsoft.com/en-us/azure/web-application-firewall/afds/afds-overview?WT.mc_id=AZ-MVP-5003382
https://docs.microsoft.com/en-us/azure/frontdoor/front-door-overview?WT.mc_id=AZ-MVP-5003382
https://docs.microsoft.com/en-us/azure/frontdoor/front-door-routing-architecture?WT.mc_id=AZ-MVP-5003382
https://docs.microsoft.com/en-us/azure/frontdoor/front-door-backend-pool?WT.mc_id=AZ-MVP-5003382