云所传达的信息一直是非常简单的：抛开具体流程与相关IT管理工作，由服务供应商打理一切。用户不再需要亲自动手安装服务器、一次又一次检查后备发电机的燃料剩余或是对成千上万个可能出错的环节加以调试。噩梦般的日子已然过去，如今大家只要把数据和信用卡准备好，其它的交给服务商即可。

在过去几个月中，我一直梦想着建立起全球最为庞大的计算设备帝国。无处不在的虚拟机将我的数据拆分成无数极小的单位，并负责处理规模更为可观的数据内容。私有网络在不同虚拟机之间承载着我的加密信息，这样其他人就能对数据加以利用并将其转化为漂亮而直观的图形化结论。当然，我用的台式机已经相当陈旧;虽然可以为其添加更大的内存，但云服务能够帮助我仅仅通过浏览器就自由调配来自世界各地的计算资源大军、从而轻松搞定个人设备无法完成的高强度工作负载。

另一大好消息在于，当我完成手头的工作之后，这些汇聚起来的虚拟机资源也将同时回归原位、不再作为我的独占方案而继续计费。这正是云的最大优势——我们可以根据实际需求在必要时加以购买。需要强调的是，微软推出的Windows Azure云过去常常出现计费错误，但如今技术支持方案已经解决了这个问题。再有，我也希望微软方面能够改变一下消息提醒机制，不要总是向我的信用卡账单发来仅仅几美分的云服务使用费通知。

在分布式虚拟机来来往往的过程中，我们实际需要支付的金额其实非常低。如今物价飞涨，大部分一元店也可以出售价格不超过十块钱的货品了;然而在云服务领域，大家仍然能够用一丁点零钱买下虚拟机及计算资源的使用权。这实在是一项了不起的成就，也证明了小钱如今还是能够办点大事的。

关键性区别

在进行了一番探索后，最令人惊讶的启示在于云计算世界是如此多样。如果我们仅仅把云设备当作一种通用化商品，实际上就犯了先入为主的错误。云服务厂商的营销团队希望让客户以为各类云环境下的计算设备与存储体系都像乐高积木一般可以随意替换，但事实并非完全如此。每一家供应商都在努力拿出不同于其它的独特解决方案，从而将自家虚拟机与服务同其它竞争对手区分开来。虽然对于普通用户来说往往需要在使用一段时间后才能体会到不同服务之间的差别，但在需要利用云环境处理大量业务工作的用户眼中、不同方案之间可以说是天差地别。

这种差异从操作系统开始就已经出现了。虽然很多人可能认为云环境使用的是Linux系统——毕竟Linux可谓无处不在，但具体采用哪套发行版仍然存在取舍。面对Ubuntu等普及度很高的标准版，各云服务供应商仍然有可能创建自己的版本、从而对现有功能进行小幅或者大幅强化。以Amazon Web Services与谷歌计算引擎为例，它们都为云体系开发出了自己的Linux版本。Rackspace的用户们可以从一系列免费Linux系统中作出选择，也能够以按月付费的方式使用红帽企业Linux。

Linux并不是惟一的分歧之处。大部分云方案都将微软Windows当作额外的备选项目，不过大家在微软的Windows Azure以及戴尔Cloud当中无需为此支付使用费。很明显，各大厂商都希望能将微软雄厚的客户基础吸引过来，帮助使用者更为轻松地将现有计算任务迁移到云环境之下。任何已经付费购买了微软技术方案的客户都能在其中找到一点熟悉的感觉。除此之外，Joyent Cloud使用的则是名为SmartOS的操作系统——属于OpenSolaris这一强大系统的衍生版本。

更深层次的差异则更容易被人们所忽视。尽管所有硬件看起来都采购自英特尔、它们在机架上的运行效果好像也没有差别，但实际情况是这些多核心刀片设备往往会被拆分成一个个独立的虚拟机系统，从而更为灵活地满足大家的计算需求。我们租用的并不是客观存在的专有设备——云服务的运作机制更像是假日酒店或者度假村，用户以使用数量及时长为基础付费、其余时间资源则被分配给其他使用者。

虚拟机基准测试

在对虚拟机进行处理速度测试时，不同云方案间的差别将变得更为明显。各大供应商试图帮助我们创建独立单位以完成CPU性能测试，但他们给出的指导机制显然太过粗糙。我利用自己的云资源处理DaCapo提供的Java程序，这种测试方案非常适合以Java应用程序开发作为主要工作内容的用户。DaCapo套件会对多种不同作业类型进行测试，其中包括在Java当中创建图像以及启动Tomcat服务器。即使是不涉及Java开发的用户，也可以通过这种方式对具体云服务方案的处理能力进行宏观审视——毕竟不同基准测试对于设备资源的压力指向类型也有所区别。

最终测得的差异居然如此显著，我们甚至在同样的虚拟机上也无法跑出同样的测试结果。这是因为不同的云设备组合会利用不同类型的虚拟化层处理各类设备驱动。这种有趣的方式会将“区别”累积起来，并最终产生完全出乎意料的实际结果。

首先来看Lucene，一款用于对大量文本文档进行检索的工具。在索引创建测试当中，SoftLayer的基础虚拟机能够轻松拿出两倍于Amazon基础实例的性能表现。不过在索引机制创建完成后，SoftLayer的虚拟机在索引内容搜索环节下的性能优势就只剩下30%了。

这样的结果甚至经常会出现在同一套云方案中的虚拟机身上。以谷歌为例，其云服务提供的计算设备往往无法按照用户预期进行运作。高性能CPU虚拟机的基准测试运行速度往往只比标准虚拟机略快一点、有时候甚至完全一致。而在Tomcat模拟当中，高性能虚拟机的速度又达到了标准版本的两倍。但更令人费用的是，高性能版本在Avrora基准测试中反倒比标准版本慢出近三倍。

在这一系列对谷歌虚拟机的测试当中，一分钱一分货的道理虽然仍基本靠谱，但程度却远不及大家的想象——有时候甚至完全相反。添加更多CPU能够在一部分多线程测试当中取得正面效果，但有时候反而会让其它测试的结果变得更差劲。同理，添加内存容量同样基本有效，但提升效果并不稳定。以上各类提升手段对于实际测试速度的影响让人觉得有点摸不着头脑。大部分测试在反复进行时都能得出基本一致的结果，但仍有一部分(例如XALAN解析器)会给出差异巨大的测试结论。

综上所述，这意味着大家需要具备丰富的专业知识并通过大量实验来找到以下问题的答案：一套虚拟机的实际价值究竟如何?喜欢精打细算的朋友需要在付费之前，认真考量不同虚拟机在基准测试当中的实际表现。很明显，SoftLayer虚拟机在处理Lucene索引创建任务时表现最出色，但在搜索时的优势则没那么明显。这种差异意味着每个人都应该对自己的实例进行计时运行测试，并以此为依据进行服务方案采购。大家不能想当然地认为每小时要价3美分的云设备就要比要4美分的更划算——这个问题没那么单纯。

数据存储

虚拟化影响给用户带来直观感受的一大领域在于数据存储。数据库高度依赖于磁盘驱动器的I/O通道速度，而且虚拟化机制下带来的每一丁点额外数据都会拖慢其处理速度。某些云方案在这方面并没有下力气调整，因为他们可能认为大部分用户还是希望能在自己的内部设施中运行数据库。

另一些供应商则建立起自己的特殊数据存储服务。以SoftLayer为例，他们在经过单独调校的虚拟机上运行MongoDB，借此提高数据写入的性能表现。大家应该充分发挥这类特殊服务的性能优势，而不要迷迷糊糊地将MongoDB放在自己的普通实例当中。惠普Cloud与Rackspace Cloud则以同样的方式提供MySQL即服务方案。

不少厂商都在努力把同样的机制推广到更多数据库技术当中。他们将虚拟化层剥离出去，同时创建出各类API、允许用户根据实际数据规模而非虚拟机数量进行存储资源采购。他们希望能在自身经过高度优化的操作系统当中获得远超普通设备的实际运行效果。

其它服务项目也都在强调差异化性能属性。Amazon提供一套广泛的数据存储解决方案，能够将数据内容打包并在需要时进行恢复;不过其中最引人注目的要数Glacier服务，它的设计思路在于以低廉的价格提供“以小时为单位”的数据检索时间——没错，不是毫秒、秒或者分钟，而是小时。

当然，大家也可以额外购买一套内部设备并安装自己最喜爱的存储解决方案;不过这类托管方案仍然拥有显著的吸引力，足以让大家安心地把数据交给其打理。如果某套云体系具备大家喜欢的数据存储层，那么其它工具带来的差异一般说还是可以忍受的。

网络选项

另一个值得探讨的话题就是网络。某些云方案——例如戴尔Cloud以及SoftLayer——提供用于同虚拟机连接的私有网络。在私有网络的支持下，大家往往更容易接受将数据库迁移至云环境当中，毕竟与公共互联网相比、利用私有网络传输业务数据要更安全一些。虽然这项技术本身还称不上完美，云安全目前也仍然是个极具争议的话题，但我们应该将其视为一个良好的起点。

另外一些供应商则从更为具体的地理区划出发提供云服务方案。了解到虚拟机的实际部署位置有助于大家制定数据存储考量以及最终决策。特别是对于那些较为固执的员工而言，将高价值数据副本保存在位于不同区域的云基础设施当中能够有效抵御风暴、火灾以及其它意外灾害所带来的潜在威胁，从而保证企业更为安全地平稳运营。举例来说，谷歌就以非常透明的方式公开了不同数据中心之间的带宽使用成本，因此同一数据中心内部的数据传输流量也可能带来不同的使用成本。

带宽计费制度又是另一大容易引发误解与争议的指标。以戴尔Cloud为例，它不会收取任何带宽使用费，但提供的服务品质自然也不太可能让人满意;这就像是可以免费入住但却蟑螂遍地跑的汽车旅馆——厂商能够借此简化价格计量与核算机制，对价格比较敏感的用户也会对此表示认同。如果大家正打算建立一套像《银河系漫游指南》中那样规模庞大、需要处理海量数据，但却只需要返回单一数值(42)的体系，那么这类方案还是很有竞争优势的。

更多考量标准

云服务当中最有趣的部分就是包含大量针对特定工作的虚拟机。虽然它们并不属于大家每天都在使用、能够运行PHP代码的普通虚拟机，厂商仍然承诺帮助用户借此大大简化未来需要面对的各种挑战。举例来说，Amazon已经准备好了大量显卡(也就是GPU)供用户进行实验，我们可以将想象得到的一切算法交给它们打理、由此评估其实际价值。物理学家、生物学家乃至计算机科学家们已经开始在这些虚拟机上运行自己的算法。作为典型实例，这向我们昭示了云计算这一新型体系架构如何切实简化自己的研究工作以及日常需求。

这些特殊堆栈并不一定需要搭配特殊的硬件设备，但基于性能考量而提供特定优化方案的例子也不少。目前已经有多种云服务——其中包括Amazon、Joyent以及Windows Azure——提供专门用于Hadoop负载的设备选项。这些厂商对底层操作系统以及JVM进行了调整与优化，旨在获得更为出色的性能表现。Joyent宣称其虚拟机的运行速度“提升到近三倍”。真的假的?这取决于大家要用这些虚拟机运行哪些具体负载。就其本身而言，Amazon拥有大量直接面向Hadoop作业的虚拟机，从而帮助大家避免在自己的普通虚拟机上处理这类高强度计算任务。

除此之外，还有很多引起我个人高度关注的其它功能。一部分云方案在性能测试与图形化仪表板方面比其它竞争对手表现得更为突出。刚开始我对这类情况非常纠结，但挣扎了一段时间之后我决定将关注重点转移到其它方面。了解虚拟机的全局负载当然非常重要，但大部分开发人员更倾向于利用自己的统计工具掌握虚拟机的当前运行情况。不过大家的具体需求可能有所不同，也许很多用户对这类额外功能非常看重。

另一类功能最终也可能成为决定云方案成败的关键性因素。目前云环境下已经诞生出一部分新型功能，旨在使其更轻松地实现虚拟机自动化、并根据个人使用情况进行少量配置变更。Amazon允许大家利用同一套镜像创建出上百套新虚拟机系统，而后通过对配置信息的调整对它们加以区分——整个过程以自动化形式完成，我们不必逐一对其进行单独配置。

这类功能的实际价值在很大程度上取决于大家运行的实际作业类型。如果各位主要使用静态堆栈，那么上述功能基本发挥不出什么优势。但如果大家需要经常大规模构建或者移除虚拟机系统，那么自动化配置能力就会变得非常关键。相信随着此类支持功能的不断涌现，需要面对大数据处理任务的用户将成为云服务的忠实支持者。

哪种云方案最适合自己

说了这么多，我们得出的最重要的结论就是：云方案的选择绝对不是个简单而直观的问题。对于其他人而言价格最低廉的方案在我看来很可能会变得成本高企。最适合各位的带宽计费方式对我来说也可能非常昂贵。基准测试结果纷繁复杂，数据存储成本也各不相同。我们每一个人都需要将注意力集中在这些系统身上，花时间认真进行数字比对并在制定决策之前进行大量实际测试。

但这也正是乐趣的一部分。在庞大服务器规模的复杂集成之下，各类云方案的表面运行效果可能都很顺畅;不过真正重要的是服务供应商采取怎样的实际手段解决各类问题并向用户开放选择不同架构的权利。时至今日，这些选项正变得愈发透明也更易于实现，作为用户的我们也不必再受到备份机制与机架容量的困扰。但这一切都需要用时间来体察——在经过几个月的尝试之后，我发现自己的云探索之路还远远没有走到尽头。