使用云原生对象存储支持 DevOps 最佳实践

对于每个以最高速度运行 DevOps 的 Amazon 或 Etsy，都有成千上万的团队像我一样，我将慷慨地称之为正在进行的工作。链条的强度取决于其最薄弱的环节，这句古老的格言当然适用于 DevOps。每个 DevOps 组织都有自己的优势和劣势。也许您的 CI/CD 管道是高度自动化的，但由于遗留的审批步骤导致部署频率滞后。也许团队在单元和回归测试方面缺乏实力，因此代码提交频率较低。可能是缺乏指标限制了问题识别，因此可以改进平均解决时间 (MTTR)。

然后

虽然他们看起来“2018 年如此”，但我发现 DevOps 成熟度模型是团队自我评估和突出那些薄弱环节然后规定达到下一个水平所需的条件的好方法。在加入 MinIO 之前，我的团队开始了将 DevOps 原则应用于我们的文化、流程和技术的旅程。在许多公司中，文化阻力是最难的部分；我很幸运能够成为倡导 DevOps 文化的开源公司的一员。我们致力于敏捷，甚至有人可能会说我们是敏捷书呆子，但我们开始意识到我们正在努力支持敏捷流程和报告工具，而不是支持预期结果的流程。最终，我们放弃了大多数敏捷仪式，只保留每日站立会议并转向基于看板的活动管理。在技术方面，

在三年的时间里，我们取得了巨大的进步，并且能够以高度自动化的方式从开发人员桌面转到生产环境。为了评估我们的进展和后续步骤，我们的领导团队召开了一次规划会议，在会议中我们使用 DevOps 成熟度模型评估了自己。很明显，我们在单元测试和指标方面存在缺陷，而这两者的缺乏已成为进一步提高效率和质量的制约因素。通过成熟度模型的视角，我们能够更好地查明我们的不足并召集团队来弥补这些不足。

现在

快进两年了，我很荣幸加入软件定义数据存储领域的领导者 MinIO。MinIO 跨 Kubernetes、公共云和私有云以及虚拟化环境提供高性能、S3 兼容的对象存储。安顿下来后，我开始寻找解决数据访问和存储基础设施问题的 DevOps 成熟度模型，但很惊讶没有找到等效的框架。过时的数据访问和存储基础设施可能是云原生应用程序的薄弱环节。

因此，我决定尝试扩展 DevOps 成熟度模型结构，以纳入云原生数据存储架构。

多云数据访问和存储基础设施的 DevOps 成熟度模型

传统的 SAN 和 NAS 系统与 POSIX 数据库相结合，提供了良好的文件系统数据库性能，但代表了 DevOps 的反模式——即使不是不可能，也很难过渡到基于版本控制的数据库即代码模型。传统的存储系统是单一的和僵硬的——大量的时间花在解决这个技术债务上，使像 JPA 这样的遗留 API 永久存在，这些 API 允许数据库在不成为 DevOps 架构本身的一部分的情况下持久存在。

使用商用硬件和 HDFS 等协议的软件定义块存储的引入是面向大型批处理工作负载的一大进步。块存储在可扩展性和性能方面对文件存储进行了重大改进，Hadoop 引入了基于 API 的接口，简化了应用程序开发并为 CI/CD 打下了基础。

对象存储的引入将数据和存储转变为真正的“即服务”模型，这对于 DevOps 管道的蓬勃发展至关重要。AWS 的 S3 API 进一步提高了开发人员的速度，并提供了一种有效管理非结构化数据指数增长的工具。通过利用 S3 API 和对象存储的固有优势，开发团队能够实现更紧密的 DevOps 无限循环，部署频率增加、错误减少和问题的 MTTR 降低就是证明。虽然每个公有云厂商都推出了自己的存储模型和RESTful API，但S3 API已经成为事实上的标准，这既是AWS的市场份额的作用，也是S3 API本身的能力。

在成熟度模型的顶端运行的 DevOps 商店利用基于 Linux 的容器和基于 Kubernetes 的编排从底层计算、网络和存储基础设施中提取应用程序。该架构非常适合云原生，其中各个服务作为离散容器存在，并且可以在不中断应用程序正常运行时间的情况下即时升级（或回滚）。有趣的是，存储抽象并没有降低数据访问和存储的重要性——相反，云原生应用程序需要高性能的存储基础设施！

DevOps 和 MinIO

MinIO 对象存储提供了传统架构和存储配置无法提供的功能——适用于 Kubernetes 的高性能、有弹性且可扩展的存储基础设施。

在 Kubernetes 集群中，MinIO 提供原生的、基于操作符的功能，支持多层底层存储。当 Kubernetes 部署到公共云中时，多层功能尤其引人注目，因为容器化应用程序可以通过单一界面利用 NVMe、HDD 和云提供商的存储。MinIO 优化了应用程序性能，同时还优化了云存储、网络和计算支出。

如果存储和数据基础架构不是分布式的、解耦的、声明式的和不可变的，那么持续交付就会受到限制，并且开发-测试-阶段-生产周期中的回归更为常见。持续交付的解耦原则旨在确保，随着您的应用程序在整个周期中移动，它不会与您的数据基础架构的特定实现相关联。MinIO 通过在从开发到生产的每个级别实现 S3 兼容性来解决这个问题，并使部署最小的开发环境变得简单，该环境可以通过简化的数据层 REST-ful 接口轻松扩展和扩展到云。

就其本质而言，MinIO 是分布式的，具有数据的主动-主动复制，以及在支持驱动器发生故障时继续运行的能力。MinIO 实施的一次写入多次读取功能意味着无论部署如何，您的数据完整性都会得到维护，并且您可以花费更少的时间来围绕读取错误或数据争用问题进行编码。此外，通过在您的 MinIO 存储桶中进行版本控制，再也不用担心因覆盖而丢失数据！MinIO 的声明式部署过程意味着您可以使用基于 Kubernetes 的部署的所有常用工具，随时随地提供您需要的功能。所有这些特性共同使 MinIO 成为开发任何规模的大数据驱动应用程序的最佳选择。

MinIO 有助于将数据层与应用程序分离，在执行部署时提供持久性和连续性。此外，MinIO 严格遵守 S3 兼容性，为开发人员提供了熟悉的事实上的标准 API，可加速开发并确保跨架构的互操作性。应用程序可以从非常小的笔记本电脑占用空间开始，并推进到多节点和多数据中心生产部署，而无需对云支持或本地集群部署进行任何代码修改，使用 MinIO 服务或其他符合 S3 的实现。此外，您的数据层可以更容易地得到最有意义的基础架构的支持，例如，将您的热数据保存在本地快速 NVMe 上，并将冷数据保存在云中。与外部管理和安全服务及应用程序集成，例如 Keycloak、Active Directory 或 LDAP 等身份提供者，集中控制，简化部署并提供跨任何云、本地和边缘的关键保护。对于寻求优化的 DevOps 组织通过容器自动化和基础架构即代码的速度，MinIO 完成了最佳架构，以加快上市时间并推动业务成果。你可以自己尝试，你可以下载 MinIO MinIO 完成最佳架构以加快上市时间并推动业务成果。你可以自己尝试，你可以下载 MinIO MinIO 完成最佳架构以加快上市时间并推动业务成果。你可以自己尝试，你可以下载 MinIO在这里，并在此处获得有关一般 Slack 频道的帮助。