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

对于每个在最高速度级别运行DevOps的亚马逊或Etsy，都有成千上万像我这样的团队，我将慷慨地称之为正在进行中的工作。 “链条的强度取决于最薄弱的环节”这句老话无疑适用于DevOps。每个DevOps组织都有自己的优势和劣势。也许您的CI/CD管道高度自动化，但由于遗留的审批步骤，部署频率滞后。也许团队在单元和回归测试方面缺乏实力，因此代码提交频率较低。也可能是缺乏指标限制了问题的识别，因此平均故障修复时间（MTTR）可以得到改善。

然后

虽然看起来它们“已经过时了”，但我发现DevOps成熟度模型对于团队进行自我评估和突出显示这些薄弱环节，然后为达到下一级规定所需内容是一个很好的方法。在加入MinIO之前，我的团队踏上了将DevOps原则应用于我们的文化、流程和技术的旅程。在许多公司，文化阻力是最难的部分；我很幸运地成为一家支持DevOps文化的开源公司的成员。我们致力于敏捷，甚至可以说我们是敏捷狂热者，但我们意识到我们正在努力支持敏捷流程和报告工具，而不是流程支持预期的结果。最终，我们放弃了大多数敏捷仪式，只保留了每日站立会议，并转向基于看板的活动管理。在技术方面，我们已经大量投资于Git、Jenkins和Ansible，它们之间拥有坚实的基础工具来增强我们的CI/CD管道。

在三年时间里，我们取得了巨大的进步，能够以高度的自动化从开发人员桌面迁移到生产环境。为了评估我们的进展和下一步行动，我们的领导团队进行了一次规划会议，在此会议上，我们使用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兼容性，并简化部署最小开发环境来解决这个问题，该环境可以轻松地扩展到云，并提供一个简化的RESTful接口到您的数据层。

MinIO本质上是分布式的，具有数据的主主复制，以及在后备驱动器发生故障时继续运行的能力。MinIO实施的写一次读多次功能意味着，无论部署如何，您的数据完整性都能得到维护，您花费在解决读错误或数据争用问题上的时间更少。此外，永远不用担心数据因覆盖而丢失，因为您的MinIO存储桶中提供了版本控制！此外，MinIO的声明式部署过程意味着您可以根据需要，在需要的时候，使用所有常见的基于Kubernetes的部署工具来设置您需要的功能。所有这些功能共同使MinIO成为开发任何规模的以大数据为驱动力的应用程序的最佳选择。