本节书摘来自华章出版社《PaaS程序设计》一书中的第1章，第1.3节，作者 Lucas Carlson，更多章节内容可以访问云栖社区“华章计算机”公众号查看
1.3 云：发展历程简介
什么是云？这个外来术语被过度使用。
Dropbox就是所谓的云么？或者是iPhone？还是Gmail？
对某些人来说，这些林林总总的例子也许就是所谓的云，但对开发者而言不是。
对开发者来说，云是相互关联的一组基础技术，借助这些技术可以采用新的方法来构建和运行新的技术。如果用户不能在基础技术上开发新技术，那就不是云。
很多应用和SaaS都是基于基础云技术构建的。Dropbox和Gmail就是建立在基础云技术上的SaaS应用。但它们本身不是云技术。
20世纪90年代数据中心开始增长。第三方公司将服务器集中安置在房间中，然后出租。相比之前公司需要自己购买服务器建设数据中心，这会便宜很多。
随着集中式数据服务器的增长出现了虚拟化技术，这标志着进入云时代的第一步。应用虚拟化，数据中心可以将大量服务器组合然后划分成小型（虚拟化的）服务器。早期涉足虚拟化的公司中，Vmware和微软公司开发的软件对虚拟化的发展至关重要。
1.3.1 API引入
在2006年，继虚拟化之后云的进一步发展是：应用编程接口（API）。API增加了一层复杂的自动化层，这样用户可以通过简单、实时的命令控制、启动、停止以及创建新的虚拟机。继亚马逊公司首创推出了亚马逊Web服务之后，API为基础设施即服务的出现铺平了道路，它的很多规范是我们现在公认的云标准的前身。
云发展到此时，批量创建大量虚拟机已经是轻而易举的事，但如何管理是个头疼的问题。用户身边触手可及的大量服务器该如何管理呢？DevOps粉墨登场啦。
1.3.2 DevOps出现
2010年前后DevOps成为主流。它源自于开发者更快完成工作的需求。开发者厌倦了代码部署运维时的等待，没有工具去进行服务管理，手工完成所有工作。为了摆脱这些困境，程序员们转向云技术，并成为DevOps的鼻祖。他们构建系统来管理和维护基础设施，并且用程序来完成与服务的交互。
DevOps推出Chef和Puppet这类重要的工具，可用于管理几千台服务器、升级代码、更新代码、更新服务、部署新的服务器实例、修改配置，而这些工作对开发者来说是极其繁琐和困难的。于是，DevOps的自动化工具，例如RightScale和ScaleXtreme，也开始兴起。
在所有云工具中，DevOps为开发者提供了最好的控制管理。代价是用户仍需要花时间去构建和管理系统。如果事情不顺利，仍然由开发者负责处理。所以，DevOps并不是开发者的最终方案。这就是原因。
作为开发者，可能需要花时间编写基于Chef和Puppet的代码，但是最终的目标可能是尽量从系统运维中解脱出来。如果是这样，现在的平台即服务可以解决系统管理问题，给开发者节省更多时间。有了PaaS，我们不需要编写Chef指南或者Puppet脚本去管理服务器，可以将更多的时间放在编写与用户交互的编码上。
DevOps一直是应用程序生命周期管理工具的基础技术，我们后面会花点时间探讨一下。应用程序生命周期管理离不开DevOps，因此DevOps不会消失。DevOps属于核心基础技术，在云领域中更是不可或缺的。
DevOps工具也是PaaS如何后台运行的重要组成部分。例如Heroku、EngineYard、AppEngine以及AppFog等平台，DevOps工具都是后台运行的核心组成部分。
1.3.3 应用程序生命周期管理的诞生
由于有了DevOps，人们可以轻松管理上千台机器，但它仍然与硬件设备紧密相关。相比于具体细节（例如，虚拟机上安装什么版本的libxml）应用程序更关心服务（例如，MySQL和MongoDB）。DevOps，甚至IaaS，都没有实现服务和应用管理。下一层次的云技术是应用程序生命周期管理。
应用程序生命周期管理工具技术以Cloud Foundry、 Open-Shift以及 Cloudify等为代表。它们还不是真正的PaaS（尽管有时他们自己宣称是），因为它们仍然需要操作员来人工操作（并未将操作员从实际操作之苦中解脱出来）。但是，它们为PaaS技术奠定了基础。这些工具知道怎么启动、停止和部署应用。它们也知道如何运行和管理诸如MySQL之类的服务。
应用程序生命周期管理工具全面接管应用，支持跨服务器管理应用，因此，应用可以运行在上百甚至上千台服务器上。一般来讲，IaaS和DevOps工具对分布数百台服务器上的应用——需求、资源以及服务，考虑欠佳。应用程序生命周期管理了解应用，为它们提供服务，知道如何管理、扩展以及维护它们 。
很多情况下，我们可以在笔记本电脑上运行应用程序生命周期管理工具。Cloud Foundry的微VM就是很好的证明。OpenShift和Cloudify也有类似的工具。应用程序生命周期管理进一步产品化的任务艰巨，即使很小的产品安装也需要5～10个人的团队，管理几十或者几百台机器。
应用程序生命周期管理能带来很多好处。例如，一个文档管理网站可能整夜遭遇严重的网络堵塞。我们需要依次处理好1000多台服务器上众多的新用户。
在应用程序生命周期管理概念出来之前，我们需要安排一个团队人为处理好几百台新服务器的增加工作。我们需要部署好代码。这些工作都需要人工干预以及人力资源协调。
即便采用DevOps，这也是一项艰巨的工作。我们如何确定Puppet自动创建的服务器运行正确呢？我们如何维护这些服务器呢？我们如何实时监控应用加载对各个服务器的影响呢？这些正是DevOps工具的缺点。
Cloud Foundry之类的应用程序生命周期管理工具改变这一切。只需要告诉Cloud Foundry你的应用需要1000以上的实例，它就会自己完成所有工作。这就使得跨服务器的应用更新升级变得无比简单。
但问题仍然是有的。我们仍然需要有人监控应用程序生命周期管理软件，还是没能完全摆脱人工操作。我们只是将注意力从一个应用换到生命周期软件的运行情况上。
在我们的样例中，在有应用程序生命周期管理工具之前，当需要增加服务器时，开发团队需要和实际操作团队密切合作才能保证升级成功。有时候必须是原始团队，甚至是原来的人员或者两者都要满足，只是角色分开。操作人员需要手工完成所有服务器的联调工作。
现在，应用程序生命周期管理工具能帮我们完成所有的工作。它了解应用，知道怎么执行代码，知道怎么添加服务器和实例。但是应用程序生命周期管理工具自己需要操作者。我们需要运行这个工具。区别在于它是一个抽象的工具，我们可以装载任何应用或者其他东西。作为一个开发者，不管运行这个工具的操作人员是跟你同处一室坐在你旁边，还是在几百米之外的地方，例如波特兰、俄勒冈州，都没有关系。
于是我们进入了NoOps和平台即服务领域。
1.3.4 新一代云——平台即服务
云使得我们再也不会陷入巨大开支，不再需要购买服务器、系统以及涉及的人工费用。
以往，创业者们都有着相似的经历。我们需要雇用一些有资质的员工，花百万美元在数据中心以及管理等事情上。
和基础设施即服务一样，云的核心理念以及最大好处就是减少购买数据中心的投入。我们不再需要购买数据中心，但仍然需要操作人员管理我们租用的服务器。
NoOps方案则完全不需要操作人员与开发人员的密切协作了。操作需求也能满足，但完全与每个独立应用无关了。NoOps方案主张将运维工作外包，让开发者更快地完成任务。开发者不需要等另一个团队来部署他们的代码，而是由系统自动衔接完成这些工作。
NoOps方案也是有争议的，因为有人会将它读成“没有，运维”，暗示运维会越来越无所谓。恰恰相反，运维现在越来越重要。NoOps的真正目的也是让开发者更重视运维，但我们不再需要直接完成应用程序维护工作。就像NoSQL并不是指SQL不再重要，而是会有另一种方式实现数据存储和恢复，而开发者不再需要直接与SQL交互。
平台即服务外包了运维工作。这并不是不要运维工作，而是从开发工作中分离出来，这样开发者的工作越来越简单，效率越来越高。
平台即服务管理的原始迭代包括Force.com（http://force.com）和Google应用引擎（Google App Engine，GAE），很受限制。他们要求必须基于他们的API进行开发，这样他们只需要按他们的语法工作。他们的平台即服务的特点就是跟他们的系统捆绑密切。他们承诺用户可以获取特别数据，充分利用他们平台的特长，例如自动扩展，完成这类比较困难的工作。
早期的PaaS有两个缺点。第一是我们需要学习一整套API接口，这就有一个学习适应的过程。第二个缺点是可移植性。例如，我们是基于Google的App Engine平台开发的，想要将应用移植到其他平台上很困难。当然平台的优点也很多，例如它们提供的收集系统数据和服务。
随着新演员的出场，诸如Heroku和EngineYard的平台发生了变革。他们打破了开发者必须依赖于他们的API接口的说法。实际上，他们认为“我们将全盘接受你的应用。你可以使用专用的API接口，在我们的系统上运行你的代码将如同运行在自己的设备上一样容易，你不需要做任何修改”。对开发者来说，这是云计算发展中一个历史性的变革。
最初，PaaS为了保障变革性的服务限制了语言。例如，Heroku和 EngineYard的早期用户只能使用Ruby语言。所以优点是我们编程可以不用依赖于API接口，但是必须受限于选择的语言。
PaaS在新一代PaaS平台公司（AppFog和dotCloud）的帮助下迅速改进，不再要求使用某一特定语言。现在很多大型PaaS公司或者老牌公司，例如HeroKu和EngineYard，支持很多编程语言。从限制性平台到更加开放的平台代表云技术的重大进展。
有些PaaS公司仍然绑定使用某一种语言，但他们承诺能因为精通这种语言而给出更多好处。
在像AppFog这样的PaaS公司中有一种发展趋势就是多基础设施PaaS。我们可以同时在很多设备上运行我们的应用，哪怕是多个公司提供的设备。这是云技术发展过程中第一次用户可以同时在亚马逊Web 服务器和Rackspaces上跑应用。如果亚马逊Web服务器宕机了，Rackspaces就像热备系统一样继续运行我们的应用。PaaS所能实现的正是程序员们想要的。
