影响：容器化已经大大改变了应用程序开发者打包和部署软件的方式。过去三年里，Docker俨然成为了容器化的主要标准。不过在容器广泛部署应用到产品应用之前，IT运维团队必须要了解容器化的简易性所带来的巨大新挑战。
你要了解的不仅仅是Docker
2015年11月，Docker公司申明Docker Hub的pull请求突破12亿，用时仅两年半，突显了Docker容器化形式的社区采用之广泛，传播速度之快。对于很多开发者和独立软件开发商(ISV)而言，Docker正在逐渐成为云原生应用(Cloud Native application)的实际描述和打包形式。
图1：从构件(Artifact)到应用(Application)再到运维(Operation)——应用程序的开发阶段(来源Wikibon)
可从开发者笔记本上拿到一个应用程序再成为一种常见的开发形式仅仅只是一个完整应用程序开发生命周期的一小部分。Docker(容器的形式)实质上是处理了构件到应用程序的阶段。但将这个应用程序放到功能性运营上还要费一段功夫，不只技术方面，还要管理开发(Dev)和运维(Ops)之间的切换。必须将以下项目从应用程序移动迁移到运维：
1.容器应进行数字签名以确保发起的有效来源。
2.容器必须进行扫描，确保它们不包含恶意软件或其它未知安全漏洞。
3.一个Container Registry(容器注册)结构必须恰当，应当对所有集中共享的服务执行安全的最佳实践。
4.容器环境必须能将服务名称和IT地址动态分配到单个容器。
5.容器环境必须有一个服务发现型服务，允许容器发布它们的可用性，并避免在容器文件内嵌入服务名称或IP地址。
6.容器环境应当能确认容器不仅是单个“主机”，而且是“集群”。集群应具备简单集成负载平衡或代理服务，避免单一故障点。
7.虽然容器不能维护本地数据，但不论是通过本地存储服务还是数据库服务，容器环境应具备提供永久存储卷的能力。
8.不论是裸机，虚拟机或者云资源，容器环境必须向运维提供管理基本计算资源的能力。
9.容器环境必须向运维提供保护及升级基本计算资源的能力，尤其侧重操作系统的更新和漏洞消除。
图2：容器技术堆栈
开发者和运维正在如何将应用程序模式化
除了这些容器环境内的运维要素，有一个新兴技术细分市场侧重如何“模式化”应用程序环境。而这经常称为“编排(Orchestration)”，与传统模式部署更新现场资源不同，这些建模技术(如Kubernetes，Apache Mesos，Apache Aurora等)侧重于描述应用程序如何在容器环境内运行的确定方式。这些建模结构定义了服务之间的交互，预期的性能和预期的可用性。其实，它们正努力在应用和运维之间创建一个协定(或者一个“服务等级承诺”)。
容器生态系统的广泛度正在提高
任何特定时间，抓拍容器生态系统都会导致这样的logo移动：
容器远景(来源：CustomerUP)
再过三个月，容器会由于收购，新初创公司沸腾以及开源社区“下水”，前景一片大好。虽然社区在尝试加快脚步，但对IT企业而言，理解哪些技术对它们业务最具意义以及哪些地方可以增值都有些困难。不同于2005-2010年的VMware生态系统，Diane Greene所言：“VMware销售的每一美元都会让出售的硬件和服务多卖8-10美元”价值观。容器生态系统始终在尝试解决如何推进有意义的营收。该行业早就看到了较小型企业从以工具为中心的产品向以解决方案为中心的产品迁移，包括Docker近期推出的数据中心。这些新的产品正在努力简化部署和容器的操作难题，并且会对自身没有以平台为中心产品的生态系统公司造成一定影响，这些公司未来也会想要集成Docker的平台。
结构化VS非结构化平台的变革
2015年末，Wikibon认为云原生应用平台市场可能被细分到结构化和非结构化平台。即便是在该报告发布的短时间内，市场也在不断演变，虽然结构化平台还是老样子，但非结构化平台则逐渐演变为更加固定同时保持一定程度的可组合性(Composable)。很多Wikibon确定的非结构化厂商已经通过创新或收购开始改变。正因如此，我们希望修正对结构化和“可组合性”平台的定义。即便仍然虑及一些平台所要求的灵活性，但“可组合性”无疑更好的反映了平台市场面向解决方案的状态。
你的运维团队是否对容器化成竹在胸
过去6个月里，许多独立的调查研究认可了容器的使用水平，容器也从根本上推动了以应用程序为中心采用公有云资源的团队。但大多CIO表示它们对容器化并不感冒。
毫无疑问，DevOps，云原生应用，微服务和容器在硅谷和初创公司里变得普遍，但距离企业公司有多远呢?近期DevOps调查数据显示DevOps正在逐渐靠拢以虚拟机为中心环境的企业，但其仍对容器知之甚少。
