So you want to run your application, your next project, … something on Microsoft Azure? Now image you’re already at that point where you start using Microsoft Azure. What would be the first thing you do? You typically start by creating a resource in a specific datacenter/sub-region (like a VM, a storage account, …). If you’ve given it some thought you might even have created an affinity group for your Storage Accounts and Cloud Services.
Hold your horses!
Now choosing a regions is actually a very important choice when you’re working with Microsoft Azure, for a few reasons:
- Performance for your end users: if you’re not deploying in all regions you’ll want to pick the region(s) where you’ll have most of your users in order to get the best routing between your application and your end users. The region closest to your users won’t guarantee the best routing, but it’s a starting point.
- Performance for your application: you’ll want to make sure your application, the data, the database, … are all in the same sub-region for optimal performance (you’ll be working with the performance of a LAN network instead of working a internet speed).
- Cost: the bandwidth you’re using within a sub-region is not charged, but as soon as your data leaves the sub-region (egress), you’ll be paying for that outgoing traffic.
The first point is obvious, but the second and the third are tricky. Did you know that some components of the Microsoft Azure platform are only available in specific sub-regions? Let’s take a look at what’s possible today (the most recent version is available here):
Image may be NSFW.
Clik here to view.
If you look at this table you’ll see that Mobile Services isn’t available in Europe West (Amsterdam). Now let’s say I have an application running in the Europe West sub-region and during the course of the project we decide we need Mobile Services with a custom API. Well, since that service is not available in the sub-region where the rest of my application is hosted, this could have a few disadvantages:
- Performance for my application: when the custom API in my Mobile Service needs to interact with my backend/database/… it will need to connect to a different sub-region. As a result the latency of my Mobile Service will be much higher because the integration will happen at internet speed instead of LAN speed.
- Cost: I’ll have an additional bandwidth cost I’ll need to take into account. Whenever my Mobile Service gets data from the Europe West sub-region this means that the data is leaving the sub-region (egress).
Now if I had chosen the Europe North sub-region there wouldn’t have been an issue. My Mobile Service would have performed better and there wouldn’t have been the additional bandwidth cost.
Conclusion
Whenever you can, think ahead and take into account that you might need a service that is not available in the sub-region of your choice. Having to move a complete application afterwards won’t be a walk in the park, so think about it wisely…
Have fun!
