本文来自公众号：申屠鹏会的笔记
现今，已经很少有技术从业者没听说过容器了，但放在10年前，也就是2014年前后，那时候后端技术领域可太不一样。今天，我们来聊聊容器技术的“登神长阶”。
在2014年，云计算已经是一项成熟的技术，以AWS为代表的云厂商，通过实实在在的虚拟机和账单完成了对用户的概念教育和普及。在这个时期，云计算通过对资源的抽象和整合，形成了三个层次为用户提供服务：
IaaS（Infrastructure-as-a- Service）：基础设施即服务，包含计算服务器、网络、存储等基础设施，即用户可按需获得基础计算资源。
PaaS（Platform-as-a- Service）：平台即服务，包含计算资源、操作系统、中间件、运行时、框架等服务，用户可按需获取用于开发、运行、维护和管理应用的资源。
SaaS（Software-as-a- Service）：软件即服务，包含基础设施、软件（如电子邮件、工作流、在线设计等）等，为用户提供在线使用
图片
用户使用云计算提供的各类服务基本可以归类为上述三种，比如在AWS上租用虚拟机、购买带宽资源，用脚本或手工的方式在这些机器上部署应用；而PaaS平台提供的解决方案通常包含了满足DevOps工具链的所有要求，可以满足应用的打包和发布；至于SaaS，那可选产品更多了。
在那个背景下，很明显部署过程会出现本地环境和云端环境不一致的问题，所以PaaS平台是云计算发展的重要舞台，各个技术厂商比拼的就是谁能提供更舒服的“上云”体验，谁能更好地模拟本地环境。因此以OpenStack、Cloud Foundry为代表的开源PaaS平台，通过完善的应用打包和分发机制，让用户一行命令就能把本地应用部署到云上，因此被认为是时代发展的方向。
回头看的话，如果不是Docker突然冒出来的话，现在可能还是PaaS的时代。
初出茅庐
Docker公司彼时还叫dotCLoud，是一家PaaS浪潮中微不足道、且快被拍死在岸边的一朵浪花，主打产品和主流的Cloud Foundry社区格格不入，时任创始人的Solomon Hykes为了解决其产品在PaaS业务的困境，不得已在2013年3月宣布：开源其容器项目Docker。
图片
需要说明的是，“容器”这个技术并不是Docker公司发明的，在当时也不是一个新鲜的东西。如日中天的PaaS项目Cloud Foundry核心能力也是容器，为什么后来落寞了呢？让我们回到十年前看看。
Cloud Foundry典型使用方法是这样的，用户创建好云端的虚拟机部署好Cloud Foundry后，本地应用只需要一行命令就能进行推送和安装。
cf push hello-world
它为支持的编程语言定义了一种打包格式，push则是将本地应用文件以及启动脚本压缩打包上传到云端服务器的Cloud Foundry存储库中，随后Cloud Foundry的调度组件选择合适的虚拟机下载该压缩包进行解压和启动。
图片
在这个过程中，由于一个虚拟机会启动不同的应用，Cloud Foundry会利用操作系统的Cgroups和Namespace机制为每个应用创建“沙盒”环境，相互隔离，这样起到了不同应用运行在同一个虚拟机的目的。
而当Docker发布的时候，大家无非觉得又是一个碰瓷PaaS的项目，甚至Cloud Foundry产品经理就分享过一篇“Docker vs. Cloud Foundry”的文章，从架构（Architecture）、抽象层（Abstraction Level）、应用移植性（Application Portability）、伸缩（caling）、配置管理（Configuration Management）、生态系统（Ecosystem）全方面进行了对比，得出结论：Docker无非是又一个使用Cgroups和Namespace技术的沙盒项目，实现原理大部分都一样，而Cloud Foundry提供了更高的抽象级别和更全面的平台，遥遥领先！
图片
崭露头角
相信看到这里，大家会有些困惑，既然Docker的实现原理大部分一样，那凭什么挑战在PaaS耕耘多年的Cloud Foundry，成为了时代的宠儿？
那就要从那小部分不一样的实现说起，这一部分，叫做：镜像。
历史上有太多前辈、技术公司想要解决环境不一致的问题了，前有Java “write once run everywhere”，后有Cloud Foundry的"cf-push"。PaaS当时的火热，就在于提供了应用的打包和部署功能，但偏偏这个打包是最糟用户诟病的。为了这一键部署，用户需要为每种框架、语言甚至每个应用版本维护一个打好的包，需要管理云上服务器的各项配置，才能让“可执行文件+启动脚本”的PaaS软件包成功运行，乃至有些企业出现了专业的配置管理角色。
而Docker镜像，解决的就是这个打包的问题。虽然它也是压缩包，但相比PaaS压缩包简单的内容，它包含了完整的操作系统和应用所有文件、脚本。举个例子，如果你本地开发环境使用的是CentOS8.0的操作系统，那么只需要打包时把这个操作系统和其上开发的应用压缩到一块，那么到其它地方解压，自然可以得到和当时一样的环境。
镜像——带来了宝贵的环境一致性的能力，就像三体中的二向箔，给Cloud Foundry带来了降维打击。每个用过Docker的技术人员好评连连，并加入了社区进行反馈和改进。短短发布后几个月，Docker成为了市场里的新星，特性与改进以小时为进度更新，社区Stars数量更是高达了4千。而Deis、Flynn等容器管理项目更是推出了CssS（Container-as-a-Service），与传统PaaS划清了界限。
图片
茁壮成长
由于对技术方向的误判，Cloud Foundry错失了将“沙盒”替换为Docker解决自己打包问题的机会，迅速走下了技术的舞台。
作为一个开发者，Docker开启了一个对开发者非常友好的时代。Cloud Foundry等传统PaaS项目通常服务于大企业，对于他们来说，“老板”才是服务的对象，至于开发者的牢骚，那不是问题的关键。
而Docker，不管是Logo、slogan，亦或是姿态，都是把开发者放在最高的位置（至少当时是这样）。他们深谙开发者对PaaS打包的厌恶，把简单做到了极致。不仅解决了打包和发布这一技术难题，还通过友好的封装交到了最广大的开发者手里，大家可以自由分享有趣的“镜像”，各类论坛到处充满了诸如“一分钟部署Wordpress”、“一分钟启动Mysql”等教程，促进了技术的传播。
图片
PaaS当然还在，不过此时已经变成了一套以Docker容器、镜像为核心的“容器化”思路。
但是Docker总归是一个简单的技术，Docker公司也不满足于此。
如果Docker只是一个创建和启动容器的工具，那最终只会变成某个PaaS项目的幕后英雄。Docker想走到台前。
2014年12月，Andrea Luzzardi在DockerCon上宣布推出了：Docker Swarm。它解决了单宿主机的问题，使得Docker集群可以作为一个虚拟的整体暴露给用户，Swarm最大的特点是完全使用了Docker API来管理集群，用户创建容器时，Swarm拦截请求，通过调度算法找合适的Docker Daemon运行容器。这个操作简单明了，受到了一时追捧。
图片
一直到15年，Docker走出了一个非常繁荣的生态，在容器编排（Container Orchestration)中，通过收购Fig项目，推出了Docker Compose，通过Swarm和Machine，重新定义了PaaS。
这段时间，在这个鲸鱼周围创业公司数不胜数，在容器网络、存储、监控、CI/CD、UI纷纷涌现优秀项目。
而这一年还有一件大事，那就是Google公司突然发力，正式宣告了一个叫“Kubernetes”项目的诞生。
尾声
在那个繁荣的三年时间里，Docker已经从开源产品逐渐变成一个商业项目，Docker公司终于从屠龙的勇士成为了恶龙本身。众多初期的支持者纷纷决裂，包括CoreOS、RedHat、微软、谷歌等。Docker公司强硬的态度遭致了社区越来越多的不满，终于在2015年6月，Docker、Google、CoreOS等公司共同宣布，成立RunC项目，交由中立的基金会管理。
之后各家以RunC为依据，制定了容器和镜像的标准和规范，也就是OCI（Open Container Initiative）。
很显然，故事还没结束，今日的市场格局和15年远远不同，且听下回分解。
交流问题
大家是什么时候接触云原生技术的呢？
如果你是当时（2014年）Docker的决策者，你会如何平衡容器的开源和商业化进程？
