云计算概念炒作过度 面临挑战重重

服务器在线12月25日报道不是变革而是演进

云计算模式也许已经为企业的某些应用做好了准备，但肯定没有为关键和事务密集型应用做好准备，在大规模应用之前，还必须解决安全、标准等方面的问题。

不止一个关注技术行业的分析师认为，云计算(简称"云")概念被炒得过头了。几个月前，这个术语还几乎不为人知，而现在，所有技术分析师、杂志、厂商和会议似乎都在对此议论纷纷。虽然这个概念很火，但奇怪的是目前还没有就云计算到底是什么给出一致的定义。有时候，云计算与公用计算和网格计算相提并论，有时候，它又与软件即服务(SaaS)和虚拟化混为一谈。究竟何谓云计算?

不是变革而是演进

要认识云计算，最简单的办法就是结合使用场景来考虑。云计算的供应商把服务放在网上，通过HTTP、REST或SOAP等标准协议，让消费者可以借助互联网来享用服务。该服务可能是最终用户软件、计算功能、存储功能、开发平台、业务流程或者托管平台。这些服务通常放在使用者所在公司的外部，使用者不必关心软件的安装和管理。

利用云计算的应用程序有多种: 既有放在云计算环境(如Salesforce.com)中的端到端应用程序，也有内部部署应用程序使用云计算环境的一些服务(如利用亚马逊S3服务用于数据存储的应用程序)，还有自定义应用程序，它们完全为云计算平台编写，然后放在"云"上运行(如为Bungee Connect或微软的Azure平台编写，并放在上面运行的应用程序)。

从技术的角度而言，云计算与其说是彻底变革，还不如是说逐步演进。它的问世得益于互联网、SOA和虚拟化方面的不断进步。事实上，互联网正从一种纯粹用于访问各种文档的媒介，变成汇集众多应用程序的网络，让最终用户可以享用各种各样的功能。同样，由于SOA出现在企业及其他领域，许多之前紧耦合的应用程序被分离成了比较小的模块，而这些模块可以通过Web服务、经由专用网络和互联网来提供。最后，虚拟化不但让企业可以整合基础架构，还能让服务提供商可以提供共享的基础架构环境，从而为云计算充当基石。

优势不言而喻

那么，云计算果真为企业的应用做好准备了吗?回答这个问题之前，不妨看一下云计算的优势:

1. 基于使用的支付模式。在云计算模式下，最终用户根据使用了多少服务来付费。这为应用部署到云计算基础架构上降低了准入门槛，让大企业和小公司都可以使用相同的服务。

2. 扩展性和弹性。普通企业里的许多应用(包括对应的IT设备)是为了最大使用场景(如圣诞季节)而设计的，大多数时候这些基础架构的利用率非常低。而云计算环境具有大规模、无缝扩展的特点，能自如地应对应用使用急剧增加的情况。大多数服务提供商在为云计算设计架构时，已考虑到了使用猛增的这种情况，比如亚马逊、谷歌。不过，也可能有浑水摸鱼的，如果遇到新生的、规模较小的提供商，就需要认真评估它们在这方面做得如何。

3. 厂商的大力支持。也许有些厂商只是对自己的SaaS或基础架构服务改名换姓，称之为"云计算"服务，但毫无疑问，大多数厂商都在致力于提供真正的云计算解决方案。

比如亚马逊推出了EC2、S3、SimpleDB及其他服务，它提供云计算基础架构已经有一段时间了; 与此类似的是，谷歌推出了AppEngine、谷歌文件系统(GFS)及数据存储(Big Table)等服务; Salesforce.com的Force.com可用于构建云计算应用程序。微软最近宣布了Azure服务，可以在微软(或合作伙伴)的基础架构中创建及部署应用程序。Azure还将提供数据、安全、工作流、消息传送和微软Live等服务，让企业可以在云计算环境创建功能丰富的自定义应用。来自领导厂商的这种支持对云计算模式来说是好兆头。

4. 可靠性。尽管媒体竞相报道了谷歌和亚马逊出现服务中断的事件，但从长远来看，云计算基础架构实际上可能比典型的企业基础架构更可靠。领先的几家云服务提供商已经为各自的系统增添了大规模冗余功能，而且它们正在吸取以前的教训，提供更高的可见性，以减少服务不可用的可能。如果云计算服务成为核心业务后，提供商就更有条件吸取教训，提供比任何特定企业应用程序高得多的可靠性。

挑战无法回避

不过，当前的云计算模式也存在许多挑战:

1. 数据安全与隐私。云计算基础架构具有多租户的特性，厂商们通常无法保证A公司的数据与B公司的数据实现物理分隔。另外，考虑到大规模扩展性方面的要求，数据物理位置可能得不到保证。如果企业需要遵守业务交易及相关数据方面的全国或国际法规，用户可能会觉得不放心。不过，有人认为，到时候法规可能会考虑这种大规模分布式、多租户环境。

2. 数据访问和存储模型。无论是亚马逊的S3和SimpleDB服务，还是微软Azure的数据服务(Data Service)，如今提供的存储模型都需要适应许多不同的使用场景。因而，它们可能偏向采用基于二进制大对象(blob)的简单存储模型或简单的层次模型。虽然这带来了显著的灵活性，却给应用逻辑解释不同数据元素之间的关系增加了负担。许多依赖关系数据库结构的事务型应用程序就不适合这种数据存储模型。

3. 缺乏标准和厂商锁定。大多数厂商都定义了基于标准的机制(HTTP、REST和SOAP等)来访问及使用其服务。不过，在云计算环境开发服务方面的标准才刚刚兴起，而且现在缺乏一次编写、到处运行的功能。

比如，使用谷歌的AppEngine开发应用程序的方式就与在微软Azure或Force.com上开发应用程序的方式截然不同。使用某厂商的编程模型开发的应用程序要迁移到另一家厂商的平台上并非易事。不过，现在出现了像开放云计算联盟(Open Cloud Consortium)之类的组织，它们鼓励在云计算环境采用基于开源的软件开发，还在考虑制订可以协同工作的标准。

4. 处理故障。考虑到云计算应用程序具有大规模分布式的特性，要明白出现了哪些种类的故障、出现在何处也许并非易事。因此，开发的应用程序要把处理故障当做是正常执行流程，而不是例外情况。

5. 经济模型。按使用付费的模型具有某些优势，但如果使用量一直很高，那么这种模式具有的经济性就不再存在。特别是事务密集型应用如果要使用云计算，厂商就要考虑对付费实行最高限额。

众所周知，云计算模式还比较新，不同厂商对此的定义、工作模型及服务仍在不断发展之中。因此，在选择任何一家厂商之前，都需要全面分析对方提供的服务内容、服务质量、安全模型和支付模型。

总体而言，云计算模式也许已经为企业的某几类应用做好了准备，但肯定没有为关键及事务密集型应用程序做好准备。如果应用程序预计会遇到某些使用高峰，或者需要可变动的存储容量，那么它们非常适合云计算。另外，尽管传统的应用程序如果不经过一番重大改写就迁移到云计算环境上并不容易，但新的应用程序肯定会充分利用基于云计算的服务来满足某些要求。