任何DevOps计划的核心是容器和微型服务的明智使用，这将极大地加快和简化开发人员和运营团队的工作。虽然IT管理的许多尝试和真正的规则都适用，但容器和微服务也增加了新的考虑因素，以及新的做事方式。

为了探索与成功的容器和微服务部署相关的许多IT管理问题，我们转向该领域两位经验丰富的专家AsheshBadani，副总裁兼Red Hat的Open Shift总经理和业界公认的思想领袖Marc Wilczek的观察。

BADANI，在企业家项目的写作，观察到容器和微服务的最终目标--以及它们能够实现的DevOps--是灵活性。"容器Corral应用程序是一个整洁的包，与它们运行的主机系统隔离。开发人员可以在实验过程中轻松地移动它们，这是DevOps的一个基本部分。当您从开发到生产环境的快速移动时，容器也会被证明是有帮助的。"

Wilczek在CIO最近的一篇文章中解释说，开发人员特别热衷于容器启用的微服务，原因有几个。“它们使开发人员能够快速地隔离功能，从而节省时间和精力，并提高整体生产率。与单体系统不同的是，即使是最微小的改变，也需要构建和部署整个应用程序，每个微服务只处理一个问题。”

与任何有希望的新技术或方法一样，在组织和技术方面都存在着障碍。BADINI和Wilczek提供了SAGE建议，以克服可能会影响移动到微服务和集装箱化架构的主要速度凸块：

组织技能和准备状态：在进行任何微型服务工作之前，整个企业的人员都需要参与其中，并准备好调整自己的思维方式。巴迪尼警告说：“推动文化变革的IT领导者需要团队中的首席执行官和传道者的支持。”他警告说，“最容易做的事情就是无所事事。”但当今竞争激烈、速度快的经济环境要求集装箱和微型服务的速度和敏捷性成为可能。巴达尼补充说，好消息是，“你不需要Facebook的所有资源或技能就能做出重大的业务改变。开始与较小的团队进行实验。随着你成功并变得更加舒适，在技术和人才方面展开拓展。鼓励你的团队中的人与公司以外的同行接触，谈论技术和文化挑战。”

平台。Badani说：“平台的选择是容器和微服务工作的关键。平台解决了管理、治理和安全问题。尽管有大量开源容器工具进行实验，但是企业级的容器平台通常包括几十个开源项目，其中包括Kubernetes业务流程、安全、网络、管理、构建自动化以及开箱即用的连续集成和部署功能。”

Wilczek说，容量和生命周期管理：容器和微服务都可以很容易地被替换，因此往往具有相对较短的寿命”，Wilczek说，与巨大密度结合的短寿命导致了需要监控的空前数量的项目。此外，容器需要大量的存储空间。挑战在于，"利用它们自己的操作环境,图像可以容易地达到几百兆字节的大小,"wilczek说。他建议持续的生命周期管理实践--"尤其是将旧图像退休以释放共享资源并避免容量限制。"能够快速淘汰容器，以释放存储空间，需要全面的生命周期管理努力。

网络层：Wilczek警告说，网络甚至虚拟化网络层可能会被证明是微服务和集装箱化体系结构性能的瓶颈，因此需要"在性能、负载平衡和无缝交互方面进行密切监控。"

平衡遗留和云本地应用程序：现有基础设施和新的云传应用程序之间的权衡可能是一个症结，但这是正常的，巴达尼解释说。“一些首席信息官仍然需要支持COBOL应用程序。利用新旧技术并进行权衡是正常的。一些公司寻求的容器主要是容纳应用程序开发团队正在创建的云本地应用程序，包括新的工作和现有应用程序的修改。这些应用程序通常是基于微服务的。目的是将应用程序分解为其底层服务，这样团队就可以独立地更新应用程序。”.

监测："许多传统IT监控工具不提供对组成这些微服务的容器的可见性，导致主机和最终关闭雷达的应用程序之间的间隙，"Wilczek警告。"组织需要在包括两个世界的地方建立一个共同的监控，并从底部到顶部覆盖整个IT堆栈。"

可管理性各组织需要确保有足够的人力资源专门用于集装箱和微型服务的部署和管理。Wilczek说：“开发人员常常试图通过创建另一个微服务来增加新功能。”“在任何时候，组织都会发现自己试图管理一大批容器和无数的微型服务，以争夺同样的IT基础设施。”他建议使用“发现重复服务的分析工具，以及检测容器中的模式被Havior和消费，以优先访问系统资源”。

由于容器包含系统特定的库和依赖关系，它们更易于受到新发现的安全漏洞的影响，”Badani说，世卫组织建议使用可信的注册表、映像扫描和管理工具，帮助自动识别和修补容器映像。