Some months ago I’ve written this post describing an interesting solution we’ve deployed for a geo-distributed solution that involves Dynamics 365 Business Central SaaS, Azure Functions and Azure CosmosDB as a final backend.
I’ve received lots of questions related to this architecture and in this post I want to explain the right part of the above diagram. The problem to solve here is: if I have N client applications geolocated in different countries, is there a way to redirect the incoming call to an Azure Function accordingly to the client location?
Here, we have deployed an Azure Function (here called GetItemsFromCosmosDB) to N different Azure regions. What I want is that, for example, a customer from Europe calls the Azure Function instance deployed on the West Europe Azure region, while a customer from US calls the Azure Function instance deployed for example on the West US Azure region. The solution for achieving this goal is using Azure Traffic Manager.
Azure Traffic Manager enables you to control the distribution of traffic across your application endpoints (any Internet-facing service hosted inside or outside of Azure) with distribution of traffic according to one of several traffic-routing methods and continuous monitoring of endpoint health and automatic failover when endpoints fail. Azure Traffic Manager works at DNS level and it uses DNS to direct clients to specific service endpoints based on the rules of the traffic-routing method (it does not see the traffic passing between the client and the service).
How the above solution is implemented?
We have deployed an instance of our Azure Function on each Azure region we want to support and we have created an Azure Traffic Manager profile with a geographic routing method in order to redirect the incoming calls to the right Azure Function instance.
As an example, here I have two instances of the same Azure Function, deployed on two different regions (West US and West Europe):
We’ve created an Azure Traffic Manager Profile like the following:
Here, the Routing Method is set as Geographic. With this method, users are directed to specific endpoints based on which geographic location their DNS query originates from.
In order to create the Azure Traffic Manager profile, you need to select an existing resource group or create a new resource group to place this profile under. If you choose to create a new resource group, use the Resource Group location dropdown to specify the location of the resource group. Remember that this setting refers only to the location of the resource group, and has no impact on the Traffic Manager profile that’s deployed globally.
When the Azure Traffic Manager profile is created, you need to add endpoints. Here, we’ve selected Type = Azure endpoint (used for Azure-based services) and Target resource type = App Service (because our Azure Functions are deployed on an App Service plan):
As you can see in the above picture, we’ve created an endpoint called EUROPE Endpoint linked to the App Service plan (alias, our Azure Function deployment) located on West Europe.
In this endpoint configuration, we’ve also set a geo-mapping distribution by setting the Regional grouping field with all the Azure locations we want to redirect to this endpoint (in this example, all the incoming calls from Europe are redirected to this endpoint):
In the same way, we’ve created the other endpoint that points to the App Service plan (Azure Function) deployed on the West US:
As you can see, here we’ve selected that all incoming requests from North America, South America and Australia must be redirected to the West US Azure Function.
Now, if you select the created Azure Traffic Manager profile you can see the endpoints and check their status (the endpoint is working correctly if Monitor Status = Online):
What happens now?
You just need to expose to your client applications the DNS url of the Azure Traffic Manager. This address can be used by any clients to have its requests automatically routed to the right endpoint as determined by the routing type. In case of geographic routing, Traffic Manager looks at the source IP of the incoming request and determines the region from which it is originating. If that region is mapped to an endpoint, the request is routed to that endpoint. If this region is not mapped to an endpoint, then Traffic Manager returns a NODATA query response.
In this example, your client applications must call the following url:
http://d365bctraffic.trafficmanager.net/api/<FunctionName>?parameter=value
and the request is redirected to the correct function accordingly.
If I call this endpoint from my local machine (I’m on Italy), you can see here that the Azure function called is the function located on West Europe (because the EUROPE Endpoint is triggered):
Some notes:
- If your Azure Functions are on different subscriptions, you need to use External endpoints:
- If your Azure Function is protected by a key in the url (Function protection level), you need to generate the same key on every instance.
- Azure Traffic Manager pricing is extremely low, for details check here.
- Azure Traffic Manager has also a routing method called Performance, where the goal is to send traffic to the endpoint that can provide the lowest latency to the caller. Normally there is a strict correlation between geographical closeness and lower latency, but if you want to be 100% sure that traffic is redirected to the lower latency endpoint, the Performance routing method is what I recommend.
I think that using Azure Traffic Manager is something that you should consider if you will start using some “centralized” Azure Functions on your Dynamics 365 Business Central projects. If you have customers on different tenants in different regions, this could help you on improving performances and bottlenecks.
Stefano Demiliani 