Why multi-Cloud is all but vain (re-engineering multi-Cloud part 2)
Multi-Cloud generates a tremendous amount of buzz these days, no surprise it's easy to either miss the real point or to get lost in a field of speculative expectations. In my previous instalment, I shared a novel multi-Cloud application pattern that will serve as a show apartment for today's discussion aka reengineering multicloud part 2.
Know when multi-Cloud is not appropriate
For many use cases it's hard to agree that multi-Cloud deployments are more appealing than single cloud ones: even if a multi-Cloud set up is easy (because PaaS), it's adversely affected by artificially-induced latency, data transfer costs (data in and/or data out), a big overhead in bandwidth consumption and giving up some of the recent promises brought by SD-WAN.
Still I don't believe cross-providers network integration to be the most difficult technical challenge: for me, the real problem lies in storage. The issue with storage is somehow related to network, but all this is far-reaching: storage deserves a dedicated article, I'll cover it in a third instalment.
Multi-Cloud applications must not only be designed with the usual disruptive native PaaS patterns in mind, they must also be carefully optimized to limit those many unwanted side-effects. So sometimes, it's just not worth the trouble. Keep that in mind.
Now for the real gain
I would like to focus on what is, in my opinion, the single most concrete (and overlooked) benefit: resilience.
If, for whatever reason, relations with the provider deteriorate to a point of non-return, or if the provider is taken out of business by a critical exploit, a Multi-Cloud set up greatly facilitates customer survivability and/or speed of recovery.
To understand this, take a look at your options in a mono-Cloud situation:
Your company's health is heavily dependent on her provider's, obviously.
Now observe how you hedge yourself against unfortunate events in the multi-Cloud deployment discussed in part 1:
Your company will only fail by her own terms OR by the simultaneous failure of both of her providers (assuming she only has two).
Closing notes
Beware that not all multi-Cloud architectures are equal. Most of what is called multi-Cloud today is just a simple sketch of what is to come in the next few years.
And incidentaly, we have just discovered at third Taleb fuse. More on that here and there, if you are curious.
In the next instalment, we will explore a secondary benefit from Multi-Cloud and what is the stance of the three main Public Cloud providers about this concept.
Staff Solution Engineer @ HashiCorp
3 年in my opinion what really matters for a multi-cloud strategy is the workflow, you need to be able to manage it consistently and you need a way to manage your heterogeneous infrastructure in a simple manner and last but not least, select the right tools in order to provide knowledge sprawl and responsibility sharing. All other arguments are technicality
Cloud Consultant and Frugal Architect - 15 ?1?7x AWS certified , ???????? Solutions not Platforms. (opinions are my own).
3 年I’m not a fan of multi-cloud strategies without a solid business case. Technically, the major cloud providers are more than suitable to build resilient applications. That said, given the willingness of service and cloud providers to unilaterally de-platform users and customers with little or no recourse, the focus should instead be on a public-private hybrid approach with the purpose of securing critical data and functionality.
Cloud Engineer @ Syneco Trading GmbH
3 年Great take on multi-cloud, especially the storage part you mention. ??
Cyber Security Architect
3 年Microservice APIs in Kubernetes will be popular with multi-cloud.
Senior Director Engineering at Kyriba
3 年I always like your analysis but I have to say I would put a bit more nuances this time. Information systems are composed of a diversity of applications: short-lived to eternal old mammoth. non-strategic to highly strategic. Non differentiating to critical for competitive edge. All these criteria should play a role into the reasoning one should have regarding multi-cloud vs mono. Context is key. Multi-cloud should not be by default with least common denominator... rather a choice of defensive programming. Then I'd argue managed services are starting to be designed with multi-cloud in mind and enabling functionality to be run wherever the data is. What remains, and that's where we might reach consensus are all the highly specific services differentiating one cloud from the other and for those I doubt we'll overcome your arguments anytime soon. In essence, I'd clearly like to see a baseline standardization of non differentiating services on multi-cloud to ease clients & devs life and to let the best differentiating services differentiate. Thanks for you articles & hope to see you soon Christophe ??