【IT168 专稿】早在1991年互联网还没有成气候的时候，俄亥俄州立大学的技术专家Jerry Martin发布了一份题为《网络里有金！》（RFC 1290）的官方标准文档，揭示了新兴互联网蕴含的巨大价值。尽管之前互联网作为一种院校的研究工具已流行了好多年，却一直没有为商业计算带来重大的根本性转变。Martin的这番正式宣告对互联网商用起到了早期的推动作用。
与之类似，正处于萌芽期的云计算承诺会带来类似的根本性转变：把底层的IT基础架构从现场、用户控制的服务器、磁盘和网络，变成异地、生存期短暂的CPU周期、存储容量和带宽。这种转变尽管目前还没有发生，但许多专家认为这是不可避免的趋势。限制云计算发展的最大障碍在于其可靠性还没有得到证实――IT公司不喜欢把所有宝贵计算资源都放在难以把控的云环境中。
既然云还没有准备好处理传统的商业任务，那么它对IT人员又有何价值呢？没错，云需要证明自己。云中充斥着各类计算资源，从技术服务支持到灾难恢复，不一而足。
与互联网的早期使用者一样，IT部门也发现刚刚崭露头角的云计算到处是值得挖掘的金矿。《InfoWorld》杂志曾分析了云在2008年的发展状况，确认了三项主要的云服务：基础架构服务、软件即服务（SaaS)以及开发平台即服务，它们为处于困境的IT经理们提供了诸多节省人力和成本的方案。
云为IT人员提供了许多有用工具
许多IT项目都是这样开始的：先花一个月的时间采购设备，接下来再花一个月的时间来安装、配置及调试设备。对小项目来说，这种前期负担常常是好心做坏事。基础架构云服务的两项显著功能：按需配置和灵活扩展就能提前阻止这个问题的出现。
拿最基本的基础架构服务来说，基础架构云提供商根据按需付费的原则来销售基本的IT资源：服务器、CPU、存储容量和带宽。这种云服务让客户能够在短短几分钟内启动独立的应用环境：包括服务器、存储容量和网络连接。像亚马逊、IBM和Sun都供了这种原始服务器形式的公用计算功能，用户可以自行配置及管理原始服务器。
然而，这些基础架构的组件本身还有许多有待改进的地方。虽然它们可以为你节省部署资本设备的时间和开支，但你还是跟以前一样要处理同样的配置和集成等事务。更糟的是，你必须远程处理这些任务，还面临着带宽瓶颈和新出现的安全风险。对无法充分利用云计算灵活扩展功能的相对稳定的工作负载而言，云计算确实是鸡肋。
但如果你考虑预先安装、预先配置的虚拟设备（virtual appliance），云计算方案的价值就会发生显著变化。一大批第三方开发商都可以提供这种虚拟设备以作为随时可以启动的虚拟磁盘镜像来使用。我们这里讨论的不是像客户关系管理（CRM）之类的主要业务应用软件，而是常常因部署成本而超出预算范围的以IT为中心的工具。如果使用云计算，类似技术支持服务、网络管理、安全漏洞评估和企业知识库等应用短短几分钟内就可以在云中启用。
这些应用软件分为三大类：不受支持的免费开源软件（FOSS）、受支持的免费开源软件和真正的商用产品。不受支持的FOSS这类包括流行的网络管理工具，比如Nagios、Cacti和MediaWiki。像JumpBox这些第三方云服务提供商销售同样这些FOSS应用软件及另外几十款软件，而每年收取的支持订购费只有几百美元。像思杰的Kensho和RPath的rBuilder这些虚拟设备迁移工具则提供了物理机到虚拟机（P2V）迁移引擎，可帮助用户把大多数FOSS设备迁移到基础架构服务上，比如亚马逊的弹性计算云（EC2）。
并非所有这些应用软件都得益于异地托管，但有些肯定需要异地托管。比方说，Tenable Network Security公司的Nessus安全漏洞评估工具原本就是驻留在网络外部的：它模拟黑客攻击，查出任何网端的安全漏洞。单是最初节约时间和人力的优点也足以证明有必要上马基于云的项目--即便这个项目很简单。
许多混合服务产品同样具有吸引力――它们是FOSS和商用软件的混合体，既提供客户管理的云部署环境，又提供服务商管理的SaaS。Kayako将其一系列技术支持门户产品（包括源代码）作为可购买的软件和作为全面管理的托管服务来销售。客户可以在应用软件之间随意迁移自己的数据，因而一开始可以使用每月不到50美元的托管服务；如果需求出现了增长，又可以改用自己管理的云部署环境。
借助基于云的灾难恢复，用较低的成本做好灾备
经济低迷和预算吃紧往往迫使不能直接产生经济效益的IT部门开支受到削减。许多企业最先削减的其中一个方面就是成本高昂的灾难恢复服务。你可能会认为这么做欠妥，但一般人的看法是：贵企业的生存比业务连续性问题来得重要。每月花费5000美元、但从来没有用过的热备份站点需要一到两名员工--也就因此很容易成为被削减的目标。
但不需要这样。基础架构虚拟化在理论上让用户可以在云中复制一套业务流程，这样业务流程就能处于待用状态，而成本非常低，直到你遇到灾难时可以启用。注意，这里的重点是"在理论上"。把物理应用软件迁移到云上，并且经常更新放在云中的数据需要相当专业的技能和策略。这样以牺牲"热备切换"的时间来换取大大降低的灾备成本，但你要接受一个现实--数据并没有保存在本地。
大多数IT技术专家具备实施云灾难恢复所需的技能，但如果贵企业是小企业，就得寻求外界的帮助。许多咨询公司正在积极开发面向云的灾难恢复服务套件，为相对缺乏经验的用户处理棘手问题，同时仍获得云的规模经济效应。
这类服务的一个局限在于客户的本地互联网连接速度。但是在成本暴跌的同时，企业的互联速度也在不断提高，特别是由于光纤连接方案进入到企业市场。这种方案基本上足以胜任夜间备份同步工作。比方说，CompuVision就是这样一家提供基于云的灾难恢复服务的咨询公司，它使用速率为100MB/s的互联网服务中心，在灾备服务停用时还可以提供快速的数据传输服务。
在云上直接运行应用软件，消除基础架构问题
几家云服务提供商（包括微软和谷歌）预测，应用软件开发环境会直接转移到云上，绕过传统的服务器/操作系统/存储平台。虽然云计算的黄金时代还未到来，但微软的Azure云计算操作系统已经开始充分利用现有.Net开发人员拥有的技能，让他们无须担心在什么操作系统或什么硬件上运行，即可编写代码、测试及部署应用软件。虽然《InfoWorld》测试中心测试Azure后觉得其架构设计精良，但仍然得出了负面结论：预言Azure会成为一项重要的云服务还为时过早。
谷歌的应用引擎（App Engine）要简洁得多，目前也只有测试版，不过比Azure要略显成熟，它面向一个极小的用户群：Python开发人员。应用引擎号称是具有Web功能的Python，又有着丰富的互联网连接和性能自动扩展功能；对大多数开发人员来说，接受这个工具比较容易。
软件工程顾问Denny Bollay曾比较了亚马逊的EC2和谷歌的应用引擎。"就其本身而言，EC2不错，但有人得充当系统管理员的角色，软件工程师可不想处理这种事。Google的应用引擎似乎在尝试首次成为简化的云应用平台环境，表现不错，但存在成本预测和厂商锁定等问题。我其实寻求的是，集亚马逊的非专有云与谷歌的云编译器（带BigTable数据库）于一体的东西。我还希望看到混合型的数据提供商，能够提供天气、股票、新闻之类的实时数据，我可以在应用引擎或类似平台上动态、实时地处理这些数据。这其实就是'云的催化'（cloud-seeding）。"
虽然微软的Azure支持开放的互联网应用软件标准，比如"代表性状态传输"（REST）以及异步Javascript和XML（AJAX），但谷歌的App Engine借助实际的FOSS应用引擎组件，培育出了一个新兴的开源社区。许多这些开源软件是谷歌提供的Gaeutilities的变种，提供了简化应用引擎开发的各种计算类窗口组件。像Nuages、cpedialog和KGPL等其他开源软件是完全成熟的互联网应用软件，拿来就可以运行，也可以用来二次开发成自己的应用软件。
使用云计算需注意"潜伏"陷阱
云计算对IT部门来说有很大的吸引力，因为有些方面见效快，但你在部署到如今的云服务平台之前一定要计算好成本。有些云计算的风险很容易察觉：可靠性、安全性和性价比。不要过于仓促地把关键任务应用软件放到云上，除非已经做了必要的准备工作，确保拥有足够有效的故障切换机制，并且确保任何敏感的数据都满足职业道德和法律层面的标准。考虑周到的准备工作让你可以远离麻烦，但应该选择能承受短暂服务停用的应用软件（从可靠性方面考虑）。
第二个潜伏的陷阱是成本控制。云服务提供商本来就以销售服务为生，而不是尽量减少用户的开支。密切跟踪成本是你的责任；如果你没有留意计算成本，到头来会收到一大笔账单（与以往相比可能得不偿失）。云服务提供商并没有为跟踪成本提供什么便利。比方说，虽然亚马逊提供了极其详细的日志，显示了每分钟耗用的CPU、存储的数据字节和传输的兆字节，但没有为这些统计数字提供估算成本的任何方法（因此云计算服务提供商们还需要继续完善其模式）。最后你会收到所使用的每项亚马逊服务（EC2和S3等）累计起来的总账单，但没有详细说明每一项的费用。
导致出现意外云开支的第二个因素是云本身的优势--易于使用。启动一台或十台服务器只需要一分钟，使得灵活扩展很方便，但服务器在所需应用完成之后继续运行，不断产生费用，直到关闭服务器为止--因此使用云服务时非常强调对自身业务和所需计算量的实时调整。像Rightscale和Elastra这些第三方云管理服务使核算成本过程实现了自动化，还能设定严格的开支限额，在费用达到设定的时候发出通知并暂时关闭服务。不过用户要为这种便利付出代价――比方说，使用Rightscale可自动扩展性能的云管理控制台每个月至少需要500美元。
只要你牢记这些防备措施，完全有理由现在利用云服务来减少你面临的IT问题。
