这时,Cloud Foundry 项目已经基本度过了最艰难的概念普及和用户教育阶段,吸引了包
括百度、京东、华为、IBM 等一大批国内外技术厂商,开启了以开源 PaaS 为核心构建平
台层服务能力的变革。如果你有机会问问当时的云计算从业者们,他们十有八九都会告诉
你:PaaS 的时代就要来了!
这个说法其实一点儿没错,如果不是后来一个叫 Docker 的开源项目突然冒出来的话。
事实上,当时还名叫 dotCloud 的 Docker 公司,也是这股 PaaS 热潮中的一份子。只不过
相比于 Heroku、Pivotal、Red Hat 等 PaaS 弄潮儿们,dotCloud 公司实在是太微不足道
了,而它的主打产品由于跟主流的 Cloud Foundry 社区脱节,长期以来也无人问津。眼看
就要被如火如荼的 PaaS 风潮抛弃,dotCloud 公司却做出了这样一个决定:开源自己的容
器项目 Docker。
显然,这个决定在当时根本没人在乎。
“容器”这个概念从来就不是什么新鲜的东西,也不是 Docker 公司发明的。即使在当时最
热门的 PaaS 项目 Cloud Foundry 中,容器也只是其最底层、最没人关注的那一部分。说
到这里,我正好以当时的事实标准 Cloud Foundry 为例,来解说一下 PaaS 技术。
PaaS 项目被大家接纳的一个主要原因,就是它提供了一种名叫“应用托管”的能力。 在
当时,虚拟机和云计算已经是比较普遍的技术和服务了,那时主流用户的普遍用法,就是租
一批 AWS 或者 OpenStack 的虚拟机,然后像以前管理物理服务器那样,用脚本或者手工
的方式在这些机器上部署应用。
当然,这个部署过程难免会碰到云端虚拟机和本地环境不一致的问题,所以当时的云计算服
务,比的就是谁能更好地模拟本地服务器环境,能带来更好的“上云”体验。而 PaaS 开源
项目的出现,就是当时解决这个问题的一个最佳方案。
举个例子,虚拟机创建好之后,运维人员只需要在这些机器上部署一个 Cloud Foundry 项
目,然后开发者只要执行一条命令就能把本地的应用部署到云上,这条命令就是:
文档被以下合辑收录
评论