在过去十年中几乎无处不在的敏捷软件开发是一场革命。与瀑布式开发不同，其长周期需要提前六到九个月进行规划，敏捷进来了，只需要提前两到四个星期规划快速迭代，每个迭代都可能是可交付的。至少，这就是将敏捷卖给管理层的方式。
然而，它带来了一个问题，大多数转向敏捷的组织直到他们的第一个冲刺结束时才发现。问题在于，快速迭代的能力取决于出色的质量保证 (QA) 自动化，它可以在数小时内完成回归测试，而传统瀑布式测试需要几个月才能完成。
仅仅良好的 QA 自动化不足以实现真正高效的敏捷开发过程，而且大多数组织在自动化方面处于糟糕和不存在之间。缩小自动化差距的需求直接导致了对经验丰富的自动化工程师的快速且不断增长的需求。然而，有幸聘请了优秀的自动化工程师并消除了敏捷流程的这一障碍的组织发现了另一个主要障碍：大量的质量自动化需要大量的自动化环境。
创建敏捷开发所需的许多自动化环境可能是一项繁重的工作，尤其是在使用物理硬件时。许多组织不得不虚拟化他们的开发和测试环境，以从他们对自动化的大量投资中获得最大价值，并推动他们的敏捷开发流程向前发展。
幸运的是，大约在这个时候，业界看到了私有云和公共云以及基础设施即代码的迅速崛起，所有这些都催生了 DevOps。
DevOps 和虚拟机
DevOps 迅速成为推动敏捷软件开发向前发展的下一个瓶颈，组织通过聘请 DevOps 工程师以及随之而来的基础设施即代码 (IaC) 投资来做出回应。但随着 DevOps 工程师构建广泛的 CI/CD 管道，主导框架是虚拟机，无论是私有云中的 VMware 虚拟机 (VM)，还是 AWS 中的 EC2 实例。
这就是问题所在。就其性质而言，VM 相对较重且笨重。要启动一个，您必须首先制作一份 VM 模板的副本，这取决于所涉及的启动和数据卷的大小，可能需要 10 到 20 分钟或更长时间。然后启动和稳定 VM 需要额外的几分钟。并行启动多个虚拟机实际上会减慢速度，因为它们经常竞争存储 IOPS、CPU 和网络带宽。
一个相对简单的管道启动构建环境，然后是单元测试环境，然后是回归测试环境，可能涉及创建和启动多个 VM，需要几个小时。最佳的敏捷自动化策略要求在每次提交时运行 CI 管道，例如上面概述的 CI 管道，这很容易意味着每天有数十个管道。在使用 VM 时，这可能是一个巨大的挑战。
容器来了
作为 DevOps 基础设施的虚拟机的现代替代品是容器，它克服了阻碍虚拟机的限制。容器非常轻量级，并且随着操作系统进程的启动而快速启动。使用虚拟机在 10 或 20 分钟内启动的管道可以在不到一分钟的时间内开始运行容器。更重要的是，因为它们是轻量级的，容器需要的 CPU、网络和存储资源要少得多，因此它们的运行成本比 VM 低。
没有能力为每个单独的提交处理 CI/CD 管道的 VM 基础设施可能能够通过将硬件重新用于 Kubernetes 和容器来处理使用容器的负载。容器使敏捷组织能够在从自动化和 DevOps 投资中获取全部价值方面向前迈出一大步。
事实上，前瞻性组织正在容器化他们的应用程序并在 Kubernetes 上运行他们的 CI/CD 管道以加速敏捷开发。为了从基于 Kubernetes 的 CI/CD 环境中获得最大价值，将它们与容器原生存储结合起来很重要。容器原生存储支持卷的即时克隆和跨 Kubernetes 集群的数据卷的即时访问。
在这样的环境中，Kubernetes 集群可以轻松地专用于开发、测试、集成和暂存环境，这为 DevOps 工程师提供了最大的灵活性。测试数据可以在不同的管道之间克隆并在 Kubernetes 集群之间无缝移动，减少管道运行的持续时间，同时保持不同环境之间的隔离。使用容器原生存储，在 Kubernetes 集群之间和管道阶段之间移动数据所需的时间减少到仅仅几秒钟。
使用敏捷软件开发方法的组织已经取得了长足的进步。自动化比以前更广泛、更深入，DevOps 现在支持复杂的 CI/CD 管道，使组织能够从自动化中获得全部好处并加速开发。然而，使用虚拟机的组织受到需要花费数小时运行和使用大量资源的管道的束缚。为了缩短管道的持续时间并运行更多管道，现代软件开发组织正在使用容器原生存储将其应用程序容器化并在 Kubernetes 上运行其 CI/CD 管道，以充分利用敏捷流程的优势来加速软件开发。