大约每隔10年左右，整个数据中心业界就会开始关注下一个大的抽象化概念，这一新的抽象化概念将激发出令人振奋的新服务器操作系统的形式因素。正如Redmonk公司的分析师Stephen O'Grady在他的一篇题为《抽象之路( The Road to Abstraction)》的博文中所说的那样：“计算机是很难的，这就是为什么说整个技术行业历史上的长期趋势之一便是抽象化并不奇怪的原因所在了。“
有了容器集装箱技术，数据中心业界的一个普遍的共识就是：最新的抽象单位正式到来，并将要开始取代虚拟机了。企业开发人员们现在更喜欢采用容器来打包应用程序(根据市场调研机构451 Research公司的报告显示，到2020年，这一市场规模将达到27亿美元)。而这对于数据中心运营商们需要如何支持这些应用程序及开发人员的创建工作将具有深远的影响。但是，与虚拟化技术的最后一个主要抽象转换相比，今天整个业界对于容器集装箱技术的采用曲线其实存在着很大的差异。
下面，让我们大家一起来看看当下广泛采用的容器集装箱技术对数据中心运营商们所带来的影响吧，同时，我们还将探讨我们当前在该技术方面处于怎样的水平，以及我们从以前的朝着虚拟化技术转向的趋势中所学到的经验教训。
为什么开发人员们开始青睐容器集装箱技术?
容器集装箱技术的普及采用可以说是开发人员们朝着数据中心运营商们发起的“反叛起义”。而影子IT则是这次“反叛起义”的第一次迭代，由于此前需要花费几周的时间才能在企业内部配置好虚拟机，迫使开发人员们直接转向采用亚马逊网络服务(AWS)，并直接使用信用卡支付来获取服务器资源。
现在，容器集装箱技术允许开发人员们实现更快地迁移。因为即使在AWS上，采用一台虚拟机也需要几分钟的时间，而容器集装箱则仅仅只需要几毫秒的时间。随着企业组织越来越倾向于优先考虑更快地发布新产品和功能，以便能够跟上当下这个软件消费的世界的大趋势，开发人员倾向于采用那些允许他们能够比公共云和私有云服务可支持的传统虚拟机更快地扩展应用程序和部署资源的技术。而诸如Twitter和Netflix以及其他规模化网络公司(其应用程序和平台团队具有基础设施自主权)的开发人员模式，已经开始将容器集装箱技术作为提升灵活敏捷方法的最佳实践方案(将能够帮助任何开发团队真正实现“快速的迁移”)，并将其纳入主流了。
更进一步分析，我们可以看到：较之虚拟机，容器集装箱技术具有各种成本和性能优势，这有助于解释该技术在当下流行的原因所在了。其第一个主要的益处便是：能够在同一台服务器上运行多款应用程序或操作系统，无需虚拟机管理程序，进而消除了系统资源管理程序的阻力，所以您企业的工作负载可以有一个较轻的足迹——容器足迹为零，因为其在Linux系统中只是一个边界的权限和资源。
与虚拟机相比，容器集装箱的启动和关闭非常快速——完美契合企业组织当下短暂的工作负载的短暂性质，因为这些工作往往是现实世界中的事件，并和“突发性”相关联。最后但并非最不重要的是，鉴于具备更多的灵活性，可以在不同的云服务供应商和操作系统上部署应用程序，使得容器集装箱对于操作系统的依赖关系越来越少，进而起到了使得这些应用程序避免被企业组织的目标锁定的的作用。当然，还没有VMware软件许可证费用。毕竟，这一软件许可证费用对于任何主要数据中心而言，都会大大增加其运营费用成本。
但是，这一优势并未像虚拟机那样发挥出来
容器集装箱规则的特征之一是没有规则。一大现实案例便是Docker容器模式已经在市场上赢了。但随之而来的技术选择和丰富的快速开源平台比比皆是。您企业可以使用任何您所希望的Linux模式。您可以选择快速发展的容器orchestration业务流程平台，如Kubernetes、Mesosphere DC / OS和Docker Swarm。
即使是在当下的容器集装箱模式级别(假定Docker已经赢得了市场)，现在也面临一种更开放的标准容器模式的挑战。因此，数据中心运营商们会很快发现自己陷入了更深层次的问题，这些问题很多是尚未标准化的问题：包括配置容器存储和网络化，以及对运行中的容器的洞察，这些问题与运营商们曾希望借助虚拟机技术的采用所达到的成熟度相当。
其真正的原因可以归结为企业现在实施容器集装箱的能力还相当不均匀，包括系统成熟度方面的，也有用户意识方面的原因。
容器集装箱的世界没有VMware。基本上，Docker是最接近通用品牌的容器集装箱了，但Docker远不及VMware在虚拟机发展的早期所具备的技术锁定。一方面，容器集装箱技术的早期采用者们有很多的选择和灵活性，但也意味着它们必须是自己的系统集成商，并将许多这些工具集成在一起。
从1997年至2002年期间，VMware大概花费了五年的时间围绕着虚拟机技术创造了一个市场。在这五年的时间里，他们可以说是这一市场唯一的玩家，并有一段时间，通过打造像VMotion技术，VRS资源平衡等等方式来建立起了企业级的护栏，来进一步封闭了该技术。
而在另一方面，Docker几乎立即开源了其围绕着容器集装箱的核心技术。红帽、Canonical、Mirantis以及几乎每家主要的开源供应商都在商业上得到支持。所以尽管Docker是第一个推动者，但是他们失去了控制权。许多人会认为，他们花了太长时间来强调orchestration业务流程，这就是为什么他们在Swarm采用大潮流中远远落在了Kubernetes和Mesosphere DC / OS之后的原因所在了，尽管他们原本在容器模式方面拥有巨大的先发优势。
今天的容器集装箱产品生态系统是数十年来我们在数据中心领域所看到的最大的地雷之一，无数供应厂商争相拥有现代应用程序“堆栈”的各个部分。但随着可选择的开放源代码平台的大量开发，数据中心运营商也面临着挑战，需要选择合适的技术，并实现高度定制化的整合。如果您企业是像Netflix，Ebay或PayPal这样的网络规模化巨头，并且具备足够的工程师，那么采用容器的经济性是有道理的。但对于需要可预测结果的市场上的其余企业而言，这可能相当危险。
今天，我们在容器集装箱技术的采用确切的处于什么水平?
SHOW FULLSCREEN
资料来源： Google Trends
没有人会对容器集装箱的重要性提出异议。在过去三年中，Docker本身登上头条新闻的次数已经呈直线上升趋势，而Kubernetes也正在开始引发业界的广泛兴趣逐渐达到临界，由上图中的Google Trends即可看出。
但企业在实际生产过程中对于容器集装箱的采用究竟在何处呢?虽然我相信容器集装箱所带来的正面积极效应是如此令人兴奋，企业将持续推动，直到该技术的采用变得无所不在，但我听到和看到的是，集装箱技术通常仍然停留在第一档，其受欢迎程度仍更多地局限于开发人员的笔记本电脑，而几乎没有用于主流企业生产部署的用例。
今天的容器集装箱技术：好的方面
从我的观点看来，今天的容器集装箱对于企业的吸引力主要包括：
面向消费者的服务转移到容器集装箱化的DevOps工作流程(更广泛的生产实例包括Viacom、Bloomberg和Ticketmaster等大品牌)。
借助状态应用程序和数据库进行实时分析(Verizon、Google、Apple和Uber便是其中记录其案例研究中的大品牌企业)。
容器集装箱可实现从微服务到数据库的端到端自动化DevOps。
今天的容器集装箱技术：坏的方面
在这一技术朝着主流方向推动的过程中，我认为也有两大主要障碍继续存在：
容器集装箱自身不稳定的技术基础：太多的业务流程、网络、存储、安全选项。无限排列。对于大多数典型的企业(并非所有企业全都是Google或Facebook这样的网络规模化的企业)都不能支持。今天的容器集装箱技术，将需要在这个问题上消耗大量的人力物力，需要更多的工具和支持才能取得成功。
数据库和分析引擎：容器集装箱系统一直在努力满足持久存储的需求，自动扩展以跟上微服务，性能和延迟，以满足业务的预期。在这个方面上大量的投钱是典型的答案，这导致了过度配置的问题。
虽然您可以使用容器集装箱技术，并在虚拟机上运行，以利用现有的基础设施，但我们所看到的是，今天的终端用户(在没有成熟的容器特定生产工具的情况下)正在经历这两个世界的最差体验——容器技术工具的复杂性和虚拟机的大开销。尝试这样做的企业通常会以如下两种方式之一：
简单模型：每台虚拟机一个容器
易于开始。每个容器都安装单一的网络和存储(VM!)。现有的工具在某一点上起作用。
但是，在经历了短暂的时间后，却会变得非常痛苦和昂贵。虚拟机蔓延。高度浪费/间接费用开销庞大。存储和网络管理是依赖于管理程序的旧的/慢的/昂贵的模型。这种方法在开发环境与操作环境之间造成了重大的脱节。
高级模型：每台虚拟机多个容器
创建了直接暴露于容器的不同的网络/存储模型。虚拟机的抽象无法解决这些问题。
最有可能的是，您企业将传统IT模型的新容器堆栈分层，而这正是开发人员将其迁往公共云服务的重点原因。
数据中心运营商的结论
在本周的CoreOS Fest上，Ticketmaster平台的高级副总裁分享了他们早期主要的容器集装箱生产用户常见的问题，当时他说：“我们实际上并不想再建立更多的软件，那些是我们不需要维护的东西，我们写的每一块软件都应该是商品，这是我们永远拥有的技术债务。“
容器的早期路径是DIY，极端定制和技术债务之一。对于太多看到容器上升态势太快，而不能再观望的企业组织而言，我想提供一些关键性的建议来降低风险：
1、为您的客户(开发人员)提供他们所需要的：容器本机，整个应用程序的自动化体验，可轻松扩展和管理。
2、选择开源方法，减少锁定并提供多种支持选项。目前，开放性最好的“堆栈”组件包括Kubernetes，用于Linux的开放API(网络、存储，以便您企业可以在不同的云基础设施上部署应用程序)、CNI和Flex Volume。
不要等待解决方案成熟，届时就太迟了。Dev开发将在公共云端，而ops运维将成为新的大型机，逐渐萎缩。使用开放API构建适度的容器集群并不需要大量投资，这对大多数企业组织来说都是正确的起点。
