多云架构师指南

在这一点上，混合云和多云之间的界限是模糊的。混合云的定义当然更广泛（公共、本地、边缘）。多云一般是指多个公有云。使它变得模糊的是，云是一种心态——而不是一个物理位置。因此，我们现在看到这些术语可以互换使用。

然而，有一点很清楚，独立于定义 - 两者成功所需的首要原则非常相似。

尽管混合云现在很热门，但多云也同样流行。每个大型企业都是多云企业。每个公共云海报公司都有另一个公共云上的数据。原因多种多样——锁定、定价、应用程序、客户需求、运营敏捷性——但结果是一样的。多云不再是偶然——它是企业云战略的重要组成部分。

我们将在这篇文章中回答的问题是：哪种类型的企业从多云中受益最大，成功的关键是什么？

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

在多云中取得成功有两个核心要素。第一个是 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 兼容的对象存储。每个公共云存储服务——谷歌云存储、Azure Blob 存储、阿里巴巴对象存储服务和 IBM 云对象存储——都引入了自己的专有 API，并且从根本上相互不兼容。

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

这本质上是可以解决的——Kubernetes 再次成为关键。答案来自 Kubernetes 原生的软件定义对象存储。有了它，您就拥有在每个云、本地和边缘环境上运行您的应用程序所需的一切，无论大小。

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

Andreessen Horowitz 的团队发表了一篇关于云对公共云优先公司的成本的精彩帖子。在那篇文章中，该团队建立在我们几个季度以来一直在说的东西之上：云是一个学习、专注于产品和敏捷的好地方，但从长远来看，它在规模上根本没有意义.

想想云原生精英。A16Z 标识此列表：

它们均采用弹性计算、网络和存储作为基础组件，并以自助服务/多租户作为客户参与工具。但这并不是他们成功的原因，这些特征也不是公共云独有的。这些企业通过专注于他们的产品成功地扩展了规模，这几乎总是意味着在单个公共云平台上运行。出于显而易见的原因，该公共云平台与 AWS 不成比例——这是客户所在的地方。它为 AWS 创造了一个异常强大的循环和一个非常有利可图的循环。

公共云的选择很重要，但它并没有改变游戏规则。有数以万计的企业建立在 AWS 之上，但其中很少有人进入 Cloud 100 名单。那些确实具有良好的产品/市场契合度、提供简单性、易于使用、具有透明的经济性并且可以在云原生上动态扩展和缩减。

这些公司中的每一家都拥有（或正在面临）一个合法的改变游戏规则的问题。如果我必须保持增长，我必须在更多的云上……那么我如何实现这一目标？这不仅仅是其他公共云——问题更广泛，包括私有云、Kubernetes 发行版，对于某些人来说，它甚至意味着边缘云。

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

我想你知道这是怎么回事。

定制的云集成被证明是一个糟糕的主意。每个额外的原生集成都会增加一个数量级的复杂性。第三朵云并不比前两朵云容易——它实际上更难。结果证明这是一个 n 体问题——更难抽象出功能和性能中不可避免的不一致，更难管理与最低公分母相关的妥协。如果您投资于专门的团队，您将在每个平台每年向工程师投资 5-1000 万美元（如果您可以吸引并加入他们）。存储成本会有所不同。失去部落知识的代价也是如此。最终，它会导致错误且无法维护的应用程序代码。

大规模的现代存储

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

现代大规模存储是对象存储。句号。

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

当您选择与 S3 兼容的高性能软件定义对象存储（促销插件——这就是我们）时，您每年可能会在工程师身上投资一小部分加上存储成本（或私有/边缘云的硬件成本） ，让经济变得轻而易举——即使您的产品在 20 个平台上可用。

企业甚至可以选择使用 Equinix 等创新托管服务提供商来推出自己的基础架构云。在这里，您对基础设施进行长期租赁——实现定价可预测性、服务保证和全球覆盖。然后将 Azure、AWS、Oracle 和 Tanzu 实例指向那里。是的，您为带宽付费；但根据应用程序类型，考虑到它主要是读取操作，它的成本会大大降低。

多云手册

这是多云架构师的手册。

第 1 步：通过专注于您的产品，在公共云上建立伟大的业务。它在一定程度上快速、简单且经济可行。由于 S3，我们喜欢 AWS 作为起点。是的，竞争对手推荐竞争对手似乎很奇怪，但整个世界都欠他们一个让 S3 普及的债。

第 2 步：开发您的 Kubernetes 组合。在开发在 Kubernetes 上运行的软件方面积累专业知识，使其具有弹性、高性能和可扩展性。现在是学习在容器中、在 Kubernetes 上充分利用您正在编写的代码的复杂性的时候了。如果您已经在公共云中（并遵循我们的建议），那么您就有对象存储的能力——可能是 S3。

第 3 步：根据您自己的客户和战略考虑，从另一个云开始绘制您的全球统治地位。使用 Kubernetes 和 MinIO（或其他与 S3 兼容的高性能软件定义的 Kubernetes 原生对象存储）来进行迁移。

第 4 步：做大。每个公共云。每个 Kubernetes 发行版。您自己的私有云。从客户的角度是不可知的。
这似乎过于简单，但实际上它确实有效，而且上面列表中的许多公司已经在这样做了。你可以自己试一试。