《PaaS程序设计》一1.3 云:发展历程简介-阿里云开发者社区

开发者社区> 华章出版社> 正文

《PaaS程序设计》一1.3 云:发展历程简介

简介:

本节书摘来自华章出版社《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所能实现的正是程序员们想要的。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

华章出版社

官方博客
官网链接