Multi cloud - don't get trapped by the illusion of cloud platform neutrality

Enterprises must realize that 100% cloud platform neutrality is more an illusion than reality, nor can it be enforced by barring all platform-specific services. Instead, this overshoots the mark, limits the benefits of the cloud, and overlooks the real multi-cloud challenges.

In the era of client/server computing, everyone laughed at the quote from Thomas Watson, chairman of IBM, who stated in 1943: “I think’s that there’s a world market for maybe five computers”. However, 80 years later, it looks like he was right after all. Basically, there are Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP) plus two cloud platforms in China. Even though Watson had probably five mainframe computers in mind, whereas the cloud platforms consist of an unimaginably large number of servers running in a multitude of data centers around the world, it is viewed abstractly the same.

Be aware that we are on the path where almost all IT applications of all Western world enterprises run on three hyperscale cloud platforms: AWS, Azure or GCP. Also note that while there are many software providers, their SaaS solutions are increasingly running on these platforms, too. From a political and competition law perspective, this may be worrisome, but from an individual company's viewpoint, cloud adoption is crucial to competitiveness and business agility; the benefits are huge. So, enterprises move to the cloud, but do not want to commit to a single platform; instead, pursue a multi-cloud strategy with two or even three platforms.

Compliance to regulatory obligation

Particularly in the Financial Industry, a certain degree of platform neutrality is not just an architectural guardrail, but a regulatory obligation. For example, BaFin in Germany requires all insurers to have an exit strategy defined, i.e., insurers must be able to move their applications from current cloud platforms to others or back to on-premises. Note that this VAIT obligation does not require a 100% platform-neutral solution, but “only” a defined exit strategy and migration plan. This is often overinterpreted.

Frequently the illusion is created, and top management is led to believe that it is possible to move workloads between cloud platforms at the push of a button. This can be show-cased for small applications but is hardly feasible for the entire IT landscape. The fallacy often drawn is that you can move at will between the cloud platforms if you only use platform-independent services. However, the problem is not so much the services used, but data, virtual networks, security mechanisms and cloud operations.

Figure 1: Cloud Independence App

Real barriers to cloud neutrality

Let’s focus on data first. Moving data into the cloud is for free, while moving data out of the cloud is costly. All three players charge high egress costs. So, moving your data between the cloud platforms is an expensive endeavor. Data also determines the deployment of workloads as it should be avoided to spread highly interconnected applications and data of one business domain across multiple cloud platforms. Whilst cross-cloud integration is of course technically feasible, cross-traffic should be minimized due to high egress costs and latency, reliability, and security challenges.

AWS, Azure, and GCP offer a wide range of services or are basically a compilation of services. The individual services differ, but frequently the other platforms offer similar, albeit not identical, services. That's because the three players have also "copied with pride" and made long known solutions available as cloud platform services. But this similarity is less the case for network, security, and cloud operations. The virtual private network / cloud (VPN/VPC), security and operation services differ strongly. For example, a VPC in GCP spans multiple regions unlike in AWS or Azure. A VPC in AWS consists of a public and private sub-net, not so common in Azure. AWS, Microsoft and Google have implemented their cloud security fabric differently; e.g., very different Identity & Access Management (IAM). Besides, it is almost impossible to find employees who can operate all three cloud platforms alike.

These key differences are a bigger barrier to cloud neutrality than, for example, the nearly negligible differences between AWS Lambda, Azure Functions and Google Cloud Functions. However, the focus is often mistakenly placed on these variances. To avoid lock-in, strict architectural constraints are often imposed, allowing only platform-independent solutions that can be run everywhere. This sounds reasonable at first but is restrictive and severely limits the benefits of the cloud. Nothing to be said against state-of-the-art cloud-agnostic solutions but do not compromise for that reason alone.

Pitfalls and the risk of overshooting

Another typical mistake is to define “proven” solutions used on-premises as cloud standards without reassessment. Similarly trapped in old on-premises mindset, one database solution is often defined as the standard. But for cloud applications, it is not uncommon to use several databases. As these are fully managed database services, this is best practice and illustrates the difference between cloud and on-premises computing.

Don't overdo the cloud agnosticism by foregoing the use of cutting-edge platform services. Consider, e.g., an architecture on AWS comprising Amazon API Gateway, Event­Bridge, Lambda, and Dynamo-DB. Should this state-of-the-art, serverless architecture be forbidden because AWS-specific services are used? On Azure, should tight integration with Microsoft products be omitted? Should you forgo BigQuery on GCP? Bluntly put, don’t be more papal than the Pope. Leverage the strengths of the platforms. This ties you a little more to the cloud platform used, but not much more than is the case anyway.

Exit strategy as a guide and not just a duty

All this is not meant to be a general carte blanche. Choose carefully which cloud platform services you want to use and which not; just don't be too restrictive for dogmatic and on-premises minded reasoning. Allowing this flexibility makes it more important to define a comprehensive exit strategy for all cloud applications, or even the entire IT landscape. Specify shadow architectures for alternative cloud platforms and for on-premises. The migration steps must be described in detail, and effort and costs must be determined.

Figure 2: Executable Exit Strategy

In doing so, you will realize that there are alternatives, even if you are using "proprietary" services. In this respect, the lock-in is proving not to be as tight as feared. Compare this for example to SAP S/4HANA with proprietary ABAP and HANA. This is a much tighter vendor lock-in. Moreover, you will find that agnostic solutions loosen the lock-in knot, but not that much either. The platform lock-in is primarily caused by the highlighted key differences in networking, security, and operations, as well as the significant migration costs.

Summary and recommendation

In summary, 100% cloud platform neutrality is more an illusion than reality and this is less due to the use of platform-specific services. Dogmatic restrictions cause more harm than benefit. Define your multi-cloud strategy with the support of an experienced, tech-savvy strategic partner, with pragmatism, open mindset and without false illusions or on-premises thinking. Be prepared for the worst case with exit strategies and shadow architectures, but don't let that stop you from realizing the full potential of the cloud.