Ways To Use Azure Traffic Manager

In this post, I will explain several ways that you can use Traffic Manager, Azure’s website redirection solution, that enables high availability, fault tolerance, and more between different application deployments.
 

 

Azure Traffic Manager

Traffic Manager is a DNS-based redirection solution for endpoints. An endpoint is any public IP address that has a DNS name. Note that simple definition includes DNS-configure public IP addresses in Azure but also endpoints anywhere else, such as on-premises, AWS, Google Compute, GoDaddy, or anywhere else that you can host a web application with an IP address/DNS name combination.
The system is pretty simple:

1. A web application is presented to the Internet with a public IP address that has an associated DNS record.
2. You create a Traffic Manager profile in Azure. Note that the location/region is irrelevant because Traffic Manager is a rare instance of a global service.
3. When creating the profile, you select a routing method. This is how Traffic Manager will route traffic to endpoints (more later).
4. The Traffic Manager profile will have a Microsoft-owned trafficmanager.net DNS name. Configure your web application with a CNAME record pointing to the traffic manager domain name.

For example, www.joeelway.com (CNAME pointing to joeelway.trafficmanager.net) will resolve to my traffic manager profile, which in turn will resolve to the IP address/name of an endpoint depending on the selected routing method.
There are 4 possible routing methods:

• Priority: Clients are sent to one endpoint. If that fails, they are redirected to another.
• Weighted: Traffic is load balanced based on endpoint weighting.
• Performance: Clients are sent to the closest (latency) endpoint.
• Geographic: Traffic can be directed to specific endpoints based on its source location.

Those are all simple scenarios but in this post, I want to focus on some other concepts.
Remember, the endpoints that Traffic Manager don’t need to be in Azure. I know one Microsoft partner that uses Traffic Manager with a customer that has no other services running Azure. It only uses Traffic Manager to redirect to services hosted elsewhere. That partner once told me that the Azure bill was so small every month, it would cost them money to charge the customer!

Migration / Disaster Recovery

In a simple sense, both of these scenarios are identical. At one point in time, a website is running somewhere, such as on-premises, and later (planned or unplanned), it is running somewhere else such as Azure or another data center.

 
In these two scenarios, create a Traffic Manager profile with all traffic going to your production system. In the case of a migration, you can build up the new version of the system in the new location and test it independently of production.
When a disaster happens, you can modify the Traffic Manager profile to redirect to the failed over system. This could be the last step (Azure Automation runbook) in a recovery plan to failover to Azure or to another Azure region.
In a migration scenario, such as migrating to Azure, once all tests are signed off, you can switch users over to the new system by modifying the Traffic Manager profile. If you need to do a rollback, the change is simple: modify the Traffic Manager profile.

Blue-Green Application Upgrade

This scenario, similar in construction to above, was recently discussed by Microsoft in a blog post. Instead of a location migration, there is a simple change of endpoint to enable application upgrades. There are two implementations of the code, each with its own endpoint. Traffic Manager redirects to the old version of the code.
When testing has completed on the new version, there are a couple of strategies that you could use:

• Cutover: The redirection is replaced with a new redirection that points only to the new endpoint.
• Phased: The existing migration is switched to weight-based, with the new version of the code getting a small amount of traffic. The weights are gradually modified to give vNext more weight and vOld less weight as confidence in the new system increases until all traffic goes to vNext.

 
This solution provides a business with a safe way to switch between different versions of code. This is especially true if there are drastic changes, such as a switch from co-location hosting to Azure or a switch from Azure virtual machines to Azure App Services.

Layered

A Traffic Manager profile can use other Traffic Manager profiles as endpoints. This opens up some interesting scenarios. A “simple” one is illustrated below.

 
In this example, a global web application is shared using a single CNAME record that redirects to a top-level Traffic Manager profile. The illustration shows that the top layer redirects to two regional Traffic Manager profiles in Europe and the USA but this could scale out to many continents/countries. The top layer can achieve this redirection based on country or performance. The latter might be more successful if there are not country-specific requirements.
Within the European Traffic Manager profile, clients are sent to one of two deployments. I could have added UK/France regions here too or even non-Azure locations. Traffic is being sent either to North Europe or West Europe. The choice depends on whether you want active/active (weight-based) or disaster recovery (priority) deployments. The same solution is also deployed in the US regions.
We could make this a more complex deployment too. We could add the blue-green approach to each installation, adding a third layer.