I have a fairly typical common application deployed to Azure, with the following components:
- Two Cloud Services - Web and Worker
- Azure Service Bus
- Azure SQL Database
- Azure Storage
In the Azure management console, you can choose to automatically scale out each cloud service (meaning more servers added), which happens within the same data center.
What's the easiest way to scale a complete Cloud Service architecture (like ours) out across multiple data centers?
Alternatively, if it was easy enough to replicate just our Cloud Services across to another data centre (correctly handling load balancing etc), would the SQL and Storage lag/transfer rates be reasonably fast through Microsofts data "backbone"?
The reason I ask is that our servers are currently in Europe, but we are about to do a big push in Asia, and want to mitigate any performance issues for the website (which also hosts our mobile API).
I appreciate that this is a non-trivial problem since you need to think synchronising SQL Databases and Azure Storage containers, but I was hoping Microsoft have thought about it already :)
I currently deploy using the "Publish" command from a Visual Studio Azure project. This has a single ServiceDefinition (containing my two Cloud Services) and a ServiceConfiguration file for each environment (Live/Test).
What I really want is something as easy as this (but maybe from Visual Studio):
>git push azure-NorthCentral master
>git push azure-SoutheastAsia master
>git push azure-WestEurope master
This example uses Git deployment for Azure Web Sites, which are more isolated than our Cloud Service architecture, e.g. no data synchronisation to consider.
I marked this question to be closed as too broad, because honestly, there's no right answer when it comes to geo-scaling. However, I wanted to offer an objective answer regarding what Azure provides natively, related to your app (whether you choose to incorporate them or not).
Traffic Manager is designed specifically for routing your traffic to a particular region, based on specific rules (nearest, round robin, primary/failover). This would direct traffic to a specific region you deployed to, per your specification.
Azure Storage provides ability to have geo-replicated secondary storage (you cannot choose the region for the secondary; each region is already paired with another). You may then choose to read from the secondary region instead of primary. You will have to deal with the fact the data is eventually-consistent.
SQL Database service provides active geo-replication, where you'll have read-only databases in additional regions (again, this is an async replication, though your secondaries remain transactionally consistent).
Keep in mind: There is no SLA/performance metric around bandwidth/throughput between regions. You'll need to do some benchmarking.