多云架构师指南

目前，混合云和多云之间的界限很模糊。混合云的定义当然更广泛（公有云、本地部署、边缘）。多云通常指的是多个公有云。造成模糊的原因是，云是一种思维方式，而不是一个物理位置。因此，我们看到这些术语现在可以互换使用。

然而，有一点是明确的，那就是无论定义如何，在两者上取得成功的首要原则都非常相似。

如今，混合云很热，多云也同样普遍。每家大型企业都是多云企业。每家公有云海报公司都在另一家公有云上拥有数据。原因多种多样——锁定、定价、应用程序、客户需求、运营敏捷性——但结果是一样的。多云不再是偶然事件，而是企业云战略的关键部分。

我们将在这篇文章中寻找答案的问题是：哪些类型的企业从多云中获益最大？取得成功的关键是什么？

让我们从成功的驱动因素开始，然后转向那些将从这些驱动因素中获益最大的企业。

在多云中取得成功有两个核心要素。第一个是 Kubernetes，第二个是对象存储。其他一切都是第三位的。

Kubernetes 的魔力

在最基本的层面上，Kubernetes 的价值在于它能够将基础设施视为代码——为软件堆栈的有状态和无状态组件提供完全规模的自动化。

Kubernetes 是大规模云计算的主流方法，因为它允许开发人员专注于功能（我们将回到这一点），而不必为可管理性或可移植性而苦恼。它还允许 IT 自动化可能损害正常运行时间的运营细枝末节。 

结果是，应用程序上市更快，无缝扩展，可以在任何地方运行。

Kubernetes 的魔力在于它是一种持续赠送的礼物。你投入 Kubernetes 越多，它就能自动化的东西越多，抽象的程度越高；你能够提取的价值就越大。这意味着应用程序、基础设施和数据。如果你只将 Kubernetes 用于应用程序，你仅仅利用了它价值的一小部分。因此，Kubernetes 不成比例地奖励大胆的人。这导致了对象存储的同步兴起，因为它比传统的块存储和文件存储选项更容易放入容器中。

对象存储浪潮

如前所述，CPU、网络和存储是 Kubernetes 要抽象的物理层。它们必须被抽象化，以便应用程序和数据存储可以在任何地方作为容器运行。特别是，数据存储包括所有持久性服务（数据库、消息队列和对象存储）。

从 Kubernetes 的角度来看，对象存储与任何其他键值存储或数据库没有什么不同。存储层简化为下面的物理或虚拟驱动器。将持久性数据存储作为容器运行的需要来自于混合云的可移植性。将基本服务留给外部物理设备或公有云，会失去 Kubernetes 自动化的优势。

传统上，应用程序依赖于数据库来存储和处理结构化数据；以及存储（如本地驱动器或分布式文件系统）来容纳其所有非结构化数据，甚至半结构化数据。然而，非结构化数据的迅速增长挑战了这种模式。正如开发人员很快发现的那样，POSIX（可移植操作系统接口）太啰嗦，开销太大，无法让应用程序以规模化运行，而且它被限制在数据中心（因为它从未打算提供跨区域和跨大陆的访问）。

这导致了他们转向对象存储，对象存储专为 RESTful API 设计（正如 AWS S3 首创的那样）。现在应用程序摆脱了处理本地存储的任何负担，使它们实际上变得无状态——因为状态在远程存储系统中。

如今，应用程序从一开始就基于这种预期构建。处理某种数据（日志、元数据、blob 等）的精心设计的现代应用程序，通过将状态保存到相关存储系统，符合云原生（RESTful API）设计原则。

这使得对象存储成为云的主要存储类别，这一点从公有云对对象存储的依赖（以及块存储和文件存储的定价）以及私有云和边缘出现的 高性能对象存储中可以看出来。

但有一个陷阱......

Kubernetes 是伟大的均衡器。与 S3 兼容的对象存储是 Kubernetes 的完美存储类别。组合并重复，对吧？

不幸的是，事实并非如此。事实证明，在其他公有云上找不到与 S3 兼容的对象存储。每个公有云存储服务——Google Cloud Storage、Azure Blob Storage、阿里云对象存储服务和 IBM Cloud Object Storage——都推出了自己的专有 API，并且从根本上彼此不兼容。

GCP——不与 S3 兼容。Azure——不与 S3 兼容。阿里云——不与 S3 兼容。IBM Cloud——不与 S3 兼容。Oracle Cloud——不与 S3 兼容。

从本质上来说，这个问题是可以解决的——Kubernetes 再次成为关键。**答案在于 Kubernetes 原生的软件定义对象存储。**有了它，你就拥有了运行你的应用程序所需的一切，无论其大小，都可以在任何云、本地部署和边缘环境中运行。

谁将从 Kubernetes 原生的软件定义对象存储中受益

来自 Andreessen Horowitz 团队的一篇精彩文章关于云成本的文章，针对公有云优先的企业。在这篇文章中，该团队建立了我们几个季度以来一直在说的事情：云是一个很棒的学习场所，可以专注于产品并保持敏捷，但从长远来看，它在规模上 simply doesn’t make sense。

想想云原生的精英。A16Z 确定了以下列表

它们都是以弹性计算、网络和存储为基础组件，以自助服务/多租户为客户参与方式构建的。但这并不是它们成功的关键，这些特性也不是公有云独有的。这些企业之所以能够成功扩展，是因为它们将重点放在了产品上，这几乎总是意味着在一个单一的公有云平台上运行。该公有云平台恰好是 AWS，原因显而易见——客户都在那里。它为 AWS 创造了一个异常强大的循环，一个异常有利可图的循环。

选择公有云很重要，但它并非改变游戏规则。成千上万的企业建立在 AWS 之上，但只有很少一部分进入了 Cloud 100 列表。那些能够进入榜单的企业拥有良好的产品/市场契合度，提供简洁性，易于使用，经济透明，并且能够以云原生方式动态扩展和收缩。

这些企业中的每一个都面临着一个合法且改变游戏规则的问题。**如果我必须继续增长，我必须在更多云上...那么我如何才能实现这一点？**这不仅仅是其他公有云——这个问题更广泛，包括私有云、Kubernetes 发行版，对某些企业来说，甚至意味着边缘云。

技术战略团队有两个选择可供考虑。第一，构建专业知识，并专门为他们想要使用的每个云的 API 集编写代码。第二，找到一个能够抽象化基础设施的解决方案，以便他们可以将应用程序架构简化为一个能够在任何云上运行的单一代码库。

我想你已经知道事情会往哪里发展了。

事实证明，定制的云集成是一个糟糕的主意。每个额外的原生集成都会增加数量级的复杂性。第三个云不会比前两个更容易——实际上更难。事实证明这是一个多体问题——更难抽象出功能和性能方面的不可避免的不一致，也更难管理与最低公分母相关的折衷方案。如果你投资专用团队，你每年将在工程师方面投入 500-1000 万美元（如果你能吸引和招募到他们的话）。存储成本会有所不同。同样，失去这些专业知识的成本也会有所不同。最终，它会导致应用程序代码出现 bug 和无法维护。

现代大规模存储

虽然 Kubernetes 在这方面解决了许多挑战，并且已经将云中基础设施堆栈的很大一部分商品化，但症结一直是存储。块存储和文件存储本质上不是云原生的，POSIX API 从可扩展性的角度来看，从未是 Kubernetes 的理想补充，从操作和可维护性的角度来看，也不是。为了让 Kubernetes 真正取得成功，它需要现代存储。

大规模的现代存储就是对象存储。就这么简单。

当这些企业能够将 Kubernetes 与与 S3 兼容、高性能、软件定义的对象存储配对时，他们就能解决这个问题。现在，这些企业可以从产品优先的角度攻击每个云，完全抽象化基础设施。这实际上改变了游戏规则。

当你选择与 S3 兼容、高性能、软件定义的对象存储（推广插件——就是我们）时，你可能每年只需要投入一小部分用于工程师的资金加上存储成本（或者在私有/边缘云的情况下是硬件成本），这使得经济效益显而易见——即使你将你的产品提供在 20 个平台上。

企业甚至可以选择自行构建基础设施云，借助像 Equinix 这样的创新型托管服务提供商和其他公司。在此，您需要对基础设施进行长期租赁，从而实现价格的可预测性、服务保障和全球覆盖范围。然后，您可以将您的 Azure、AWS、Oracle 和 Tanzu 实例指向此处。是的，您需要支付带宽费用；但具体取决于应用程序类型，如果主要为读取操作，则费用将明显降低。

多云策略

以下是多云架构师的策略手册。

步骤 1：通过专注于您的产品在公有云上构建一个出色的业务。它快速、简便且在一定程度上经济可行。我们建议以 AWS 作为起点，因为它拥有 S3。是的，竞争对手推荐竞争对手可能看起来很奇怪，但整个世界都应该感谢他们推广了 S3。

步骤 2：提升您的 Kubernetes 技能。在开发您的软件以在 Kubernetes 上运行方面建立专业知识，使其具有弹性、性能和可扩展性。现在是学习如何在容器中、在 Kubernetes 上充分利用您编写的代码的奥秘的最佳时机。如果您已经身处公有云（并遵循了我们的建议），那么您应该具备对象存储技能 - 很可能是 S3。

步骤 3：根据您自己的客户和策略考虑因素，以另一个云为起点，绘制您的全球统治路线图。使用 Kubernetes 和 MinIO（或其他与 S3 兼容、高性能、软件定义、Kubernetes 原生的对象存储）来完成迁移。

步骤 4：放手一搏。每个公有云。每个 Kubernetes 发行版。您自己的私有云。从客户的角度看，保持无差别。
这似乎过于简单，但实际上它确实有效，上面列出的大多数公司已经在完全按照这种方式进行操作。您 可以在一个下午亲自尝试一下。