Reengineering multi-Cloud for financial gains

Cracking on the benefits of a purely native multi-Cloud approach, today we'll examine the actual monetary benefits. We'll also see how far AWS and Azure managed services stand from the multi-Cloud Holy Grail and share some key takeaways.

In part 1, we argued that the multi-Cloud as it is today is quite limited and put forward a new, native model;

In part 2, we explained how native models are superior to the current models and articulated the simple main benefit they could bring to large organizations: survivability (or resilience, if you will).

Now for the monetary benefits: relying on several providers can look dear at first but it facilitates global deals and rebates. Leveraging (or should I say: overusing?) pay-per-use to its limits, a native multi-Cloud makes it easy to arbitrate Cloud consumption at different time scales:

• in real-time[*], by tactically choosing the cheapest pay-per-use service (as long as it counterweights the aforementioned adverse side-effects);
• on a yearly basis, by strategically assigning more capability where the biggest savings are to be expected based on negotiated contracts;
• opportunistically[**], by enlisting the hard-won service mesh to perform asynchronous tasks offloading to a broader range of cheap, container-based serverless service (eg: GKE offloading to Fargate, EKS to ACI, ...).

Some of these gains can surely be achieved thanks to a standard multi-Cloud layout, however I believe only a native design will let customer get their money's worth.

For sure this is quite enticing, but how far are we from native multi-Cloud?

The ecosystem (Azure/AWS focus)

Today

Microsoft has the upper hand with its multi-Cloud friendly Azure Arc strategy. Amazon is catching up with its ECS anywhere service (revealed during reInvent 2020).

If both approaches may rightfully be called "native", neither of the Cloud providers seem to work on the native approach we advocate here: for now, ECS Anywhere and Azure Arc focus on the Control Plane however the most dreadful multi-Cloud roadblocks lie in the Data Plane (as we have seen in parts 1 and 2. Even more of that to come in part 4).

In their latest announcement (dated 25 May), Microsoft teams unleash a fantastic new capability: let you run your apps in Azure, AWS or on premises. But this is heavily Control Plane oriented. The managed service mesh required for proper Data Plane implementation will have to wait.

The truth is that all providers will have much to lose with a managed service mesh. That is to say:

The provider that will be first to deliver a full featured native Multi-Cloud PaaS will have less to lose than its followers...

Tomorrow

I'm not a great fan of the Multi-Cloud that is being discussed today between Cloud architects or on social networks, but I want to believe in what it could become. The example we went through in part 1 is just a what-if scenario among many other more or less likely candidates. The most likely scenarios are shaded from our view by the cloud, not the Public Cloud this time, but the cloud of customers indecisions and providers competition...

In this game, everybody is waiting for the others. I believe it's up to Cloud customers to break the circle first by asking themselves where they want to be in two or three year time and for what reasons. Because

As long as public cloud providers are not hard-pressed for managing your data plane, the Multi-Cloud will remain what it is today: a chimera.

Takeaways

Good reasons that would give strong impetus to a customer vision are:

• being proactive / not remaining hapless against a devastating attack on your single provider.
• maxing out rebates opportunistically.

And I think the worst reasons are:

• making economies of scale: multi-Cloud is not going to be cheap, it's going to save your enterprise's life... (sorry to insist so heavily on that point)
• ditching complexity. If you work for a big company complexity is not a dead end, it's the beginning of simplification and costs reduction. And a native approach will be way more simple than the makeshift designs of today.
• freaking out on vendor lock-in. "lock-in" does not rime with Multi-Cloud, it rimes with "take-in" (gullibly). All Cloud providers support organizations like the Cloud Native Computing Foundation and do a wonderful job at breaking this dogma. Take a look at Google's latest multi-Cluster GKE Gateway controller: it's definitely heading to the right direction don't you think?

What's next?

The fourth and last instalment will focus on the single main challenge ahead... Data.

Notes

[*] Check out this example

[**] o15y!