架构师的混合云指南

随着我们逐渐进入 2021 年，一些技术趋势正在主导着 IT 架构师的讨论。其中最主要的是 Kubernetes。相关的，并且迅速成为“标准”的是混合云。

在规划混合云时，架构师角色中固有的挑战只会加剧。首先，它是新事物，市场营销往往会超过事实。其次，它在不断发展——这要求架构师对未来趋势有强烈的洞察力。第三，组织正在改变和适应全球性流行病带来的挑战和磨难。最后，这是一项长期规划，但需要短期成果——我们唯一可以确定的是，现代企业无法容忍技术真空。毕竟，真空正是引发多云现象的最初原因。

现在是为混乱带来秩序的机会。在最根本的层面上，架构师必须在各种环境中提供一致性。开发人员一致性、应用程序一致性、用户界面一致性、性能一致性。列表可以继续下去，但就一致性而言，成功标准保持不变。

这篇文章将重点关注一个元素，尽管它在任何混合云架构中都是一个非常关键的元素：存储。在我们进一步讨论之前，我们应该提到，本文只关注对象存储。对象存储是云和 Kubernetes 的存储类别。这使得它成为混合云的存储类别。文件和块系统目前已成为遗留系统——人们只需看看公共云中如何对其进行定价，便可以理解这一事实。

从架构师的角度来看，从定义游戏规则开始会有所帮助。人们倾向于使用“公共云”和“内部部署”这些术语，并就此结束对混合云的定义。然而，事实是，混合云是多维度的。

为了提供一个功能性的混合云架构，你需要制定一个可以在以下环境中运行的存储策略。

公有云 - 这是一个越来越大的领域，但始于 AWS、Azure、GCP、IBM、阿里巴巴和腾讯。你的混合云存储软件需要在你的业务运行的任何地方运行。即使声称运行在单个云上的公司也并非如此——总是存在其他云，你只是还没有发现它们而已。

私有云 - 私有云的定义在不断演变，混合云存储的作用也需要随着这种新兴架构而演变。私有云是一个概念，而不是一个地方，现代私有云通常位于非现场数据中心、虚拟专用网络和虚拟专用云中。你的混合云存储需要在你的云计算基础设施运行的任何地方无障碍地运行。

Kubernetes 发行版 - 通常被忽视的是，Kubernetes 发行版可以被认为是私有云的一个子类别，但我们将其视为单独的实体，因为它们不适合自行构建的方式。为了在这里运行，你的混合云存储解决方案需要是对象存储、软件定义和云原生。选项包括 VMware（Tanzu）、HP（Ezmeral）、Cisco（IKE）、RedHat（OpenShift）和 Rancher/SUSE。

边缘 - 也经常被忽视，边缘是任何混合云架构的重要组成部分。你的混合云存储解决方案需要轻量级、功能强大、云原生且速度快，以便在边缘运行。尽管边缘在当今的重要性各不相同，但这种重要性只会越来越高——随之而来的是小型对象的挑战。设计混合系统的架构师需要清楚地思考边缘的影响。

混合云存储的属性

鉴于这些混合云参数——跨公共云、私有云、Kubernetes 发行版和边缘部署的对象存储——成功的属性是什么？我建议考虑以下因素

一致性 - 如前所述，目标是用户体验、应用程序性能和开发人员体验的一致性。路线图很好，但数据可以信赖。哪些对象存储解决方案可以在多个公共云中运行，跨 Kubernetes 发行版运行，以及在边缘运行？是否存在会阻碍解决方案在这些环境中取得成功的因素？例如，设备不适合编排。它无法在各个环境中提供一致性。公共云是另一个一致性受到威胁的领域。主要参与者越来越多地谈论他们的内部部署产品，以及他们在彼此的云中运行的雄心壮志。这与他们在运行服务的经验如何协调，而服务需要对硬件拥有完全控制权？他们真的能保证一致性吗？

性能 - 性能扩展了你可以与对象存储配对的应用程序池。几乎所有现代工作负载都需要性能。如果你没有性能，你就无法运行 Spark、Presto、Tensorflow 或其他任何已成为企业格局定义的 AI/ML 和大数据应用程序。即使是归档工作负载也受益于性能。哪个企业会设计一个缓慢的恢复流程？

架构师不仅需要为性能设计，还需要为大规模性能设计。这是现代对象存储闪耀的地方。长期以来，对象存储一直以廉价和缓慢而闻名，但新的对象存储产品可以在标准硬件上以每秒数百 GB 的速度读写。并非每个工作负载都需要这种性能，但每个工作负载都希望有这种性能。为了服务于最广泛的受众，架构师需要为速度而设计。

规模 - 规模通常被错误地理解为系统的理论极限。虽然对象存储被认为是无限可扩展的，但每个人都知道实际上并非如此。可扩展性具有多个维度。架构师需要考虑扩展的运营效率以及可能出现的瓶颈。例如，使用外部元数据数据库的对象存储 simply 无法扩展到某个点。它们不是大规模基础设施的合适选择。

混合云对象存储解决方案需要以相同的方式进行扩展——无论环境如何——并且需要简单、最少的人工干预和最大程度的自动化。

软件定义 - 对于一个考虑在多个云（公共云、私有云、边缘）上运行多个工作负载的架构师来说，只有一个答案：软件。多个环境决定了其他异构硬件。软件抽象了后端物理存储，是架构师在这项工作中的主要工具（参见 Kubernetes）。软件定义了用户体验，提供了灵活性和可扩展性。

云原生 - 对于一个考虑存储的架构师来说，这可能是一个可以“忽略”的组件，因为很少有供应商真正是云原生的。不要这样做。正如豹子不能改变它的斑点一样，设备供应商也不能突然变成软件定义和云原生。云原生既是一种哲学，也是一系列技术和原则的集合。如果 Kubernetes、容器、微服务、S3 和 API 从一开始就不是计划的一部分，那么总是会存在摩擦。它不应完全取消非云原生存储供应商的资格，但它应该让人停下来思考。过去对内部部署有效的方案不适用于云。五年前成为关键供应商关系的方案可能与正在出现的架构无关。

框架 这篇文章旨在为展望未来的企业云架构师提供一个框架。任何成功规划活动的关键是挑战你的思维，并围绕计划的关键组成部分创建尽可能多的细节。规划混合云存储架构需要非凡的纪律和对先前信念的深入评估。然而，对于企业来说，回报可能是巨大的——从成本节约的角度和竞争力的角度。

欢迎随时联系我们，在 Slack 上与我们互动或通过电子邮件联系我们 hello@min.io ，以继续讨论。