以下为原文：
近来Docker越来越火，也吸引了我这个6年虚拟化从业者的注意。笔者对Docker的技术细节并不十分熟悉，也还在学习过程中。但笔者见证了虚拟化技术兴起的全过程，参考对照虚拟化技术，笔者对Docker为什么会在当前这个时间点火起来，Docker与虚拟化的技术对比，我们该怎么办等相关问题有一些自己的理解。意见不一定正确，欢迎拍砖。
一、Docker和Kubernetes为何此时兴起
1、 尝过虚拟化的甜，想来点应用的辣
随着X86服务器，KVM等虚拟化技术，以及OpenStack等IaaS管理平台的普及和成熟，VM可以在不同X86服务器厂商的硬件平台上在线无缝迁移了。硬件差异化不断缩小甚至消失，软件的重要性不断提升，IT真正进入『软件定义数据中心』的时代。
并且人们发现，虚拟化后的IT在部署简单化，资源利用率，高可用性，维护便利性等方面收获了的巨大的收益。在这个背景下，IT部门提出了更高的要求，如何将应用在不同操作系统间实现无缝迁移，将开发和生产统一，做到『一次构建，到处运行』?并且能否让应用的部署，分发，负载均衡，高可用性，监控运维等方面也与虚拟机一样有更统一和更简单的方法呢?在这个时间点，Docker和Kubernetes出现了。
2、 受微服务理念的『蛊惑』
微服务的思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。一个微服务一般完成某个特定的功能。一些微服务还会发布API给其它微服务和应用客户端使用。运行时，一个微服务实例就可以是一个Docker容器，所以微服务天然需要Docker。
微服务带来的好处有：第一软件工程上多部门更好协作，第二软件本身的扩展性更强。下图是微服务的搜索图，而我们知道Docker正是2013，2014年开始火起来，所以说微服务是与Docker是『相得益彰』的关系。
3、 互联网公司的『摇旗呐喊』
DevOps兴起于互联网公司，基本理念是开发和运维合为一体，把开源工具拿过来，再根据自己的业务特点稍加改动，测试通过后就上线支撑公司的产品和服务，并一边运维一边改进。
在DevOps出现之前，开发的工作流程是：市场调研，需求分析，系统设计，软件编码，单元测试，集成测试，系统测试，软件发布。运维人员的工作流程是：安装服务器，安装软件，配置软件，系统运维。很明显在老的模型中，运维人员地位低下，整天做着重复且枯燥的工作，并且开发和运维之间相互等待资源环境，软件版本，以及bug list。
所以能不能运维专注于提供，维护，监控平台，提供工具。开发利用运维的工具发布，维护自己的产品或服务呢?互联网的神仙/屌丝们很快发现，Docker的『一次构建，到处运行』正是他们需要的。
4、 组织IT服务云化，平台化的『Next』
IaaS平台经过长时间的市场教育和技术教育，终于在2015，2016开始大规模的普及化和落地。政府，军工，事业单位，大中小型企业正如火如荼的进行着IT服务云化的过程。道路选择上中小型企业选择的是公有云，政府，军工，事业单位，大型企业一般都是自建私有云，像12306这种某时间段对IT有大规模溢出需求的单位，更适合的是混合云。
所有的组织都需面对客户，也都有的业务和数据。当今世界发展的趋势是：
用户体验越来越重要(产品过度泛滥+烧钱的大有人在+别人都在『取悦』用户) ;
业务更替越来越频繁(N个试错-->1个OK-->继续N个试错);
数据就是资产(不解释)。
所以呢，未来，IT服务需要更轻量(100~1000容器/Node)，更高效(无GuestOS开销)，更敏捷(devop理念)的平台。当前，考虑原有业务迁移的便利性，笔者认为以虚拟化为核心的云平台更胜任。
二、请输Docker与虚拟化的对比
1、 浅层技术对比
对Docker稍有接触的人应该都见过下图，无需更多解释，Dokcer减少Guest OS这一层级，所以更轻量和更高性能。
2、 深层技术对比
但用户很少直接使用Docker，而是要使用Docker为核心的平台系统，那其实对比项还是蛮多的。
从上表可以看出：
容器更高效，更敏捷，更好维护;
虚拟化在安全性和支持广泛性上有天然优势;
管理平台成熟度上，Docker和kubernetes还有很长的路要走。
3、 适用场景不同
对于高I/O要求的业务，例如数据库服务，建议部署Docker+物理机，因为在虚拟机中部署Docker，I/O性能将受到虚拟机的限制。对于虚拟桌面服务等强调租户权限和安全的业务，建议采用虚拟机方式，虚拟机的多租户强隔离特性，保证租户在拥有虚机root权限的同时，其他租户和主机的安全。
此外，大部分业务系统将适用于虚拟机+Docker形式的组合，操作系统和Docker引擎采用虚拟机镜像封装，平台软件、业务组件等与业务相关软件采用容器镜像封装，为实现安全隔离和资源的高利用率，基本应该遵循：不同租户的业务运行采用虚拟机隔离，相似类型的业务部署在同一组容器上的思路。
三、我们该怎么办?
首先介绍下笔者公司产品的情况，2011年开始我们以KVM为基础自主开发了OPV-Suite平台(IaaS云平台)和OPV-VDI(桌面虚拟化)产品，主要面向私有云客户，也向公有云服务商供应产品和技术。面对Docker的挑战，我们在确定还需在虚拟化产品继续深耕下去的同时，还该怎么办呢?
1、 未来云产业格局分布
盗一张我的领导对云产业玩家的分析图。明显看出云产业链里的价值高地正在往云服务商处聚集，当然这个服务可以是公有云服务，也可以是私有云服务，还可以是混合云服务。
笔者一直认为，云消费者并不关心，你这个服务商使用的是虚拟化技术还是Docker，更不关心你自己写的还是基于开源平台改的。他关心的是你的服务是否可靠，是否稳定，是否便宜，是否安全。所以，根据你团队的特点，选择你们自己最擅长的技术，为云消费者提供有竞争力的服务，才是未来我们能否立足的核心。
2、 技术上先看看别家怎么做
用户不关心技术，我们关心呀。首先声明，下表的分析数据是从2016容器大会上各厂商PPT上了解到的，必然既不全面也不深刻。
单从数量上看势均力敌。为什么会这样，笔者认为第一Docker还在迅速发展过程中，到底怎么做大家还没有统一的意见。第二各个互联网公司的技术团队擅长的东西并不一样。
3、 我们怎么办?
好，该得出结论了，我们该怎么办呢?
提供用户需要的云计算产品和服务，适合虚拟化的就虚拟化，适合Docker的就用Docker，并以自己团队最擅长的方式构建出平台来。
4、 DCOS应该是怎样的?
笔者认为融合了虚拟化和容器的平台，我们暂且叫它DCOS(数据中心操作系统)的体系结构应该是这样的，篇幅有限，笔者将在第二篇文章中详细介绍各模块的功能和实现方法。
