Using Azure Front Door Service with App Services

Disclaimer: Cloud is very fast moving target. It means that by the time you’re reading this post everything described here could have been changed completely. Hopefully some things still apply to you! Enjoy the ride!

Azure Front Door Service is great service that you should be evaluating when building web applications. Read more about it from the documentation. I strongly recommend looking into it 😊.

Let’s take a look how you can use that together with App Service to build up multi Azure region application. Here’s our application architecture:

Azure Front Door Services demo application architecture

Our demo application has two web applications behind the Front Door. One in North Europe and one in West Europe. How end users then access the application? Well through the Front Door frontend host address (or custom domain if implemented). Here’s example:

End users view of the application (notice the West Europe region)

In above screenshot you can see that I have landed into the application which is hosted in West Europe.

What about if the user would try to access the web application directly? That won’t work since the web applications have been configured with access restrictions (only Front Door Service IP Range is allowed):

And if I now wipe out my West Europe instance Front Door will automatically move me to the North Europe instance:

End users view of the application (notice the North Europe region)

Let’s now look how to build this kind of solution. First of course we have our normal structure in our code repository (as I have been preaching for many many years 😊):

Front Door application source code structure

Under deploy folder we have our Infrastructure-as-Code assets and under src we have our application code. Other folders we can ignore in this example.

In order to have fast inner loop for your infrastructure development you should have really easy way to kick off the Azure infrastructure deployment. In our case it’s the deploy.ps1 under the deploy folder. It then calls the Azure Resource Manager (ARM) template deployment and passes those azuredeploy*.json files to that. It’s designed so that it has meaningful default values in the parameters so that it’s easy to use. To test the deployment I only need to navigate to that folder and login to Azure using PowerShell and then execute the deployment command. Here’s the content of the deploy.ps1 file:

Notice that in the end of the script I call the VSO commands so that I can further automate my deployments in Azure DevOps. Let’s come back to that later. Here’s example output from the command (notice that I didn’t need to pass any parameters to the script since the defaults are fine for me):

And of course I can then further iterate and improve my infrastructure and then run same software development practices (pull request & code review etc.) as for any other code change in my application.

My actual application was super simple Node.js app that you can execute locally just by npm start and see how it looks like:

Demo application running locally

Continuous integration setup in the Azure DevOps is pretty simple for this kind of application:

Front Door demo app CI setup

And same goes for the release definition of the application:

Front Door demo app CD setup

Only real automation in the CD pipeline is the use of variables in the Azure App Service Deployment tasks:

Azure App Service Deployment for the first application

and

Azure App Service Deployment for the second application

Those variables came from the deploy.ps1 when we used the VSO commands (as mentioned above).

We can view our ARM template deployment history in the Azure portal (including ongoing deployments):

ARM template deployment history in Azure portal

Deployment names in Azure Portal are exactly the same as our deployments in Azure DevOps release management so we can easily match these two:

Front Door app deployment history in Azure DevOps

Above enables end-to-end visibility since you can easily backtrack from Azure portal that what deployment is the last one and then look up more details in Azure DevOps.

Note: My demo app has quite aggressive health probe interval (5 seconds) so if you’re using Free tier from App Service you will go over the daily quota and Azure will stop your app services in that case.

You can change the health probe settings from the ARM template:

Health probe settings in ARM template

Health probe should anyway be more meaningful than just poke to the “/”. Maybe “/api/health” which then validates that the application is indeed healthy.

You can find the source code for this example from GitHub:
https://github.com/JanneMattila/118-FrontDoorApp

Hopefully you find this post useful!