哪种多云架构会胜出？

出于多种原因，您将不得不一头雾水，不注意到多云部署已成为新常态。我听到的核心论点是避免锁定并选择同类最佳的云服务的概念。 正如我之前在这里指出的那样，多云带来了复杂性，也带来了操作复杂体系结构的挑战。
许多企业可以将这些部署转移到运营中（cloudops），而其他企业则陷入了云计算的困境。 一个简单的答案是他们应该更好地计划，但这不是企业想要听到的，并且对他们而言公平的是，这不是有效的回应。他们需要采用能够解决当前业务问题的多云架构，并为实现不会中断操作的优化的多云架构提供途径。
以下是一些候选架构： 异构云原生。为了寻求最佳的，解耦的云计算部署，小组正在选择他们认为最适合该工作的技术。这种架构最终带来了来自许多不同的公共云提供商的许多云原生服务，这确实引起了问题。
这并不意味着不希望使用云原生，而是。这意味着我们错误地使用了本机云。问题在于，本机云服务之上几乎没有或没有通用服务。
您将最终获得十种不同的安全解决方案，几种治理工具以及十几种管理和监视解决方案。尝试同时与所有这些人一起工作，看看会发生什么。 异构联合。
尽管这看起来像是一种古老的架构模式，已经在云计算中逐渐流行起来，但事实是它很新。这种体系结构能够利用容器和容器集群，但是可以通过将其作为联合主机部署到许多不同的公共云中来实现。 这种方法取决于发生的事情。首先，诸如Kubefed之类的标准以及将使用容器集群联合的最终产品必须出现在市场上。其次，云社区需要接受这种体系结构作为理想的东西，这样就会产生生态系统。 以上都不是。
这条路径意味着我们朝着多云的另一个架构方向发展，那将是什么呢？如果我们正在研究异构云原生的问题，这意味着正在进行中的复杂性之争，那么逻辑上的出路将是规划和开发通用服务，例如安全性，治理，管理，监视，甚至是devops方法和工具链。 辩论实际上是在缺乏计划（原生）和过度规划（联邦）之间，并且没有强制使用特定的，标准的支持技术，例如容器和Kubernetes。 什么会赢？从我的角度来看，只要我们摆脱异构云原生及其局限性的复杂性，就可以了。
您要采取什么行动？