作为一名技术编辑，我在工作中经常与人讨论他们的容器化战略。在刚开始接触容器的时候，人们总是希望得到容器技术所带来的利好，而没有想到过破坏性容器。他们可能有一两个基于容器的系统，或者在使用云技术，但是没有明确的战略。
在你兴奋的全力奔向容器之前，最好弄清楚破坏性容器是什么。我建议人们建立短期和长期的目标，并且在容器化的道路上适应新的需求并且接受其文化内涵。
Devops团队要开始使用容器的原因是：
首先，加快应用程序的开发和部署：容器简洁、轻便、快速，你可以很容易的开始使用基于热门开源项目的现成模版图像和显影容器。准备就绪之后，你可以打包你的任务为容器映象，并在生产环境中运行，与你在开发环境中所做的完全一样。如果将自动化添加到进程中，比如CI/CD工具，那么进程将变得更快。
其次，将应用程序迁移到云中：容器的另一个非常有用的特性是它们的可移植性。容器化一个应用程序来自主操作系统和物理基础设施，相同的容器可以在前提下运行也可以在公有或私有云中运行，而不需要转换部署格式或更改代码。
最后，转向微服务构架：每个容器通常是单一的指向，单一的过程，并且恰当的校准微服务构架。组织正在寻找更好的方法来开发和维护应用程序，离开那些难以维持微服务构架的大型应用程序，会有助于开发和升级。容器是微服务构架的完美平台，生态系统的涌现使得大型微服务战略得以实施。
容器化你的应用有很多好处，但问题是从哪里开始呢？你应该把过去的应用重构为现代微服务构架容器还是应该用容器制造一些新的东西？
有时我们也会尝试用另一种方法，容器化现有的应用程序而不是重构为微服务的模式？当我们容器化一个应用程序的时候，整体的应用程序可能和容器不兼容，你可能会损失一部分微服务应用带来的利好，特别是易于维护和更新的选项，但是仍然有很多可以保留的地方。
容器化一个应用程序可以使你把容器带到环境中，帮助你去构建团队和建立流程，优化这之间的过渡，直到完成一个基于微服务构架的应用程序。
在容器化的结尾，你会想有一个管道和工具链，可以用于新的微服务和管理旧应用程序的打包。通过这种方式，您可以规范容器周围的所有进程，甚至可以在容器中运行遗留的单片应用程序。使用这个方法的优势是，你可以把微服务绑定在现有的应用程序上，然后所有的新功能都可以基于微服务构架。
一个最近比较流行的混合的方法是，用Devops的已知案例来提升和转移。"提升和转移"是指容器化过程中的一个前提。用单一的应用程序来解除它（通常来自旧的数据中心）并将其转移到其他地方（通常是现代公共或私有云）。
然而，作为一个提示，提升和转移应该不仅仅只是一个传送机制。它为转化为微服务构架模式提供了基础，并且以可管理的方式将容器引入环境中。这就是为什么它可以迅速成为一种Devop团队容器化的流行方法。但是当用于提供更有效的一系列好处时，对于那些想在容器战略上表现出实质性进展的人来说，这可能是一个快速的胜利。
如果你的目标是用容器重新构建一个遗留应用程序的话，完整改写微服务构架是重要的一步。这中间有许多环节，如分成几大块重构应用程序。它还将提供一些好处，让你逐步深入到真正的微服务构架中去。正如Devops团队决定如何运用容器技术一样，他们可能会考虑建立外部联系，因为外部的投资可以支持更长远的创新。就像我在博客中命名的"DevSecOps"，我把安全小组放在列表的首位，我认为它将会是Devops有用的伙伴，非常有战略意义。
不管在安全和Devop之间会存在什么样的障碍，Devops的协作精神对于安全人员来说很有吸引力。安全小组不仅可以成为强大的盟友，他们可能在安全和IT风险方面有更长远的考虑，这可以加强对特定应用程序容器化的Devops驱动业务。
最后，对于重建或容器化现有应用程序，两难在于，没有一个解决方案是适合所有人的，这就是为什么快速获胜是非常重要的。所以不管你决定怎么做，做好计划，去创造一个现实的成功标准吧！
技术名词解释：
容器：容器技术虚拟化技术已经成为一种被大家广泛认可的容器技术服务器资源共享方式，容器技术可以在按需构建容器技术操作系统实例的过程当中为系统管理员提供极大的灵活性。
Devops：英文是Development和Operations的组合，是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
微服务构架：微服务是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务。
