Azure Front Door is a powerful global routing solution that provides high availability and performance acceleration, among other features, for HTTP/HTTPS applications. The end users of the application are automatically routed to the nearest Microsoft “Point of Presence” (POP), and from there across the Microsoft global networking fiber to either a backend in Azure, or to the best “exit” POP for external (“Custom Host”) backends.
Blue/Green
Blue/Green (or Canary) Deployment is a methodology to introduce application enhancements to a small subset of end users, and if all goes well, slowly increase the ratio until all users are on the new deployment. In case things do not go perfectly, it’s simple to just stop routing requests to the new buggy backend. This is a much safer way to introduce code changes than just suddenly pointing all users at the new enhancements.
Azure Front Door makes Blue/Green simple. This article will explain how.
Frontend
Azure Front Door provides a nice configuration tool called “Designer.” It allows you to easily connect your frontend(s), backend pool(s) and routing rule(s) together. You essentially go through the Designer when you create your Front Door, but then you can use it later for configuration changes. Here is what it might look like after completion:
The first step is to configure the frontend.
The main item here as it relates to blue/green is “Session Affinity.” This determines whether the end user always gets routed to the same backend after first accessing the Front Door.
Whether or not you enable this depends on your application, and the type of enhancements being rolled out. If it’s a major revision you will likely want to enable Session Affinity, so that if the user is initially routed to the new codebase she will continue to use it. If the enhancement is relatively minor, for example involving a single page with no dependencies on other parts of the application, you could potentially leave this disabled. If in doubt, enable Session Affinity.
Backend Pools
This is where you configure the host(s) that will end up satisfying your users’ web requests.
In this example, I just chose two relatively-random public endpoints. You would configure your existing backend website and the new one under test. I divided requests between my two on a 75% to 25% split. You would likely send more traffic to the current website than the new one, and then likely direct more to the new one as it proves itself to be bug free.
Here is a screenshot of the definition of one of the two backends. Note the three parameters circled which, with one other, will be discussed in relation to how a configured backend gets chosen by Azure Front Door for a given request.
The following screenshot shows the two backends I configured as part of my backend pool. Note that the total of the “Weights” does not have to add up to 100 — I did that for clarity.
Note that how much traffic gets routed to a given backend also depends on other parameters, which is discussed in excellent detail in this section.
For the purposes of a simple Blue/Green configuration, here is a summary on how you might configure these parameters.
- Keep the backend under test disabled to start. Once you get all other parameters configured, you can enable it to start your Blue/Green testing.
- The Priority of both backends should be the same. I recommend just leaving them at “1.”
- As part of the Backend Pool configuration there is a section called “Load Balancing.” For the purposes of our discussion, the most important parameter here is “Latency sensitivity.” This value determines the highest number of milliseconds that a health probe can take for a given backend to be even considered for selection; setting it to zero disables the parameter entirely. I recommend you set it to a reasonably high value such as 500 (a half a second), meaning any backends responding in less than that time frame will be considered. The goal is to make sure both backends get used, as it’s possible they are in different data centers and present different latencies to the end user.
- Any backends making it this far are finally selected based on weight.
Routing Rules
For the purposes of Blue/Green, the routing rules are relatively unimportant. What you select here depends more on how your web application works.
That said, consider enabling “Caching,” which in essence turns your Azure Front End into a Content Delivery Network (CDN). This will allow web content to be cached and delivered from the Front Door POP rather than the backend. The POP is closer, sometimes significantly closer, to the end user than the backend. This can dramatically improve application performance.
This documentation contains full details on Azure Front Door routing if your configuration starts to get more complex.
Conclusion
Configuring Blue/Green with Azure Front Door is relatively simple once you understand a few vital concepts. Give it a try!