《PaaS程序设计》一3.3 走向公开标准

3.3 走向公开标准

公开标准是平台即服务的一个重要概念,因为它们让开发者有信心独立完成与供应商提供的服务相关的应用部署。
需要了解每个不同供应商的来龙去脉完全是个噩梦。然而,我们已经讨论过了PaaS不同的类型和它们提供的不同种类的服务。
不可移植平台即服务开始时承诺“我们会向你的web应用提供Google的能力”提供不同解决方案,区别于可移植平台Heroku所说的:“零修改运行你的代码”。Heroku相对于某个平台是一套完全不同的解决方案,那个平台承诺:“我们为你打造可以在笔记本电脑桌面运行的你自己的平台。”每个供应商都在努力解决不同的问题,对于用户创建和部署应用的方式有完全不同的想法,从而产生不同标准,不一样的体验,以及不一样的展现。它们可能使用基于git的部署机制、REST API或者部署专用系统。有的可能支持持续整合,而有的可能关注部署工作。鉴于这些区别,很难以其中某一个作为标准。

3.3.1 开源的魅力

尽管一路走来出现很多不同类型的平台即服务技术,每天还产生很多新技术,最有可能从Cloud Foundry或OpenShift上产生新标准:一些提供开源选项的PaaS。
阐述这些技术的几个强有力的因素是:用户可以在自己的笔记本电脑上运行这些技术,这一点对尝试将PaaS整合到自己每天的工作事项的开发者们来说充满诱惑。PaaS开源社区的另一个好处是用户理论上可以在多个提供兼容PaaS选项的供应商之间选择,甚至自己在生产环境中运行。与之相反,除非Heroku开放其技术栈的源代码,否则用户必然被捆绑到Heroku选择的基础设施供应商。
总之,开源PaaS的这些有利条件为创建标准奠定基础,基于它们的API创建的标准不会限制用户使用特定设备或者服务提供商。它也扮演新兴标准的角色,指导用户如何以标准方式在公共和私有的基础设施上部署应用。
我们已经看到开始将Cloud Foundry API作为标准使用。AppFog用它在亚马逊 Web Services、Rackspace、HP Cloud以及Windows Azure上部署应用,这也验证了一个标准的API可以在不同后台使用。开发者通过Cloud Foundry API与这些系统交互,降低他们使用的API语言与底层设备之间的耦合度。
每天越来越多的PaaS技术变成开源的。Cloud Foundry是最早这样做的领头人之一,之后Red Hat开放了OpenShift、GigaSpaces支持开源云,甚至dotCloud在它的PaaS技术栈里开辟了一片开源领域。

3.3.2 评估旧应用

如我们看到的,现在有很多PaaS供应商,适用不同需求并拥有不同的理念。当我们考虑遗留应用迁移到云上的问题时,应当根据应用的需求考量不同平台的限制。在下一章节,我们会深入探讨将遗留应用迁移到PaaS上,并为用户可能会面临的一些困境提供解决方案。

时间: 2024-09-27 12:57:04

《PaaS程序设计》一3.3 走向公开标准的相关文章

《PaaS程序设计》一导读

前 言 编程很艰难编程是一项很艰苦的工作.相当艰苦.当你完成代码编写并且编译成功,你很开心.可是你会发现程序存在bug,这耗费了你几小时.几天.甚至几周时间去查找.定位.解决这些问题和边界情况.当你完成所有编码并且认为不会再有更难的问题了,你还得部署代码:Vim apache.conf.vim my.cnf.vim /etc/host.iptables.当你觉得你是一个程序员时,突然你深深陷入了系统管理的泥潭中,完全不明白怎么会这样.程序员比较擅长的事是创造性的偷懒.当一个程序员重复做同一件事情

《PaaS程序设计》一3.2 可移植性:不再繁琐

3.2 可移植性:不再繁琐 可移植PaaS是这样一种平台,在其上运行的代码编写完成之后,就不需要进行较大修改.开发者在共享主机或者专用主机上开发的代码迁移到可移植PaaS上不再那么困难.想要运行应用不再需要依赖服务转接器. 平台仍然存在局限性,这是需要应对的挑战,但这些局限相对代码来说更偏功能性. 可移植性扩大了平台即服务支持的语言数量和类型,也扩大了语言自身的灵活性.如果我们想要将应用移植到不同的可移植PaaS平台上,需要调整应用的某些内容,但不需要彻底改写系统. 相对而言,看看早期的Goog

《PaaS程序设计》一2.3 PaaS:综合两种方式的最佳方案

2.3 PaaS:综合两种方式的最佳方案 对于开发者来说,通常会以共享主机的方式起步.很快,就会经历需要更强的功能和控制的阶段,于是,就会转向独立主机托管.在完全拥有了控制权之后,你可能会感到很惬意,也会很兴奋,因为你可以对服务器进行调整和优化,让它们运行得更快,网站可以更快地的被加载,并且可以处理更多的用户请求. 然后,随着时间的流逝,兴奋感很快就会烟消云散,因为日复一日维护服务器所增加的负担,会让人筋疲力尽.独立服务器可以提供更强的功能和控制,但是很容易就会遭受攻击,而作为开发者,你必须自己

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

1.3 云:发展历程简介 什么是云?这个外来术语被过度使用. Dropbox就是所谓的云么?或者是iPhone?还是Gmail? 对某些人来说,这些林林总总的例子也许就是所谓的云,但对开发者而言不是. 对开发者来说,云是相互关联的一组基础技术,借助这些技术可以采用新的方法来构建和运行新的技术.如果用户不能在基础技术上开发新技术,那就不是云. 很多应用和SaaS都是基于基础云技术构建的.Dropbox和Gmail就是建立在基础云技术上的SaaS应用.但它们本身不是云技术. 20世纪90年代数据中心

《PaaS程序设计》一3.1 不可移植的PaaS:遵照一个模板

3.1 不可移植的PaaS:遵照一个模板 采用不可移植PaaS的平台即服务,我们就可以基于这个平台的独特规范和API编写代码,从而创建应用.这意味着我们的代码结构需要严格依附于特定的模板或应用编程接口(API).这些API可能主要集中在服务数据库.存储架构或者搜索架构上.而其他时候,API属于低层次并且面向编码的.有时候我们必须使用专门为那个平台所构建的特定语言.正如我们所看到的,这种平台里有各种不同类型的"钩子",使得它可移植性较差.最早形式的平台即服务就是建立在这种结构化很强的想法

《PaaS程序设计》一1.6 云计算的承诺(或者炒作)

1.6 云计算的承诺(或者炒作) 从开发者的角度来看,这个兴盛的新兴领域的部分挑战决定了云计算是不是都是炒作. 对于一个开发者.公司或者政府机关,Gmail究竟能有多大改变?可能不会很大.它也许是有一定先进性,但绝不是变革性的.然而,学会在现代化公司的运维工作中充分使用基础云技术,例如DevOps或者PaaS,无论你是刚开始使用还是正在使用,只要这些技术能让我们的工作更简单高效,那就不是炒作.相反,这正是高科技公司创建和运维的模式.这是事实.毫无疑问,我们正迎头迈入云计算时代. 当技术产生于技术

《PaaS程序设计》一1.1 开发者的困境

1.1 开发者的困境 开发者到处都是,他们工作于小公司.政府机关.企业或者自己创业.所有开发者都在面临相同的挑战:处理开发过程的运维事项.工作环境的不同使得问题看起来不同,其实核心问题是一样的. 例如,让我们回顾一下传统的瀑布开发过程.通常,开发者编写代码并在开发/测试环境里成功运行.然后就交付给IT团队,在这一环节的运维人员花几周甚至一个月时间验证应用的质量并实施部署,造成应用产品化的极大延迟.工作超期,产品测试延迟,最终,也许最难以承受的后果就是减缓了创新的速度. 速度,或者缺少速度,就成为

《PaaS程序设计》一2.4 PaaS:现代应用的虚拟工具

2.4 PaaS:现代应用的虚拟工具 在过去的数十年中,应用开发发生了巨大的变化.从早期的在计算机上运行编译的代码,到客户/服务器架构,再到现在的REST 应用编程接口(API),编译和运行代码的工具也发生了很大的变化. 2.4.1 转向高级语言 让我们回到早些的那个例子:需要一个程序进行DNA测序,这个程序要运行得尽可能快,因此,我们可以使用诸如C或者汇编的底层语言,以便获得尽可能高的性能.使用PaaS,通常需要构建Web应用程序,延迟并不是那么的至关重要.对于运行在PaaS上的不同类型的应用

《PaaS程序设计》一2.5 重建信心

2.5 重建信心 在我丢失了网站数年之后,平台即服务开始出现.平台即服务的出现可以让应用程序更容易以更快的方式运行.现在,备份应用程序可能只需要点击一个按钮.开发者不再需要担心服务器宕机,因为自然有人维护这些服务器.PaaS重建了现代开发者部署应用的信心和激情.随着采用PaaS并充分利用其功能,接到可怕的电话:告诉你服务器挂掉的时代一去不复返了.