容器作为一种赋能技术，在企业IT规划中扮演着重要的角色。其中原因不言而喻，它能帮助企业获得快速发展。毕竟对于数字化业务而言，速度就是金钱。为了实现业务敏捷度，IT领导者希望颠覆以往的二八模式，即将80%的预算用于维护，仅投入20%预算进行创新。如今，CIO们希望将更多预算用来帮助企业建立敏捷性与敏锐性。
容器、DevOps以及微服务等要素组合起来，可以帮助CIO们实现这一目标。
简而言之，容器将应用程序封装在单一程序包当中，与运行所在的主机系统相隔离。开发人员能够在开发过程中，轻松移动这些程序包，这也是DevOps理念中的基本要求。从开发环境快速迁移至生产环境时，容器技术同样具有重大意义。
仅仅技术本身并不能解决问题，在多个跨职能DevOps小组和重新考虑流程以及业务边界时，CIO还需要直面文化层面的种种挑战。无论是技术还是文化，CIO都可以从同行身上学到很多东西。本文介绍了企业采用容器的四种典型方式，并列举出每种方式所需要注意的事项。
当然，对于任何一家企业而言，并不存在完美的容器部署方式。你可以以一条路径作为切入点，之后再切换至其他路径。另外，企业内部的不同团队往往也会采取不同的容器部署方式。因此，企业内部往往同时存在多种容器部署模式。
引入容器平台
不少企业在开始使用容器之后，很快意识到自己需要一套平台。通常，由特定的小组(例如DevOps小组)在推进变更的过程中，引入一套用于快速执行实验及部署的敏捷性技术平台。在此过程中，容器就成了理想的解决方案，他们会力争说服领导者接纳容器，并最终将其作为企业运营的固定组成部分。关键问题在于，企业应该使用哪种平台部署并管理容器?尽管目前市面上存在着大量开源容器工具，但企业级容器平台通常囊括数十种开源项目，包括Kubernetes编排、安全性、网络、管理、自动化构建以及持续集成/部署等功能。总而言之，这类平台有助于解决管理、治理以及安全性方面的诸多问题。
对于这条路径，企业可以先从易于实现的目标入手。 Web服务器与应用程序服务器往往是最易于作为容器化工作负载进行部署的目标，然后进一步引入数据库与有状态系统，同时密切关注与现有构建及部署工具/流程的集成效果，把握进展情况。
除此以外，也要考虑容器安全问题。由于容器中包含系统特定的库与依赖项，因此更不容易发现隐藏的安全漏洞，可信注册表、镜像扫描与管理工具可实现自动识别并修复容器镜像。
打造云原生应用容器
一些企业更倾向于使用由应用程序开发团队打造的云原生应用容器，其中包括新项目以及对原有应用程序的改造成果。这类应用程序通常以微服务架构为基础，目标在于将应用程序拆分为多项基础服务，以便团队可以针对各独立组件进行应用程序更新。IT团队还可以使用灵活的API实现这类目标。
如果采用此种模式，企业应使用安全且易于理解的API集在应用程序当中同其他自有，或者第三方应用程序、系统及数据进行交互。另外，还需要充分考虑如何将其与现有系统相集成。由此可以看出，容器与微服务及API相结合，将帮助开发团队更轻松地开发、协同并部署云原生应用程序。
在考虑使用新的运行时，以往部署的单体式应用服务器很难用于运行下一代应用程序，这是因为后者往往采用事件驱动设计、响应式以及无服务器等新兴技术。容器平台必须有能力支持广泛的现有及云原生运行时与框架方案。同时，也要关注开发者工具，在运行时不断发展的同时，立足云端的开发者工具，也有望高效管理由自我学习技术以及自动化工作流带来的日益复杂的工作环境，进而帮助开发人员更快构建起高质量产品代码。
实现云管理的技术与文化因素
在这种常用模式中，运营团队或管理大量应用程序的其他团队通常已经深刻认识到公有云的优势，且希望将其弹性、速度与性能等要素纳入运营环境。但团队可能出于历史、法规或安全等方面的考量，仍需要在本地环境中运行某些应用程序。此外，团队通常还需要面对原有裸机服务器或虚拟化环境，甚至包括一部分私有云。面对繁多的考量因素，云管理将成为至关重要的一环。
这其中关键问题在于——要如何建立一个抽象层级?一套在所有环境中都能良好运行的平台?确保运营团队能够无缝管理所有应用程序?又如何将各类基础设施隐藏起来，为开发人员提供一套统一的部署环境?这种便利性将成为提高开发者工作速度的重要前提。
从另外一个方面来看，文化因素可能让数字化转型难以起步。一位带领重要变革的银行CIO表示，除非员工们能够在心态与行为模式上真正适应这种改变，否则一切变革都只能是空谈。推动文化变革的IT领导者需要同时得到企业高层与基层团队管理者的支持。毕竟，无论愿不愿行动、如何行动，业务对于速度的追求永远不会消失。
推动业务创新
在这种模式下，企业会成立一支小团队以解决特定的业务问题，这就需要引入更多现代实践，引导员工成为变革的推动者。同时，IT团队需要快速创建、迭代并确保IT部门后续能够对解决方案进行扩展。这些团队通常会获得新的技术工具与使用权限，根据不同规则进行探索性尝试。
我们的IT人员是否具备适应新需求的技能?我们需要招聘新员工吗?我们原本的技能投资该怎么处理?……这些对技能的争论逐渐浮出水面。企业不仅需要招聘新员工，还需将内部交叉培训结合起来，由外部专家评估当前状况，并制定计划以帮助达成目标。
值得注意的是，企业不要怕失败，如果企业不愿放手让IT团队进行大胆尝试，那么人才必将开始流失。以澳大利亚麦格理银行为例，他们的CIO就希望招募人才以建立新的、极具突破性的客户体验。正是凭借着这种充分放权、尊重创造的态度，麦格理银行才成功吸引到了高质量的新鲜血液。
总结
每一段数字化转型都有其独特之处，也没有哪两条DevOps道路会一模一样。正如之前提到的四种模式一样，你不一定非要照搬其他企业或竞争对手的容器使用方式。但可以向他们学习，并参考以下几项基本思路推动容器采用：
成熟企业比云原生企业面临着更大的挑战，不少成熟企业的CIO仍然需要支持COBOL应用程序。
不要被规模问题困扰。单从规模角度来看，世界上没有几家企业能够与Facebook相提并论。但你并不需要Facebook那么庞大的资源或技能储备，也可以完成重大的业务变革，从小处入手，并在逐步获得成功后再扩展团队、引入技术。
最后，鼓励IT团队积极参与外部交流。鼓励团队成员与公司之外的同行们交互，共同探讨技术与文化层面的挑战。
