采用多云方案不应导致 IT 预算膨胀和无法实现里程碑。它应该帮助您管理成本并加速路线图的推进。
最近，一位记者要求我们帮助为技术领袖概述混合云的挑战和复杂性。虽然我们怀疑许多技术专家已经对此进行了相当多的思考，但我们也知道从与客户和社区成员的直接讨论中，这仍然是一个重要的探讨领域。我们希望将这种思考总结成实际的东西，在适当的地方进行扩展，并在必要时提出具体建议。
首先，我们要说的是混合云和多云的概念很难分解。如果您拥有一个本地私有云和一个公共云提供商，那是否就使您有资格成为多云用户？虽然实际上很少有人只使用两个云。Flexera 团队每年都会对这个问题进行研究，他们发现 87% 的企业自认为是多云用户，平均拥有 3.4 个公共云和 3.9 个私有云，尽管这些数字与去年的报告相比略有下降：
其中存在一个合理的问题：云使用得越多是否就越好？
答案是肯定的。如果您没有正确设计事物，您可能会陷入可怕的“n 体问题”状态。这是一个物理学术语，被用于软件开发。在多个公共云环境中，“n 体问题”指的是管理、集成和协调这些云的复杂性。在 n 云环境中，每个云服务（如 Amazon Web Services（AWS），Azure，Google Cloud等）都可以看作是一个“体”。每个这些“体”都有自己的属性，如 API、服务、定价模型、数据管理工具、安全协议等。在这种情况下，“n 体问题”是有效地管理和协调跨多个云的各种复杂元素，包括互操作性、安全性和合规性、性能管理、治理和访问控制以及数据管理等方面。
随着您向系统中添加更多云（或“体”），问题变得指数级更加复杂，因为云之间的差异不仅仅是线性的，不能从成对互动中推导出来。
在多云环境中克服“n 体问题”需要精心设计的架构，特别是在数据存储层面。选择云原生技术，更重要的是云可移植技术，可以在不增加显著成本的情况下释放多云的潜力。
另一方面，是否云的数量太少会有问题？如果太少意味着只有一个，那可能是有问题的。多于一个，你就在正确的方向上思考这个问题。事实证明，云太少或者多个云只有一个用途（例如计算机视觉或纯粹的备份）都会产生相同的结果——锁定和增加业务风险。
锁定会减少选择的灵活性，增加成本，并减少企业对其技术堆栈以及云内的选择的控制（例如，AWS 拥有 200 多种服务和 20 多种数据库服务）。云太少也可能带来业务风险。AWS 和其他云每年都会多次宕机。这些宕机可能会导致业务陷入停滞。
企业需要构建一个弹性、可互换的云架构。这意味着应用程序的可移植性和数据复制，以便当一个云宕机时，应用程序可以无缝地切换到另一个云。再次强调，每个公共和私有云上都有数十种数据库——实际上，其中一些甚至在公共云之外是不可用的（参见 Databricks）。这不是“云太少”的挑战中的问题所在。
随着您向系统中添加更多云，问题变得指数级更加复杂，因为云之间的差异不仅仅是线性的。
数据层更加困难。在 AWS、GCP、Azure、IBM、Alibaba、腾讯和私有云上运行的存储选项不多。这是真正的云原生存储提供商的领域，它们是对象存储、软件定义和 Kubernetes 本地化的。在理想的情况下，AWS、GCP 和 Azure 都应该支持相同的API（如 S3），但事实并非如此。依赖于在其中一个云上运行的数据的应用程序将需要重新设计以在另一个云上运行。这就是锁定问题。
关键点是在云部署模型中要具备灵活性。即使是最著名的“单云”用户，如 Capital One ，也有大规模的本地部署——实际上，他们使用了 MinIO。没有一个大型企业可以“锁定”在一个云上。这种刚性会阻止企业购买在其他云上的公司，这相当于割掉自己的鼻子来报复自己。
企业必须为云操作模型中的选择性而建立。这是成功的关键。云操作模型涉及 RESTful API、监控和可观察性、CI/CD、Kubernetes、容器化、开源和基础架构即代码。这些要求与灵活性并不矛盾，相反，遵循这些原则提供了灵活性。
好吧，不是 42。但可以是三个。在企业做出明智的架构决策（云原生、可移植、采用 Kubernetes）的前提下，答案应该在三个到五个云之间，并根据规定需要更多的监管要求进行调整。
同样，假设正确的架构，这个范围应该提供选择性，从而提供成本的杠杆。它在宕机情况下提供弹性，提供所需服务的丰富度，应该能够使“n 体问题”变得可管理。
虽然大多数人会告诉您，在多云环境中，复杂性是最难管理的问题，但事实是一致性才是主要挑战。拥有可以跨云（公共、私有、边缘）运行的软件提供了管理复杂性所需的一致性。以对象存储为例。如果您有一个可以在 AWS、GCP、Azure、IBM、Equinix 或您的私有云上运行的单一对象存储，那么您的架构就会变得更加简单。一致的存储及其功能（复制、加密等）使企业能够专注于应用层。
一致性创造了选择性，而选择性创造了成本杠杆。减少复杂性不能以不可持续的成本为代价。通过选择可以跨云（公共、私有、边缘）运行的软件，您可以减少复杂性，增加选择性。如果在 GCP 上运行工作负载更便宜，就将其迁移到那里。如果在 AWS 上运行数据库更便宜，就在那里运行。如果在本地存储数据并使用外部表更便宜，那就这么做。
选择提供应用程序和开发人员一致体验的软件，您将实现选择性，并在成本方面获得杠杆效应。确保该体验基于开放标准（如 S3 API、开放表格格式）。
定制云集成实际上是一个糟糕的主意。正如前面提到的，每个额外的本地集成都会增加一个数量级的复杂性。以这种方式来思考：如果您投资于专门的团队，那么您每年都需要投资 500 万至 1000 万美元用于工程师的每个平台。这还不包括每个云的部落知识的成本。最终，这将导致出现错误且难以维护的应用程序代码。软件定义、以 Kubernetes 为中心的软件可以解决这些问题。做这种投资，而不是定制云集成的投资。
我们常常作为IT领导者，处理眼前的问题：影子 IT 或新的并购整合。正因如此，我们经常没有建立与整体战略相关的框架或第一原则。这一点在云操作模型中尤为明显。企业需要秉持容器化、编排、像 S3 这样的 RESTful API、自动化等第一原则。这些第一原则构建了一致性的基础。
那些试图因为获得了大量的前期积分或对组合中其他应用程序的好处而强制规定使用 Cloud A 而不是 Cloud B 的 IT 领导者，是被锁定游戏中上当的傻瓜，这种游戏是甲骨文等公司发明的，但三大云平台已经掌握到炉火纯青的地步。
采用多云不应成为 IT 预算膨胀和无法实现里程碑的借口。它应该是管理成本和加速路线图的工具。采用云操作模型的第一原则并坚持这一框架，将提供分析几乎任何情况的背景。
不久前，一位客户问我们是否建议将云分散在多个服务中。我们花了一会儿时间才理解这个问题，因为这个问题本质上是错的。问题应该是：“我应该在多个云上部署多个服务吗？”
对于这个问题的答案是肯定的。
Snowflake 在多个云上运行。Hashicorp Vault 在多个云上运行。MongoDB 在多个云上运行。Spark、Presto、Flink、Arrow 和 Drill 在多个云上运行。 MinIO 在多个云上运行。
选择一个云原生的架构堆栈，您很可能会得到一个可以在不同云上进行迁移的架构。这就是考虑混合/多云的方式。