是时代选择了 Docker？还是 Docker 选择了时代？
本文是云原生系列的第二篇文章，主题是回顾容器的发展史。
在 PaaS 林立的时代，为什么开发者最终选择了 Docker？Docker 又是以怎样姿态给与了 PaaS 世界“降维打击”，直接宣告了 PaaS 时代的结束呢？
云计算简介（可以跳过）
后续回顾中会涉及到云计算的发展，故而先对云计算的相关模型知识略作解释，如果本身对这些知识已经了解的，建议直接进入 下一部分。
美国国家标准和技术研究院 2011 提出的的云计算定义中明确了云计算的模型。该云模型由五个基本特征、三种服务模式和四种部署模型组成。
五个基本特征
随需应变自助服务：
可以向消费者单方面提供计算能力，例如服务器算力和网络存储，根据需要自动组合，无需消费者人工与每个服务提供商互动。
随时随地用任何网络设备访问：
可经由异构瘦客户端或胖客户例如，手机、平板电脑、笔记本电脑和工作站）端通过网络使用标准方式访问的机制。
多人共享资源池：
提供者的计算资源池以多租户模型为多个消费者服务，根据消费者需求分配和重新分配动态地使用不同的物理和虚拟资源。资源需要有位置感独立性，客户虽然无法控制或了解确切的所提供资源的位置，但能够在更高级别指定位置抽象（例如国家、省或数据中心）。资源的包括存储、处理、内存和网络带宽等。
快速弹性灵活部署：
在某些情况下，可以自动地弹性配置和释放，根据需求快速向外和向内扩展。通常要给消费者提供近乎是无限的可以随时以任何数量配置的资源。
可被监控与量测的服务：
云系统通过利用自动控制和优化资源为消费者提供某种抽象级别的计量能力。 其中的资源使用可以监控、控制和报告。
除NIST的规范外，一般认为还有如下特征：
- 基于虚拟化技术快速部署资源或获得服务。
- 减少用户终端的处理负担。
- 降低用户对于IT专业知识的依赖。
三种服务模式
软件即服务（SaaS）：
消费者使用应用程序，但并不掌控操作系统、硬件或运作的网络基础架构。是一种服务观念的基础，软件服务供应商，以租赁的概念提供客户服务，而非购买，比较常见的模式是提供一组账号密码。例如：Adobe Creative Cloud，Microsoft CRM与Salesforce.com。
平台即服务（PaaS）：
消费者使用主机操作应用程序。消费者掌控运作应用程序的环境（也拥有主机部分掌控权），但并不掌控操作系统、硬件或运作的网络基础架构。平台通常是应用程序基础架构。例如：Google App Engine。
基础设施即服务（IaaS）：
消费者使用“基础计算资源”，如处理能力、存储空间、网络组件或中间件。消费者能掌控操作系统、存储空间、已部署的应用程序及网络组件（如防火墙、负载平衡器等），但并不掌控云基础架构。例如：Amazon AWS、Rackspace。
四种部署模型
公有云（Public Cloud）：
简而言之，公用云服务可透过网络及第三方服务供应者，开放给客户使用，“公用”一词并不一定代表“免费”，但也可能代表免费或相当廉价，公用云并不表示用户资料可供任何人查看，公用云供应者通常会对用户实施使用访问控制机制，公用云作为解决方案，既有弹性，又具备成本效益。
私有云（Private Cloud）：
私有云具备许多公用云环境的优点，例如弹性、适合提供服务，两者差别在于私有云服务中，资料与程序皆在组织内管理，且与公用云服务不同，不会受到网络带宽、安全疑虑、法规限制影响；此外，私有云服务让供应者及用户更能掌控云基础架构、改善安全与弹性，因为用户与网络都受到特殊限制。
社群云（Community Cloud）：
社群云由众多利益相仿的组织掌控及使用，例如特定安全要求、共同宗旨等。社群成员共同使用云资料及应用程序。
混合云（Hybrid Cloud）：
混合云结合公用云及私有云，这个模式中，用户通常将非企业关键信息外包，并在公用云上处理，但同时掌控企业关键服务及资料。
历史选择了Docker
2000-2010：云计算伊始，群雄并起
2000 年到 2010 年这十年里，除了语言们本身的迭代与竞争外，后端领域最主要的新玩意，就是在这一时期逐渐兴起的云计算了。
各大互联网公司或是自身架构过渡到大规模分布式系统之后，意识到研发成果可以为公众所用，或者是弹性计算设计中，有大量的冗余服务器白白浪费资源，或者是对先行者的模仿，总之这一时期，各个厂商开始推出以 IaaS 服务模式为主的云计算服务，涌现的主要玩家包括 ：
- 【AWS】Amazon Web Services（2002）
- 【GCP】Google Cloud Platform（2008）
- 【Azure】Microsoft Azure（2008）
- 【Aliyun】Alibaba Cloud（2009）
- 【OpenStack】OpenStack（2010）
2011-2013：逐鹿中原
云计算给开发者的兴奋渐渐消退，或许是期待太高，云计算的形象从原来的高大上逐渐幻灭，最终抓住的只是实实在在的虚拟机和长长的账单。而这时各家云计算平台的竞争也已经逐渐明朗，如日中天的 AWS 、盛极一时的 OpenStack、紧追不放的 Azure、GCP，还有大吃中国这一时期互联网合规性政策红利的 Aliyun。
与此同时，以 Cloud Foundry 为代表的项目，开始尝试探索 PaaS 服务模式方向。
2013-2014：Docker！
2013 年是云计算发展较为关键的一个年头， Cloud Foundry 已经完成了最艰难的普及阶段，吸引了包裹IBM，华为、百度、京东等一大批顶尖技术厂商，以开源 PaaS 为核心构建平台层服务能力的思维已经得到了普遍接受，这一时期的云计算从业者仿佛渡过长夜看到曙光的疲惫旅人，PaaS 时代即将降临已经成为了大家的共识。
然而，互联网世界从来不缺少的就是变革者，几乎被钦定的 Cloud Foundry 没能携着大家的期待将 PaaS 的辉煌普照开来，当然某种意义上，大家的共识也没有错，PaaS 时代的确要来了，就在这一年，我们的真正主角，名为 Docker 的开源项目诞生了。
在 Red Hat、Pivotal 这些 PaaS 弄潮儿们推崇着以 Cloud Foundry 社区为主的主流方案的同时，PaaS 热潮中一个名不见经传的小公司 dotCloud 艰难维护着自己主打产品。因为该产品跟主流的 Cloud Foundry 社区脱节，长期以来无人问津，眼看就要被 PaaS 风潮抛弃的时候，2013年3月13日 dotCloud 公司做出了这样一个决定：开源自己的容器项目 Docker，当然，这件事在当时根本没人在乎，但命运就是这样有趣，PaaS 发展的拐点就这样近乎悄无声息的发生了。
其实粗粗看来，Docker 跟这一时期的其他 PaaS 产品如 Cloud Foundry 相比，并没有什么明显的不同，使用 Cgroups 和 Namespace 实现的原理几乎一样的沙盒，在它发布后不久，Cloud Foundry 的首席产品经理 James Bayer 就在社区里做了一次详细对比，结论是没有什么特别的黑科技，也不需要特别关注。
James Bayer 的分析确实没有错，Docker 大部分功能和底层原理都和 Cloud Foundry 一致，但是他也没能预料到，就是这一小部分不一样的，甚至没能被他正视的功能，让 Docker 在接下来的短短几个月迅速崛起，以近乎三体中“降维打击”的姿态，将包含 Cloud Foundry 在内的一众 PaaS 社区横扫出局。
这个功能，就是看似不起眼的 Docker 镜像。
Docker 镜像解决了一个当时所有其他 PaaS 方案都没有解决的问题：保证环境的高度一致。
以 Cloud Foundry 为例，当时的其他 PaaS 方案踩坑成本极大，虽然一样有打包和部署的逻辑，但是必须为每种语言、每种框架，甚至每个版本的应用维护一个打好的包，经常遇到的情况是，明明在本地运行得好好的应用，推送到 PaaS 却不能正常运行，而是需要做大量缺少章法的修改和配置，在不断试错之后才能搞定。
而 Docker 镜像其实就是将整个系统的关键文件都作为基础环境打包，因此使用 Docker 镜像让用户完全不需要环境的试错成本，原本作为 PaaS 系统中最核心的打包系统被彻底抛弃。
而这正是 Docker 镜像的精妙之处，或许连作者 Solomon Hykes 都没有意识到，这个小小的创新不止给 Docker 带来了碾压级的实力，还推动整个云计算领域迅速的走上了快车道。
对于开发者们来说，在终于体验到了 Docker 镜像丝滑般的流畅感之后，自然而然的用脚投票，直接宣告了 PaaS 争霸时代的结束。
不过，Docker 项目固然解决了应用打包的难题，但是它并不具有 PaaS 大规模部署应用的能力，Docker 集群管理的需求迫在眉睫，而这时的过气王者如果能够使用 Docker 替换掉自己原有的打包模块，完全有机会再次卷土重来，但是因为 Docker 的一些商业上的潜在问题以及错误的判断的 Docker 的发展势头，错过了这个窗口期，反而是一些嗅觉敏锐的创业公司瞅准了机会，推出了如 Deis 和 Flynn 等的 Docker 容器集群管理的开源项目，这一类工具有了一个新的名称， CaaS，即 Container-as-a-Service。
2013年底，dotCloud 宣布将公司直接改名为 Docker。
2014年底，Docker 公司发布了自家的 CaaS —— “原生容器集群管理项目：Swarm”，雄心勃勃的准备实现自己重新定义 PaaS 的宏愿，这无疑是 Docker 的高光时刻，梦想似乎触手可及，想来当时的 Docker 员工和我写稿的现在一样，一定是激情澎湃，指点江山。
可惜作为未来人我们清楚地知道，属于 Docker 的奇迹并没有延续，未来属于 Kubernetes，至于这段故事，欢迎关注公众号“云原生之光”或者我的博客，未来我会慢慢讲给大家听。
为什么是 Docker？
讲到最后，我们来总结点题，“为什么是 Docker？”。
答案显而易见，正是因为 Docker 出现的这个时间点，PaaS 在普及和落地的同时，也让“打包”问题成了大家共同的困扰，而 Docker 创造性的设计了 Docker 镜像机制，降维打击般的破解了困局，近乎完美的解决了“打包”问题。Docker 镜像在技术上其实不难，但要想出这个方法，却是一个从0到1的突破，或许是误打误撞，也或许是真正洞察了 PaaS 的命门，这个创举正是 Docker 横扫云计算完成大一统的原因。
