架构师思考混合/多云的指南

最近，一位记者要求我们帮助技术领导者界定混合云的挑战和复杂性。虽然我们怀疑许多技术专家已经对此进行了相当多的思考，但我们也从与客户和社区成员的直接交流中了解到，这仍然是一个重要的探索领域。我们希望将这些思考总结成一些实用的内容，在适当的地方进行扩展，并在必要时给出具体的建议。

首先，我们要说混合云和多云的概念很难区分。如果您有一个单一的本地私有云和一个单一的公有云提供商，这是否意味着您就是多云？当然，没有人真的只有两个云。Flexera团队每年都会对这一主题进行研究，其研究报告显示，87%的企业认为自己是多云，平均拥有3.4个公有云和3.9个私有云，尽管这些数字实际上比去年的报告略有下降。

这里有一个合理的问题：云的数量是否可以过多？

答案是肯定的。如果您没有正确地设计架构，您可能会陷入可怕的“N体问题”状态。这是一个物理学术语，被借用到软件开发领域。在多个公有云的背景下，“N体问题”指的是管理、集成和协调这些云的复杂性。在“N云环境”中，每个云服务（AWS、Azure、Google Cloud等）都可以被视为一个“体”。每个“体”都有其自身的属性，例如API、服务、定价模型、数据管理工具、安全协议等。“N体问题”在这种情况下就是有效地管理和协调这些多样化且通常复杂的元素跨多个云。一些例子包括互操作性、安全和合规性、性能管理、治理和访问控制以及数据管理。

随着您向系统中添加更多云（或体），问题变得呈指数级地更加复杂，因为云之间的差异不仅仅是线性的，并且无法从成对交互中推断出来。

克服多云环境中的“N体问题”需要深思熟虑的架构，尤其是在数据存储层方面。选择云原生，更重要的是云可移植的技术，可以释放多云的强大功能，而不会产生巨大的成本。

另一方面，云的数量是否可以过少？如果过少等于一个，那么可能确实如此。超过一个，您就从正确的角度思考问题了。事实证明，云的数量过少，或者多个云具有单一用途（例如计算机视觉或简单的备份），会导致相同的结果——锁定和增加业务风险。

锁定会降低选择性，增加成本并最大限度地减少企业对其技术栈的控制，尽管在该云中可以选择（例如，AWS有200多种服务和20多种数据库服务）。云的数量过少也会造成业务风险。AWS和其他云会发生故障。每年都会发生几次。这些故障可能会使业务陷入停顿。

企业需要构建一个弹性且可互换的云架构。这意味着应用程序的可移植性和数据复制，以便在云发生故障时，应用程序可以无缝地故障转移到另一个云。同样，您会发现每个公有云和私有云上都有数十种数据库——事实上，其中一些甚至无法在公有云之外使用（例如Databricks）。这不是“云数量过少”挑战中存在的问题所在。

数据层更复杂。您不会发现很多存储选项同时运行在AWS、GCP、Azure、IBM、阿里巴巴、腾讯和私有云上。这是真正的云原生存储提供商的领域，它们是对象存储、软件定义和Kubernetes原生的。在理想情况下，AWS、GCP和Azure都将支持相同的API（S3），但事实并非如此。依赖于在其中一个云上运行的数据的应用程序将需要重新架构才能在另一个云上运行。这就是锁定问题。

关键的收获是要在您的云部署模型中保持灵活性。即使是最著名的“单云”玩家，如CapitalOne，也拥有大量的本地部署——事实上，它们使用了MinIO。没有一家大型企业能够“锁定”到一个云上。这种僵化程度将阻止企业收购其他云上的公司。这相当于为了报复而自断鼻梁。

企业必须为云运营模型中的选择性做好准备。这是成功的关键。云运营模型是关于RESTful API、监控和可观察性、CI/CD、Kubernetes、容器化、开源和基础设施即代码。这些要求与灵活性并不矛盾。相反，坚持这些原则可以提供灵活性。

那么神奇的数字是多少？

好吧，它不是42。但是，它可能是三个。只要企业做出了明智的架构决策（云原生、可移植、拥抱Kubernetes），答案将在三个到五个云之间，并为规定更多云的监管要求做出规定。

同样，假设架构正确，该范围应该提供选择性，这将带来成本杠杆。它将在发生故障时提供弹性，在所需服务的目录深度方面提供丰富性，并应使N体问题保持可管理。

可管理性如何？

虽然大多数人会告诉你，复杂性是多云环境中最难管理的事情，但事实是，一致性是主要挑战。拥有可以在云（公有云、私有云、边缘云）之间运行的软件，可以提供管理复杂性的一致性。以对象存储为例。如果您有一个可以在AWS、GCP、Azure、IBM、Equinix或您的私有云上运行的单一对象存储，您的架构将变得更加简单。一致的存储及其功能（复制、加密等）使企业能够专注于应用程序层。

一致性创造选择性，选择性创造杠杆。降低复杂性不能以某种不可持续的成本为代价。通过选择可以在云（公有云、私有云、边缘云）之间运行的软件，您可以降低复杂性并提高选择性。如果在GCP上运行该工作负载更便宜，请将其迁移到那里。如果在AWS上运行该数据库更便宜，请在那里运行它。如果在本地存储数据并使用外部表更便宜，请这样做。

选择为应用程序和开发人员提供一致体验的软件，您将获得选择性并获得成本杠杆。确保该体验基于开放标准（S3 API、开放表格式）。

定制的云集成结果证明是一个糟糕的主意。如前所述，每个额外的原生集成都复杂了一个数量级。可以这样想：如果您投资于专门团队，您每年将在每个平台上投资500万至1000万美元用于工程师。这还没有计算每个云的专门知识的成本。最终，它会导致错误且无法维护的应用程序代码。软件定义、以Kubernetes为中心的软件可以解决这些问题。进行这项投资，而不是投资定制的云集成。

我们未能看到……

作为IT领导者，我们经常处理眼前的事情：影子IT或新的并购整合。因此，我们常常无法创建与整体战略相关的框架或第一原则。在云运营模型中，这一点尤其明显。企业需要拥抱容器化、编排、RESTful API（如S3）、自动化等的第一原则。这些第一原则为一致性奠定了基础。

试图规定云A优于云B的IT领导者，因为他们获得了一系列预付信用或其他应用程序组合中的好处，他们在锁定游戏中是输家，而甲骨文率先发起了这种游戏，但三大巨头已经掌握了它。

多云不应成为IT预算膨胀和无法实现里程碑的借口。它应该是管理成本和加快路线图的工具。使用第一个云运营模型原则并坚持该框架，可以提供分析几乎任何情况的上下文。

云优先还是架构优先？

前几天，一位客户问我们是否建议在多个服务之间分散云。我们花了一点时间才理解这个问题，因为它问错了。问题应该是：“我是否应该跨多个云部署多个服务？”

答案是肯定的。

Snowflake运行在多个云上。HashiCorp Vault运行在多个云上。MongoDB运行在多个云上。Spark、Presto、Flink、Arrow和Drill运行在多个云上。MinIO运行在多个云上。

选择一个云原生的架构栈，您可能会得到一个云可移植的栈。这就是思考混合/多云的方式。