采用DevOps方式实现软件交付的原因之一是为了消除生产部署过程中的瓶颈，对于服务器端软件，通常涉及以下部分：
应用程序环境，如操作系统参数第三方组件，如应用程序服务器，web服务器和数据库顶部运行的应用软件为了消除部署瓶颈，DevOps旨在打破开发人员和IT运营人员之间的障碍（也是DevOps得名的原因），以促进协作的工作环境。因此，需要确保生产环境与开发环境保持同步，并且所有部署过程一起执行。实现这一目标的方式之一是通过使用容器，如Docker或Kubernetes。事实上，很多人将容器和DevOps理解成了同义词，并且将这两者建立了依赖的关系。
但是，这两者不需要依赖关系：完全可以在非容器环境下实现DevOps。
容器是管理运行软件的操作系统的轻量级的抽象，它能够将进程彼此隔离，对资源使用加以限制，并帮助打包软件依赖。容器不会替代虚拟化，因为容器的操作更接近应用程序级别，而不是物理级别。
容器的高效率使得它应用非常广泛，通过容器用户可以快速部署并实现软件组件联机，与虚拟化相比它能够以较低的成本启动新的应用案例，用户可以更紧密地控制应用程序环境。例如，如果开发人员在容器中编写和构建软件，则容器及其中的一切都可以被打包并传输到生产服务器。效率和自动化使得DevOps和云运行良好。
容器中好的DevOps用例始终围绕着快速上线新服务器连接的需求，这通常是微服务部署的案例。容器可以非常有效地快速启动和破坏微服务和开发/测试环境，除此以外，在DevOps中使用容器更多的是一个选择，而不是一个需求，DevOps远不止目前这些。
非容器环境下无痛部署不管容器能带来多少好处，有很多理由支持我们不采用容器化的方法来进行软件部署。包括：
缺乏容器技能或相关知识特殊应用性能要求（即实时系统）实用软件环境下不支持的硬件（即嵌入式系统，专用或传统操作系统）公有云部署等等不依赖容器来实现DevOps的成功，需要关注以下3点：
1、自动化：通过工具尽可能地实现自动化，无论是大型机应用程序还是微服务，都可以通过工具来减少手动工作量及其失误。
2、持续集成：连续测试软件模块、组件、服务等，不要等到开发结束之后才集成和部署系统。
3、连续测试：通过持续集成，确保系统始终可用、可测试且理论上可释放，测试开发工作的结果是反馈循环的一部分。
特定的构建和部署工具是有帮助的，并且通常需要达到使部署简化的自动化水平。然而，DevOps的最大成就主要来自于三个方向的努力：
持续开发构建和测试周期更频繁地部署到生产服务器直接和即时反馈给开发人员通过这三个努力，软件永远不会被孤立地构建，组件不断地进行集成，而且每个人都能知道需要改进的地方一切正常。因此，开发和IT部门可以保证正在构建的内容将按照预期的方式进行部署和运行。业务上线的过程中就在不断地突破瓶颈，因为在部署过程和生产环境中伴随着软件的测试，因此在开发周期结束时可以正常使用。
人员是DevOps成功的关键成功的关键不是工具集，而是人员、沟通和度量。因为使用DevOps实践，当开发新版本的软件时间被限制在几周或者几个月内，在最终期限到来的时候，用户不用担心软件的部署对生产造成的影响，因为在开发过程中一直在进行测试。
这就是为什么它被称为DevOps实践，而不是DevOps过程、DevOps组、DevOps工具集或DevOps环境。容器可是成为DevOps实践的一个补充，帮助管理生产环境，但它不应该是DevOps必须的。相反，专注于DevOps实践，并在这个过程中使用容器才有意义。
本文转自d1net（转载）
