All of Microsoft Azure’s management API requests pass through a single “frontdoor” service that handles routing and common functionality. The frontdoor service proxies requests to over 50 different Microsoft products (SQL, Virtual Machines, Dynamics, Active Directory, etc.) and is a mainline dependency for all service provisioning and management. As a result, downtime must be avoided at any cost and the APIs needs point of presence throughout the globe. Previously, this service was deployed to only a single geographic region, which caused three problems: (1) it hurt performance for our large international customer base; (2) it introduced a single point of failure; and (3) it would make metadata for other regulatory areas pass through the United States.

Over the past few years, Microsoft has transitioned to a fully geo distributed deployment for this frontdoor service (present in 20+ datacenters in North & South America, Europe, Asia and Australia). In each major area, there are multiple active datacenters that can automatically handle failovers due to physical or software faults. All metadata is also replicated using a simple table store that handles multi-master writes and asynchronous replication. This data store uses simple / common components (key/value store + queues) to appear consistent to our customers but is incredibly resilient to any number of common faults.

This session will cover the process of moving to this geo-distributed architecture, as well as relatable techniques for achieving high availability (via active-active-active deployments). The techniques should be transferable to public or private clouds.