云计算，从何而来，正向哪里而去

云计算平台在2008年出现在公众面前的时候，我和大多数人一样，并没有意识到这是一场影响深远的技术变革。并不是缺乏洞见，而是因为云计算的概念非常混乱。

当时，作为倡导云计算的两大巨头——Amazon和Google，分别拿出了EC2（2010 Jan Radar）和GAE(Google App Engine 2010 August Radar)。今天我们自然可以很清楚地知道，这两个产品分别对应IaaS和PaaS两类云计算模型。但是在2008年，它们则是两大巨头分别指定的唯一“云计算”平台。它们都倡导让计算像水电一样成为基础资源并能够随时低成本地获取。显然，对于计算能力，两者的定义是不同的。

EC2对于能力的定义偏向于裸能力——也就是硬件能力，而GAE的定义则偏向于在“某个特定场景下的特定计算”。最终“特定场景下的计算”又分成了PaaS和SaaS。于是云计算的三种计算模型IaaS、PaaS和SaaS才成为广为人知的概念。

那么这三种计算模型是否在一开始就凸显了革命性呢？当然不是。IaaS无论从概念到使用场景，都极度类似IDC服务器托管；GAE作为web框架先天畸形，完全不同于当时主流的编程模型，让人不得不怀疑为了获得“云计算”的好处是否真的值得；而SaaS到云计算兴起的时候，大概已经存在快10年了。

作为一名务实的技术人员，我个人在当时认为所谓云计算又是一种无聊的商业包装，还是拼凑感特别强烈的包装。我是逐渐才意识到了云计算的革命性以及它对软件行业的深远影响，而云计算平台本身也在过去的十年中逐步发展，成为了我们这个行业事实上的标准。

下面我们来简单地回顾一下云计算在过去十年中的关键技术点以及它们带来的影响。

虚拟化与IaC

在EC2推出之前，使用镜像维护物理机器已流行了相当长的时间。然而这种方式并没有对研发带来什么特别的影响，毕竟镜像仍然需要通过复制才能转移到物理机器上。这一过程仍然相当费时费力。

(镜像与物理机)

虚拟化技术可以通过机器镜像直接启动虚拟机，这使得通过镜像管理虚拟机和直接管理虚拟机没什么本质区别了。EC2更加强化了这一实践，而作为远程服务的EC2为其虚拟机管理和镜像管理提供了充分而有效的API。从而使得机器的分配、启用、停止、镜像加载都可以通过脚本自动化完成。

(AWS EC2)

至此，信息技术行业的一大革命就这么静悄悄地完成了。

首先，硬件被抽象化为一种计算能力的描述：什么计算力的CPU、多少个内核、多少内存。而至于具体的硬件规格已经不再重要。将硬件抽象为标准化的计算能力这是一大进步。

一旦我们摆脱了对于具体硬件规格的讨论，转而描述计算能力，硬件就好像被软件定义了一样。比如在EC2平台上，只要围绕着它的API和AMI镜像编写自动化脚本，就能在云端“无中生有”地产生一个符合预期的硬件。

这种方法极大地改变了硬件采购的流程，从对于某个特定型号的硬件的采购，转化为了对于某种计算能力的要求。

其次，被软件定义了的硬件可以当作软件一样地进行管理。软件这个概念从诞生之日起，就是和硬件对立的存在。硬件相对固定，更新改进和维护都需要相当长的响应时间；而软件则被认为可以较容易地演化和改进。

围绕着软件配置管理（scm）、工作区、构建流水线、持续集成、持续交付等概念。软件建立起了高效且自动化的变革管理流程。但是硬件却仍然需要依赖人工操作，相对同期的软件变革管理，易错且低效。

同样是从EC2p开始，虚拟机的启动脚本、镜像的生成过程都可以通过脚本自动化。于是所有适用于软件的变化管理实践也同样可以用于被虚拟化的硬件了。

（流水线与云平台）

这便是我们今日所说的基础设施即代码（IaC）。IaC无疑是巨大的变革，不仅仅从技术上，更是从观念上对于我们如何认识软件研发有了根本性的冲击，并带领了其后的软件定义网络（SDN）、软件定义存储（SDS）直至软件定义一切（SDE）。

弹性与运维革命

云平台声称的另一个好处是计算弹性。云平台厂商通常都会将计算弹性解释为根据业务需要动态调整计算资源的能力。比如业务的旺季需要一万台机器并不意味着在淡季也需要维持这种计算容量。

（