Why enterprises need a distinction between multiple clouds and multi-cloud
As commonly used, the term ‘multi-cloud’ doesn’t imply anything about a user’s application architecture. However, once organizations with more than one set of cloud services start using them cooperatively and synergistically, they find that the design and implementation implications are far more significant than checking a “multi-cloud” survey box.
That’s because, carefully crafted web-scale systems that anticipate a highly distributed and occasionally hostile network environment, most enterprise software is designed with the assumption that interdependent systems can easily communicate with each other with little resistance, i.e. latency, jitter, packet loss and bandwidth throttling in network-speak.
Once an application is spread across multiple clouds, these assumptions go out the window if the services are interconnected, as is the case for most nascent cloud deployments, over the Internet using VPNs. In these cases, users are in for a nasty surprise if they expect the same repeatable performance they got from on-premises systems.
Instead, IT organizations with distributed multi-cloud systems must pay as much attention to the network stitching clouds together as they do to the on-cloud application design and service selection. Unfortunately, it’s not in the best interest of cloud providers to make it easy to move workloads and data back and forth to competitors. Indeed, most charge transfer fees for the privilege.
That’s why the Oracle-Microsoft cloud interoperability partnership announced last year and recently expanded to Europe is such a significant deal. Sure, similar capabilities are available from carriers, like AT&T NetBond and CenturyLink Cloud Connect, or colocation providers like Equinix Cloud Exchange and Switch Cloud, but why employ a separate connectivity broker when you can directly link two cloud providers using a native service? Indeed, according to a report from Accenture, setting up such telco interconnections “can cost as much as $100,000 per year in recurring charges,” on top of setup fees.
Let’s go into more detail on the problem and why I hope the Oracle-Microsoft detente leads other cloud providers to break down the walls separating them from their competitors.
Most software vendors now pay homage to the cloud as an alternative platform for their products and have seen the advantages of cloud infrastructure. SImilarly, many IT organizations figure that if one cloud is good, two or more must be better. Consequently, read any survey measuring enterprise cloud usage and you’re bound to see a growing majority of respondents claiming to have some form of a multi-cloud strategy.
Similar to the ambiguity around the term “hybrid cloud,” “multi-cloud” has been the subject of much imprecision and wishful thinking. For example, when we refer to a hybrid car, we mean a vehicle with two modes of propulsion — usually a gas-burning internal combustion engine and a battery-fed motor — that work in concert to provide the required amount of power for a particular situation. Deductively, we would conclude that a hybrid cloud architecture would be two disparate clouds — generally accepted as an on-premises virtualized software stack and one public infrastructure cloud (IaaS) — used together to provide application services and resources. Unfortunately, that’s not how most people use the term. Instead, hybrid usually means connecting on-premises and public clouds where workloads and data occasionally move between the two; for example, replicating on-premises applications to the cloud for disaster recovery.
The same semantic sloppiness besets the term “multi-cloud”, which surveys typically don’t define. This results in responses that reflect the lowest common denominator definition, namely an organization that uses one or more cloud services.
