IT业界青睐的各种云服务

回首1991年，在互联网兴起之前，美国俄亥俄州立大学技术专家杰瑞.马丁以一份名为RFC1290的官方标准文件来宣告了处于新生阶段的互联网价值。尽管多年来RFC1290作为学术工具争论不断，但互联网作为商业计算的重要转变已呈不可抑制之势。马丁之前的宣言对这种趋势起到了早期的推动作用，最终促使互联网实现了完全的商业化。

云计算也是其中的典范，通过将IT基础架构从现场的服务器，磁盘和网络推进到异地处理，短暂循环，字节和带宽。这种转变目前还没有完全发生，但是许多学者已经将其视为不可避免的趋势。目前主要的障碍在于云的可靠性还没有得到证实--IT部门也不会轻易将公司所有珍贵的计算资源放在这个看似虚无缥缈的篮子里。

如果云还没有准备好来承担传统的商业任务，那么它对IT的价值何在呢？不错，云计算要证明自己。云里充满着IT部门可以为其所用的各种资源，从技术服务支持到灾难恢复不一而足。

像早期的互联网使用者一样，IT领域发现处于初期阶段的云就是一座等待挖掘的金矿。InfoWorld对2008年的云配置分析将云服务分为三类--即基础架构服务，软件即服务（SaaS)和研发平台即服务，这些云服务能为IT管理者提供充足的选择来帮助企业节约支出和劳动力成本。

云的许多有用工具能为IT所用

许多IT项目从实施之初就要花费整月去采购设备，接下来又要耗费时间去完成安装，配置和调试工作。这种前端的繁琐时常会导致某些小型项目的夭折。基础架构云服务的两个特色--即时供应和升级就能解决这个问题。

在最初级的阶段，基础架构云供应商会在量入为出的基础上来推销IT清单的具体细节：服务器中央处理器周期，存储容量和每秒的带宽等。这些云服务赋予了客户配置设备齐全的的应用软件环境的能力，客户在几分钟内就能完成包括服务器，存储和网络互联在内的的应用环境配置。像亚马逊在线，IBM和SUN这样的供应商都会以原始服务器的方式将效用计算的能力交付给用户，用户可以自行完成服务器的配置和管理。

这样的话，这些基础架构组件就可以按照用户的想法进行改变。由此也可以节约固定资产配置的费用和时间，不过在此之前你可能被同样的配置和集成方面的琐事搞的头疼不已。更糟的是你必须远程执行这些任务，还要承受带宽瓶颈的重荷和陌生的安全风险。对于无法利用云快速扩展能力的工作负载，任何努力都很难有所成效。

但当事先安装和配置了虚拟应用工具时，云价值就发生了巨大改变，由第三方研发人员提供和交付的虚拟工具可以作为随时导入的虚拟磁盘映像使用。在此我们不讨论诸如CRM等主要业务流程应用软件，但是以IT为中心的工具经常会由于配置费用而占据大额预算。技术支持服务，网络管理，弱点评估和企业知识库都只是用户只需几分钟就能在云上发现的应用软件的一小部分。

这些应用软件主要分为三大类：无支持的免费开源软件（FOSS），提供技术支持的免费开源软件和完全商业化的产品。不提供技术支持的分类主要是常用的网络管理工具，诸如Nagios, Cacti和MediaWiki。诸如JumpBox这样的第三方云供应商就以每年几百美元的收费推销有技术支持的免费开源软件。像思杰的Kensho和RPath公司的rBuilder这样的虚拟应用工具迁移工具能提供物理机到虚拟机的迁移引擎，帮助用户将多数免费开源软件迁移到基础架构服务上去，比如亚马逊在线的弹性计算云。

并非所有的应用软件都能从异地托管中受益，但是有些企业确实有这种需求。举例来说，Tenable Network Security公司的内萨斯弱点评估工具能对网络内外进行定义，模拟黑客攻击来搜出任何藏匿的安全隐患。但是最初节约的时间和人力成本也足够证明云项目的价值所在。

一些介于免费开源软件和商业软件之间的混合服务产品也颇具吸引力，他们能为用户提供客户管理云配置和厂商管理软件即服务。Kayako将他们的技术支持服务端口产品包括源代码在内都作为商业软件和全面管理托管服务来出售。客户可以在这些项目之间免费迁移他们的数据，另外按照每月低于50美元的收费来用于管理服务，当他们的需求得到授权时，可以将数据将以到自行管理的云配置上。

利用云灾难恢复来获取更经济的紧急备份

萧条的经济形势和压缩的预算可能会迫使企业削减那些不能直接产生效益的领域。许多企业首先考虑压缩的单元就是昂贵的灾难恢复服务。你可以想象经济是何其的不景气，但是常规的思维是企业的存活要比业务的持续性重要。每月花费5000美元用于热站却无法创造盈利机会，因此灾难恢复就成为首当其冲的目标。

不过从理论上说，基础架构虚拟化能帮助用户在云上备份企业业务流程，以非常低廉的成本潜伏在云上，直到灾难发生时再发挥作用。请大家注意这里的重点-即这是理论上的。将物理应用软件迁移到云上和保持云数据实时更新需要非常专业的技术和策略。你可以将"即时故障转移"以非常低廉的月付费用放在云上，但要想让企业的一切万无一失还是要做到居安思危。

云灾难恢复实施所需的技术在多数IT技术专家的能力范围之内，但是如果你的企业是小型的咨询类公司，你就不代表寻求外界的帮助。咨询类企业的业务量正在逐年走高，他们创建了以云为导向的灾难恢复服务套装，在收获规模效应产生的云经济优势的同时，又为中小用户解决燃眉之急。

这种服务的局限在于客户的本地互联网连接速度。但是速度和成本是成正比的，特别是光纤通讯正在渗入企业市场；多数业务在夜间进行同步备份就已经足够。举例来说，提供云灾难恢复服务的咨询公司CompuVision就是使用每秒传输速率在100MB的互联网服务中心在断电时为用户提供快速的数据传输。

在云上直接运行你的应用软件

一些云供应商，比如微软和谷歌都预测到应用软件的发展将越过传统的服务器-操作系统-存储平台阶段而直接进入云时代。虽然云计算的黄金时代还没有准备就绪，但微软的Azure已经把目标锁定了现有的技术设置。.Net的研发人员并不关心他们使用的是什么操作系统或者在什么硬件设备上运行，他们在云上就能完成代码编译，测试和应用软件配置。InfoWorld的测试中心就对Azure非常满意，但现在就将其作为主要的云产品来定义还为时尚早。

谷歌公司的App Engine目前还只有测试版，不过比Azure要略显成熟，它的市场目标主要锁定小型用户：Python研发人员。按照使用网络的Python程序研发人员对互联网连通性和自动性能升级收费，对于多数研发人员来说这是一款相对容易的应用工具。

软件工程咨询公司Denny Bollay对亚马逊在线的弹性计算云和谷歌的App Engine进行了对比：弹性计算云不错，但是必须有人担当系统管理员来解决软件工程师不想应对的琐事。App Engine在云应用软件平台环境中看起来很引人瞩目，但它也存在成本预测和厂商锁定的问题。我希望找到一款介于亚马逊公有云和谷歌BigTable数据库编译器之间的工具。我希望能看到集众家之所长的数据提供商，能交付股票，天气，新闻和其他我希望能在App Engine或其他产品上处理的实时信息流。

尽管微软的Azure能支持开放的网络应用软件标准，比如REST和AJAX，但App Engine使用FOSS App Engine组件形成了一个开源社区，这个社区目前还处于初创阶段。这些程序很多是谷歌供应的代码变种，能提供各种简化App Engine研发的计算小工具。Nuages, cpedialog和KGPL等都是可以运行的成熟网络应用程序，用户可以将其作为共享资源用于自己的应用软件研发。

云计算的自身问题

云计算对于IT领域来说具有很大的吸引力，但是在目前的云计算市场上着手配置应该注意计算成本。某些云计算风险显而易见：比如可靠性，安全性和性能。不要太快把关键任务应用软件放在云上，除非你已经做了充足的准备工作来确保故障转移机制能发挥作用。任何敏感数据都应该满足法律规定和约定俗成的标准。完善的准备工作能让你少走弯路，同时你应该选择能承受短暂断电故障的应用软件。有些故障可能是人为错误导致的，但是有些可能是云本身的问题。

云计算第二个潜在的缺陷是成本。云提供商的目的是出售服务，而不是让你的费用最小化。控制成本是用户自己的责任，如果你没有关注这方面的问题，你就会付出高额账单的代价。云提供商不会让成本跟踪变的简单。举例来说，亚马逊在线提供中央处理器每分钟消耗的日志明细，存储的数据字节和传输的兆字节等内容，但是他们不会给客户提供这些统计数据的成本计算。用户会得到一份你所使用的亚马逊服务（比如弹性计算云，S3等）所需支付的账单，但上面没有任何费用收取的明细。

意料之外的云支出来自与云自身的易于使用特性。配置一台服务器或许只需一分钟时间，但服务器保持运转都会产生费用，除非你关闭服务器。诸如Rightscale和Elastra这样的第三方云管理服务能实现成本计算流程的自动化，但用户要为这种便利付出金钱的代价--比如说Rightscale的自动升级云管理控制台每个月最少需要花费500美元。

只要你把这些警告铭记于心，你就能让云服务为你所用。