Multi-cloud architecture is often associated with resilience. Spread workloads across multiple cloud providers, the thinking goes, and an outage at one provider no longer has the ability to take an entire application offline.<\/p>\n\n\n\n
The reality is more complicated.<\/p>\n\n\n\n
Using multiple cloud providers can remove important single points of failure, but simply distributing workloads between AWS, Microsoft Azure<\/a>, Google Cloud or other platforms does not automatically create a highly available system. Applications still depend on DNS, routing, network transit, physical infrastructure and connectivity between the application and its users.<\/p>\n\n\n\n True high availability requires looking at the entire delivery path, not just the servers running at the other end of it.<\/p>\n\n\n\n There are legitimate resilience benefits to multi-cloud infrastructure.<\/p>\n\n\n\n An organization might run its primary environment with one provider while maintaining critical services or replicated data with another. If the primary provider experiences a major regional outage, traffic can potentially be shifted elsewhere.<\/p>\n\n\n\n That reduces dependence on a single cloud platform, but cloud providers are only one layer of modern application infrastructure.<\/p>\n\n\n\n A user attempting to reach an application may depend on a chain that includes a local internet provider, regional network infrastructure, transit providers, DNS services, content delivery networks and physical fibre routes before traffic ever reaches the cloud environment.<\/p>\n\n\n\n Redundancy at the compute layer does little to help if another part of that chain fails.<\/p>\n\n\n\n One of the easiest mistakes in high-availability planning is assuming that logically separate services are also physically independent.<\/p>\n\n\n\n Two cloud environments may use different providers while still depending on some of the same underlying infrastructure. Traffic could traverse common internet exchanges, long-haul fibre corridors or upstream network providers.<\/p>\n\n\n\n Even separate data centres can have hidden dependencies if their connectivity ultimately passes through the same physical routes.<\/p>\n\n\n\n \u201cMulti-cloud architecture can protect against a failure within one cloud provider, but it doesn\u2019t eliminate the network as a potential single point of failure,\u201d said Tomas Novosad, broadband analyst and founder of Fibre Broadband NZ<\/a>. \u201cApplications can be distributed across multiple providers and regions while traffic still depends on shared fibre routes, transit providers or local access infrastructure. High availability has to account for the entire path between the application and the end user, not just where the workload is hosted.\u201d<\/p>\n\n\n\n This physical layer is easy to overlook precisely because cloud infrastructure makes computing resources appear abstract. Developers can provision servers, databases and storage across the world in minutes, but the data connecting those resources still has to travel through physical networks.<\/p>\n\n\n\n The expansion of fibre broadband and other high-capacity network infrastructure has made those connections significantly faster and more reliable, but it has not eliminated the need to understand where dependencies exist.<\/p>\n\n\n\n DNS is another dependency that can undermine an otherwise well-designed multi-cloud architecture.<\/p>\n\n\n\nMulti-Cloud Solves Only Part of the Problem<\/h2>\n\n\n\n
The Network Can Still Be a Single Point of Failure<\/h2>\n\n\n\n
DNS Deserves the Same Attention as Compute<\/h2>\n\n\n\n