云计算2009年仍然延续了它在2008年的热度，不难预料，运行在云上的应用(以下简称云应用)肯定会越来越多，随之而来的是，肯定会有越来越多的开发人员不得不考虑或者参与开发云计算。
云计算的本质是通过互联网访问应用和服务，这些应用或者服务通常不是运行在自己的服务器上而是由第三方提供。对开发云计算的技术人员而言，在云计算模式下，尽管部署应用时无需关心基础设施方面的问题，但同时也带来了一些新的问题，比如开发云计算人员不能用以前熟悉的方式调用数据库、应用程序呈无状态特性以及必须采用不同的开发框架等。
开发云计算的挑战
“开发云计算最大的挑战是，软件必须能根据应用的需求自己调整和提供所需要的资源。”Sun云计算部门CTO Lew Tucker说，幸运的是，借助云平台提供的API，云应用的开发人员可以从云的提供方申请更多的资源。
开发云计算人员还必须进行冗余设计，要认识到很有可能在“云”中的服务器只是普通的服务器，微软Azure云平台副总裁Amitabh Srivistava说，“很有可能服务器会出问题，因此，你必须在开发云应用时考虑冗余。”
开发云计算时还必须考虑到Web应用的无状态特性(无状态性是指客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前请求，而不必了解所有的请求历史—编者注)，Srivistava说，“如果你的程序要求保留状态信息，程序在运行过程中肯定会出问题。云计算的模式是，如果什么地方出了问题就终止它，然后另外再启动一个程序。只有保证每个应用程序的运行都是相对独立的，也就是状态无关，才能达到这一目标。”
Srivistava进一步解释说，例如，在云中没有本地磁盘这个概念，也没有注册，在无状态的应用中，这些参数都要被封装起来打包在调用的参数中。
Sun公司Tucker提醒说：“无状态保证了应用程序简单，但是，要开发出真正有趣而且好用的云计算应用又需要一些状态信息，比如我们必须保存用户的信息以免要求用户不停地登录，这就是为什么我们仍然需要数据库或者其他一些什么东西来保存状态的原因。”但是，有部分云上的应用(如Web的前端)需要根据访问量动态地进行调节，必须是无状态的。
开发云计算应用的另外一个特点是：应用程序的不同部分可能分别运行在云的不同地方。例如，一个应用程序的表现层可能运行在Facebook，而其存储部分可能运行在亚马逊的弹性存储服务(S3)上，其应用程序的逻辑部分又可能运行在另外一个完全不同的地方。
“而以前程序员开发的程序都运行在自己的服务器上。” Tucker说，“这就意味着，开发云计算应用时必须重新考虑系统的架构，特别是要考虑云应用的大规模特性，不仅是用户数量大，而且计算资源分布也很分散。”
Tucker补充说：“也不要把云应用想得多么神秘。其实没有什么诀窍，要让开发云计算应用可扩展，需要仔细地设计和规划。”
不过，云平台可以给我们提供一些帮助。在某些情况下，比如使用Google App Engine来开发某些特定的应用时，程序自然就具有了可扩展性，无需开发人员考虑。有时候，我们可以使用某些设计模式，这些设计模式可以用来为应用程序提供扩展能力。例如，亚马逊弹性计算云(EC2)的Multiple Availability Zones，开发云计算人员在这里可以把一个应用部署到多个地方运行。
“以前，只有大公司能做到这一点。” Kay Kinton公司的发言人说。EC2有一种称为弹性IP的功能，它能快速建立一个互联网地址的映射，把准备发送给失败的应用实例的请求转给一个有效的实例。
不同类型的数据库
在云应用中，抽象和无状态在对数据库的访问时也同样适用。“例如，Azure就给 开发云计算人员提供了一种与访问标准的关系型数据库完全不同的方式。”Benjamin Day咨询公司总裁Ben Day说，“Azure的存储引擎也没有使用关系数据库，因此以前开发应用时所采用的很多方法在开发云应用时就行不通了。”
他还以关系型数据库中的存储过程为例来说明，在关系型数据库中，查询逻辑与实际的数据位置很近，编程者可以明确知道数据在哪里、保存在哪些设备上，而在Azure云中，这个前提不再存在。
“开发云计算应用在访问数据库时的困难在于，无法保证你要读取的数据库在某一指定的位置或者数据中心或者某一指定的设备上，”Day说，“因此，最终你只能使用最基本的SQL查询语句，而很多存储过程由于与数据库的具体类型密切相关而不能使用。”
另外，Day补充说，Azure的存储引擎也与微软规划中的SQL Server的云版本SQL数据服务(SQL Data Services)有很大区别，因此，开发人员需要了解自己到底是在使用哪个数据库引擎。例如，Azure把一个1MB的文件作为一个Blob类型的数据保存，而SQL Server中会把这个文件保存在一张表(table)中。
开发云机算应用与普通应用在访问数据库时有明显区别的并不仅仅只有Azure，使用Google App Engine时也有同样的问题。
Google的App Engine产品经理Pete Koomen介绍说：“Google App Engine不仅对实际的物理硬件进行了抽象，而且对关于设备的所有概念都进行了抽象。”这保证了开发人员把代码上传到Google以后，Google可以把这些代码和数据库分开管理。“因为Google把其中的很多流程都实现了自动化，因此，开发人员必须遵循一定的规则，这些规则与我们以前在传统的SQL模式下的规则有很大区别。”
在使用App Engine时，开发人员把那些要长期保存的数据存储在Google的大表(Big Talbe)。“大表不是SQL数据库。我们之所以使用大表而不用SQL数据库，原因在于SQL数据库要支持很多功能(例如Join功能),这使得我们要把一个数据库放到多台服务器上运行非常困难。”
“在使用我们的系统开发云计算应用时，我们会提供一个编程模型，并从一开始就鼓励程序员们采用一些反常规的方式，比如，开发人员会在一次存储过程中把数据分散保存在多个位置。”他说，这样做的好处是保证应用程序在执行查询时效率非常高。
Koomen对在云环境中使用关系型数据库持反对态度。他说:“我们发现在访问量很大的情况下，关系型数据库非常难于管理，为了解决高访问量带来的一系列问题，程序员不得不投入大量的时间和精力。”
必须习惯于变化
咨询公司Model Metrics曾帮助客户在Salesforce.com和其他一些平台上部署了云应用。它们发现开发云计算应用和B/S应用开发的一个主要区别是，“云上的应用改变要快得多。” Model Metrics的CTO John Barnes说，“例如，Salesforce.com一年要出好几次新的版本，每个新版本中很可能都会有值得一用的新功能和新特性。”
Barnes建议，“作为一名云应用的开发人员，你必须在技术上与云平台保持一致，必须关注很多技术博客，也要积极参加一些网络研讨会。”
开发人员还应该了解不同的设计模式，例如最终一致性(Eventual Consistency，最终一致性是一种一致性的模型，用于并行编程，例如分布式共享内存和分布式交易。最终一致性指的是，在一个较长的时间内，如果没有更新的话，所有的更新都会在系统内部进行传播，最终保证所有数据的拷贝都是相同的—编者注)。 采用这种设计模式时，如果程序对数据进行了修改，也许要在几毫秒之后才能在数据库中反应出来，“这种设计模式带来的结果是，很可能从数据库中取出的不是最新的值，”Barnes说，“由于诸如此类的原因，程序员开发云计算应用时编程方式会有一些不同。”#P#
系统管理变简单
对程序员而言，并不是说云只是带来麻烦，在云环境中，也有些事情变得简单了。
Barnes说：“比如，云提供的利用Web服务来组装应用程序的松耦合方法就把云变成了一个相对轻松的开发平台。”
这保证了开发云计算人员可以把精力集中在创新和业务逻辑上，而不用像以前一样，要在一些基础性和辅助性的工作上浪费时间(如要关心操作系统和硬件的配置等问题)。例如，Salesforce.com的云开发平台Force.com就提供了安全、工作流、系统管理和负载均衡方面的功能。
Model Metrics有一个客户最初决定在微软的.Net平台上开发一个大学生管理系统，后来发现如果改在Force.com上开发，其开发成本可能只需要原来的1/3～1/4，因为Force.com有很多现存的功能模块可以利用。
兼顾可能的迁移
无论如何，开发者必须牢记开发云应用与传统的套装软件的区别。Barnes说，对云的开发人员而言，还有一个值得留意的是，开发云应用时要注意不同云有不同的定价方法。
Salesforce.com开发者市场部副总裁Adam Gross还提醒那些准备在云平台上开发应用的开发人员说，需要了解他所选择的平台提供了哪些功能、有哪些特点，以便为将来的迁移做准备，“开发人员在开发云应用的第一天就要考虑到这个问题，应该尽量选择云平台上的那些非专有的技术和功能，以保证有一天能够顺利地从这个平台迁移到另一个云平台。”
Koomen对此也表示认同，他说：“Google支持流行的Python语言和Django Web框架，这就在一定程度上保证了应用的可移植性。不仅如此，Google现在正在开发开源的上传和下载工具，来让用户方便地把数据上传到App Engine中或者把数据从App Engine中下载下来。”
【编辑推荐】
