这四种容器部署方式，哪种最适合你?
容器作为一种赋能技术，在企业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团队积极参与外部交换。鼓励团队成员与公司以外的同行们交互，共同探讨技术与文化层面的挑战。
