from：http://blog.sciencenet.cn/home.php?mod=space&uid=449420&do=blog&id=483860
【原题】Above the Clouds: A Berkeley View of Cloud Computing
【译题】 云之上：伯克利对云计算的一个观点
【作者】Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz,
Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei Zaharia
(Comments should be addressed to abovetheclouds@cs.berkeley.edu)
UC Berkeley Reliable Adaptive Distributed Systems Laboratory
http://radlab.cs.berkeley.edu/
February 10, 2009
关键字：云计算，效用计算， 因特网数据中心， 分布系统的经济学
1 执行总结（Executive Summary）
云计算，这个多年以来关于“计算作为公共设施（computing as a utility）”的一个梦想，有改变IT工业中的大部分之潜能，让软件作为一种服务更加的有魅力，并塑造了IT硬件的设计以及购买的方式。有关于英特网服务的创新想法的开发者无需再在硬件上花费大量资本支出以部署其服务或者是操作它的人力费用。他们无需关住一个过度供给（overprovisioning ）的“其流行程度不能因应他们的预测”服务，否则会导致浪费代价高昂的资源，或者对一个变得流行的服务关注不够（underprovisioning ），从而遗失潜在的客户和税收（revenue）。而且，那些拥有大量面向批处理任务的公司只要他们的程序是可扩展的，就可以立即得到结果，因为1小时内使用1000台服务器的消耗不比“使用1台服务器跑上1000小时”多。这种资源的弹性，对大型扩展无需额外动作（without paying a premium for large scale），在IT的历史中是前所未有的。
云计算既指“在英特网与硬件上作为服务传送的应用（the applications delivered as services over the Internet and the hardware）”，也指提供这种服务的数据中心里头系统软件。（译注：英特网和硬件是毛和皮的关系）。这些服务本身长期被认为是软件即服务（Software as a Service ,， short for SaaS）。数据中心的硬件和软件我们通称为一朵云。当一朵云以“现收现付（pay-as-you-go）”的方式实现对大众的可用时，我们就叫它是公共云；正在出售的服务就是“效用计算（Utility Computing）”。我们使用“私有云”术语来指“一商业或者其它组织的内部数据中心（internal datacenters of a business or other organization）”，对大众是不可用的。因此，云计算是软件即服务和效用计算（SaaS and Utility Computing）的总称，但不包括私有云。人们可以是SaaS的用户或者供应商，或者可以是效应计算的用户或者供应商。我们关注SaaS 供应商（云用户）以及云供应商（Cloud Providers），这较之对SaaS 用户的关注度低多了。
从硬件的观点看，在云计算中有3个全新角度。
有无限的计算资源可以随需获取的错觉，这种错觉导致了对云计算用户“就供给早作规划”需求的消解（eliminating）。
云用户对预先承诺的消解，从而允许公司开始时很小，且只有在其需求增加时去增加硬件资源。
当在短期基础上需要使用计算资源时，一种就使用计算资源的支付能力（比如，处理器以小时计，存储以天计 ），并且随需的释放它们，从而是通过“让机器和存储在它们不在有用的时候离去”值得保存的（rewarding conservation）。
我们认为“在低成本地段构建和操作极度大尺度的商用计算机数据中心”是实现云计算的关键所在（ the key necessary enabler of Cloud Computing），这是因为它们（译注：指构建在低成本地区的数据中心）能在规模经济的尺度上让“电力、网络带宽、操作、软件以及可用的硬件”的消费减少5到7个因子。这些因素，和统计多路复用（statistical multiplexing）（译注：？）融合，较之私有云增加了效用（utilization ），这意味着：云计算可以在低于“中型数据中心”的耗费之下下提供服务，同时还能取得较好的效益。
任何应用都需要一个计算模型，一个存储模型，一个通讯模型。为了获得弹性，统计多路复用是必须的（The statistical multiplexing necessary to achieve elasticity），有无限资源的幻象要求说，这些资源中每个都需要虚拟化以隐藏关于“它们是如何多路复用 的、以及如何共享”的实现。我们的关观点是所提供的不同效用计算（utility computing ）会在基于“ 提供给程序员的抽线层级，以及控制资源的层级”上作出区别。
亚马逊EC2处于这个谱线的一端。一个所谓EC2实例看上去就象是物理硬件，而且用户可以控制“从上面的kernel开始，几乎整个的软件栈（software stack）”。这种底层使得它以内在的不同于亚马逊方式提供自动扩展宕机恢复（automatic scalability and failover），那是因为相关于复制的语义以及其它的一些状态管理议题是高度依赖于应用的。在这个谱线的另一端是特定领域平台应用，类似谷歌应用引擎（Google AppEngine）（译注：谷歌应用引擎被广泛认为是一种 PaaS 层的应用）。AppEngine 排他的专注于传统网络应用（traditional web applications），强制应用结构在无状态计算层与有状态存储层 之间作出清晰的区分（ enforcing an application structure of clean separation between a stateless computation tier and a stateful storage tier）。AppEngine 的令人印象深刻的自动扩展（automatic scaling）以及高可用机制，以及对MegaStore 数据存储的所有权在AppEngine 应用中之可得，都依赖这些约束（译注：指强制应用结构作出的上述有关状态的区分）。之于Microsoft的Azure 的应用是使用.NET库写的，而且编译为公共语言运行时（Common Language Runtime），所谓CLR是一个脱离语言的管理环境。因之，Azure 在“类似AppEngine 这样的应用框架”以及“类似EC2这样的硬件虚拟机器”之间起了媒介的作用。
效用计算（Utility Computing）何时会倾向于运行一个私有云呢？第一个例子是当对服务的需求随时而变的时候（when demand for a service varies with time）。对一数据中心在峰值时的供给而言，必须在每个月中持续那么不多的几天， 比如说在其他时间不会充份利用的那些天。取而代之，云计算让一个组织可以对计算资源按小时进行支付，即便是从云供应商那里租用一个机器的每小时价格会比拥有一个的价格贵，还是潜在的会节省开支。效用计算倾向于运行一个私有云的第二个例子是当需求事先是不知道的时候（when demand is unknown in advance）。比如说，某网络启动当它变得普及的时候需要支持一个需求，这时潜在的会发生“当某些访问者离去的时候造成的”减少（a web startup will need to support a spike in demand when it becomes popular, followed potentially by a reduction once some of the visitors turn away）（译注：？）。最后，执行批处理分析的那些组织可以使用云计算的“开支相关”特性以更快的把计算完结掉：使用1000台EC2机器一小时，其花销和“使用1台机器运行1000小时”是相当的。就第一个“随时间而变的不同需求，和时间相应的收费”之网络业务例子而言，我们已经捕获了以下公式中的权衡。
用户在云上的使用时间 × （收费 － 云上的开支） ≥ 数据中心中的用户使用时间 ×（收费 － 数据中心的开支/效用） (1)
左手边的用“用户小时数”乘以“ 每用户小时的网络收入（the net revenue per user-hour）”，得出从使用云计算中的预期利润。右手边执行了相同的计算，对象是一固定容量的数据中心，包含了非峰值的工作负载之数据中心平均效用进行的因式分解。无论哪一边都是更高利润的机会代表（greater represents the opportunity for higher profit）。
以下的表一是我们的排名列表，预告了将会在节7中叙述的对云计算的增长而言的主要阻碍（critical obstacles）。前三个关注顺应了增长，接下来的5个影响到了增长， 最后两个涉及到政策和商业阻碍。和每种阻碍相伴生的是一个机遇，范围从产品开发到研究项目， 这可以克服该阻碍。
表一：快速浏览就云计算而言的前10个困难以及机遇
我们预测云计算将会增长，所以开发者应当对它重视（take it into account）。所有级别都应当关注（aim at）同一水平的虚拟机之“超单一虚机之效率的”扩展性（horizontal scalability of virtual machines ），还有几点值得关注:
应用软件应当能快速的屈伸（both scale down rapidly as well as scale up），这会是新的需求。这样的软件同样需要一个按需付费（pay-for-use）许可模型以符合云计算的需求。
软件基础架构需要知道它不再会运行在裸露的金属之上（bare metal）而是在虚机上。而且，需要知道在开始之前做大量工作（it needs to have billing built in from the beginning）。
硬件系统需要在一个容器（至少是一打机架）的尺度上设计，这应当是最小购买的大小。操作的花销符合“性能以及购买的开销”是很重要的，类似 “把内存、磁盘以及网络的空闲部分放到低能量模式（putting idle portions of the memory, disk, and network into low power mode）”会对能源作出力所能及的贡献（ rewarding energy proportionality）。处理器应当能很好的和虚机一起工作，闪存（flash memory）应当被添加到存储层次以及LAN交换器（switches ） ，而且WAN 路由器就带宽和开销而言必须得到提升。
2 云计算：一个老观念终于登场了 （An Old Idea Whose Time Has Finally Come）
云计算是一个新瓶子，装的酒还是效用计算的长久梦想(a new term for a long-held dream of computing as a utility)【参见：35】，这最近浮现为一个商业现实。云计算之于软件有类似于“铸造厂之于五金业”的影响。曾经一度，占据领导地位的硬件厂商需要一个引人的半导体或者制造设备（a captive semiconductor fabrication facility ），而且公司必须足够的大，得以从经济上能承担构造与操作它。然而，加工设备（processing equipment ）在每一新生代技术出现时都会价格翻番。一半导体制造线今天会花费30亿美金（$3B）， 所以只有少部分（a handful of）主要的商业公司， 有非常高价的芯片，比如Intel和Samsung，还可能拥有以及操作它们自己的制造线。这激发了为别人制作芯片的半导体生产厂商之浮现 ，比如台湾半导体制造业公司（TSMC）。铸造厂使得无晶元（fab-less） 半导体芯片厂商的价值是革新性的芯片设计：一个类似 nVidia 这样的公司在芯片业中能立于不败，而无需资本，操作开支，以及和拥有最先进的（state-of-the-art）制造线相伴生的风险 。相反的，有生产线的公司可以对它们在“许多无晶元工厂的产品”上的使用作时分多路复用（time-multiplex ）， 降低了没有足够的成功产品以对摊销操作支出的风险。类似的，规模经济的优势（the advantages of the economy of scale ）以及统计多路复用（statistical multiplexing）可能最终会衍生出少量的云计算供应商，它们可以对其大型数据中心在“更少有数据中心特性的公司”的产品上之支出作摊销。
云计算已经在【参见10 云计算与云网络】中被讨论过了，写在博客中（blogged about）【参见：13 ， 25】，写在【参见 15，37，38】而且作为”研习会（workshops）， 会议（conferences），甚至是杂志”的主题。即便如此， 关于“它是什么、什么时候有用”仍然众说纷纭，这引发了甲骨文的CEO倒苦水道：
关于云计算有趣的事情是，我们已经重新定义了云计算以把我们已近做的所有事都包含进来。. . . 我并不理解在云计算的指引下我们已做的，比如改变我们的广告用词，会有何不同。
Larry Ellison，摘自华尔街日报，9月 26号 ，2008
这些论述（译注：指在报纸、杂志、会议上的论述）得到了惠普（Hewlett-Packard）的欧洲软件销售部的副董的更温和的回应：有许多人在赶云的噱头（are jumping on），但我还没有听说有两个人对它说过相同的话。关于云有许多定义（译注：如今美国已经有了一个标准了，参见这里 译者漏见：不慕虚名而处实祸）。
Andy Isherwood， ZDnet 新闻，12月11号，2008
Richard Stallman，以他主张自由软件而闻名，他把云计算想做是用户的陷阱，如果应用以及数据实在云中管理的，用户可能变得依赖于所有权系统，其开销会初步攀升（escalate），或者有关服务的术语可能会单方面的彻底的改变：这是很愚蠢的。这样就比愚蠢更加的蠢了：都是浮云（it’s a marketing hype campaign）。有些人说这是不可避免的，而且无论何时你听到某人这样说， 这背后很可能是一些商业动作。
Richard Stallman， 摘自Guardian， 9月29号，2008
我们这篇文献的目的是沥青术语，提供简单公式以定量在云和通常的计算之间进行比较，并识别出什么是顶尖技术以及云计算的非技术上阻碍和机会。我们的观点部分是由自从2005年在UC Berkeley RAD实验室中的工作塑造的，部分是由 自动2008年1月份后的亚马逊 Web Services塑造的，指导了我们的研究和教学。RAD 实验室的研究员是要发明技术，该技术能利用（leverages）机器学习帮助为了“扩展英特网服务”目地的数据中心自动操作。我们花了6个月做关于云计算的头脑风暴， 诞生出这篇文献试图回答以下问题：
什么是云计算，以及它和先前的范式转换（paradigm shifts） 有何不同，比如软件即服务（SaaS）？
为什么云计算胸有成竹(is poised to)的在现在起飞？而与此同时先前的努力都归于失败？
是什么造就一个云计算供应商， 以及为什么一个公司会考虑变成一个云计算供应商？
什么新机会为云计算所激发/驱使？
我们可能会如何对当前的云计算分类提供谱线， 以及技术和商业挑战的差异如何依赖于“在这个谱线中一特定的供给在哪里”？
如果有的话，什么是云计算驱动的新经济模型， 以及如何一个操作服务员才可以决定是否移到云里面去或者就待在私有数据中心里头呢？
对成功的云计算而言，什么是头10个困难？ 以及与克服这些困难相伴生的头10个机遇又是什么？
应当作出什么样的改变以因应“未来应用软件、基础设施软件”的设计， 以及符合云计算需求和机遇的硬件？
3 什么是云计算（What is Cloud Computing?）
云计算指作为服务在英特网上传送的应用，以及提供这些服务的“数据中心里头的硬件和系统软件”。这些服务本身早就被叫做是“软件即服务”(SaaS)，所以我们也这么叫好了。数据中心的硬件和软件一起被我们称之为一朵云。
当云是现收现付（pay-as-you-go） 模式投放给公众时，我们就叫做是公共云； 再卖的服务就是效用计算（Utility Computing）。当下的公共效用计算之例子包括了亚马逊的Web Services， Google AppEngine以及Microsoft Azure。我们用术语“私有云（Private Cloud）”指向指向不对公众开放的一项商业或者其它组织的内部数据中心。因此，云计算是SaaS 以及效用计算的总称，不过通常不包含私有云。我们会泛泛的使用云计算，只有在有区分的必要时才用其它术语去替换它。图一现实了人员的角色是用户或者云计算在这些层上的供应商， 而且我们会使用那些术语来帮助厘清所述。
图1：云计算的用户与供应商。SaaS 带给SaaS 的用户以及SaaS 的供应商的优势已经很好的文档化了，所以我们就关注“云计算对云供应商以及SaaS供应商/云用户的”效应。顶层可以是递归的，就是说SaaS 供应商也可以是SaaS用户。比方说，一租用地图的混合供应商（mashup provider of rental maps ）可能是Craigslist 以及谷歌地图服务的用户。
SaaS 对终端用户以及服务供应商两者的优势都为人所理解。 服务供应商能够从“极大简化的软件安装、维护以及相对与版本控制的中央控制”中得益；终端用户可以在任意时间，任意地点获取服务，共享数据以及写作更加的方便，而且安全的把他们的数据存放在基础设施中。 云计算不改变这些观点（arguments），但云计算确实给更多的应用供应商以选择，作为SaaS去部署其服务而无需提供一个数据中心：正如涌现的 半导体制造商，给芯片制造商以机会在无需拥有一个晶元（fab）时，去设计销售芯片，云计算允许部署SaaS，且随需扩展，无需构建或提供一个数据中心。类似于SaaS 如何允许用户把一些担子卸下给SaaS 供应商， SaaS 供应商现在可以卸下它的一些担子给云计算供应商。 从现在开始，我们会关注“相关于潜在 SaaS 供应商（云用户）以及云供应商的”议题，这些还较少受关注。
我们会对类似“X作为一种服务” 的术语避而不谈；我们所看到的X有“基础架构、硬件、平台”，但我们还不能够就“它们之间的精确差异是什么”在我们内部达成一致【尾注1】。 （用尾注代替了脚注。可以直接看全文结束处的notes，那里有更详细的叙述）。取而代之的是，我们在节5提供了之于效用计算的一个简单分类，关注了“程序员习惯、灵活性、 移植性”之间的权衡，这种权衡是同时从云供应商以及云用户的角度去关照的。
从硬件的观点看，云计算有三个新的角度【参见：42】：
无限计算资源随需可得的幻象，从而会消解云计算用户对供给的提前规划需求。
云用户提前承诺的消解（The elimination of an up-front commitment by Cloud users），从而允许公司的硬件开始时很少，而且只有在其需求增长时才会增加硬件资源。
在短期上按需使用多少计算资源就支付多少的能力（比如，处理器按小时计算存储器安天计算）而且按需释放， 从而通过“让机器以及存储在它们不在有用的时候离开”作出有益的回报。
我们为所有这三个之重要性辩论，从之于“技术、由云计算导致的可能的经济变更”的重要性方面入手。实际上， 过去在效用计算方面的努力归于失败，而且我们注意到在各个情形中，这三个关键特性中的一两个遗失了。比如说，Intel 在2000-2001年的计算服务需要商定一个协议而且需要长期的使用而不是每小时计。
作为一个成功的例子， 来自亚马逊的Web Services(AWS)的 弹性计算云（Elastic Compute Cloud， short for EC2）出售1.0-GHz x86 ISA “切片”，是每小时10美分， 而且一个新的切片，或者实例可以在2到5分钟内加入。亚马逊的可扩展存储服务（Scalable Storage Service，short for S3）对每月吉比特（10亿字节）的使用收取$0.12到$0.15， 附加带宽对英特网上的每吉比特移入移出AWS的数据收取$0.10到$0.15。亚马逊在下面一事上押宝：通过统计多路复用实例放在一个单独的物理盒上，那个盒子可以同时租给许多用户，这些用户通常不会在使用上互相影响（见节7）。
尽管对云计算用户（SaaS 供应商）的吸引力是显而易见的，谁将会成为一个云计算供应商，为什么？首先，要明白认识到通过“统计多路复用以及大宗采购（bulk purchasing）需要构建非常之庞大的数据中心 ”的 经济规模效应。
构建，资金准备，以及启动这样的一个设施是一个耗资巨大的工程（a hundred-million-dollar undertaking）。然而，由于 Web services 在2000年早期的明显增长， 许多大型英特网公司，包括了亚马逊，eBay，Google，Microsoft 以及其它的已经在这么做了。 同样重要的是，这些公司也需要开发可扩展软件基础架构（比如MapReduce，谷歌文件系统，BigTable，Dynamo 【参见16, 20, 14, 17】 ）以及需要发展操作的专门技术去装备它们的数据中心，以因应物理的和电子的攻击（译注：译者陋见，此事之情主速）。
因此，之于公司要成为云供应商而言的一个必要非充份条件就是（译注：有了这个条件不一定能够让公司转型的想法实现，没有这个条件，转型的想法就是在做梦），必须让现有的投资不仅仅是关注了非常大的数据中心， 也需要关心：对大规模软件基础设施以及为了运行它们所需的专门操作知识。给定了这些条件， 一系列因素可能会影响到这些公司成为云计算供应商：
砸很多的钱（Make a lot of money）。尽管每7小时才10美分看上去很少， 表2（如上所示）总结了James Hamilton的评估【参见：23】，非常大的数据中心（数万计算机）可以购买硬件、网络带宽以及能量，1/5到1/7的价格供应给中型大小（数百上千台计算机）的数据中心。而且，软件开发的固定开支，以及部署可以被摊销到许多机器上。其他人强调了价格优势提升了3到5个因子【参见 37，10】。因而，一个成功的大公司可以利用这种规模效应去提供服务，这低于了中等大小公司的支出而且还有可观的利润（make a tidy profit）。
影响了已存在的投资（Leverage existing investment）。把云计算服务加在已近存在的基础架构上，这开源节流了（provides a new revenue stream at ‘ideally’ low incremental cost）。实际上，经由 亚马逊的 CTO，Werner Vogels，许多亚马逊的 Web Services技术最初是为亚马逊的内部操作开发的【参见：42】。
保卫经营权（Defend a franchise）。当常见的服务以及公司应用涉及到云计算时， 在那些应用中已确立经营权的供应商会被激发去提供一个它们自己的私有云操作。比如，Microsoft Azure 提供了一为了“把Microsoft 公司应用的已存在客户迁移到云换进”的直接路径。
挑 战（Attack an incumbent） 一家 必须带数据中心以及软件资源的公司可能期望，在出现新生的强大力量之前（before a single “800 pound gorilla” emerges），在这个空间中去建立探头堡（译注：只就阳面而言，西方的竞争文化了得）。Google AppEngine 提供了一个到云部署的替代路径，其卖点在于“对许多可扩展性以及负载平衡特性作了自动化”，若非如此，开发者可能就不得不自己构建了。
影响到客户关系（Leverage customer relationships）。 类似IBM全球服务这样的 IT 服务组织通过它们的服务供应建立有广泛的客户关系。提供一崭新的云计算供给，这就给了客户无忧迁移路径（an anxiety-free migration path）保存了当事人对客户关系的投资。
成为一个平台（Become a platform）。Facebook首先支持可插拔应用，这对云计算是很适合的， 如我们所见， Facebook 的可插拔应用的实际上的一个基础架构供应商Joyent，就是一个云供应商。而且 Facebook的动机是打造社会网络应用，使其成为新的开发平台。
看上去在很吃惊的地点构建多个云计算（以及通常的计算）数据中心，比如Quincy，Washington (Google, Microsoft, Yahoo!, 以及其它)和San Antonio，Texas (Microsoft, US 国安局, 其它)。选择这些地域的动机是电力、空调、人力支出，购置物业的支出， 而且税收是随地域而变的，这些支出，电力以及致冷单项就可达数据中心支出的三分之一。表3（如下所示）显示了不同地域的电力支出【参见：10】。物理现象告诉我们移动光子要比移动电子来的容易；这就是说，通过光纤维缆（fiber optic cables）移动数据（ship data over fiber）较之 通过高压传输线移动电流（ship electricity）。
4 完美风暴中的云：为什么是现在而不是别的时候？（Clouds in a Perfect Storm: Why Now, Not Then?）
尽管我们认为说构建以及操作极大尺度的商业计算机数据中心是云计算的重中之重（key necessary enabler），附加的技术趋势以及新的商业模式也在使其在这个时代中成真中扮演了一个关键角色。一旦云计算步入跑道（off the ground），新的应用机会以及使用模式会被发掘出来，这些之前是无甚价值的。
4.1 新的技术趋势和商业模式（New Technology Trends and Business Models）
伴随着web2.0的爆发，有一个从“高技术个性化，高利润，高投入（high-touch, high-margin, high-commitment）”的服务到“低技术个性化，地绿润，低投入”的自服务之转移。比方说，在Web 1.0中，从陌生人而来的信用卡支付的接收就需要与支付处理服务（比如VeriSign 或者Authorize.net）定立合同；这种安排是更大的商业商业关系的一部分，这使得对个人或者是很小的生意去在线接收信用卡变得很繁琐。随着PayPal的崛起，一个独立人可以接收信用卡支付而无需合同，无需长期保证，只需要适度的现收现付（pay-as-you-go）交易金。这些服务提供的“接触”（客户支持与关系管理）级别接近于没有（is minimal to nonexistent），不过服务现在到达了个人的事实看上去让这变得不那么重要了。类似的，个人的网页现在可以使用谷歌AdSense去识别出来自广告的收入，而不是和类似DoubleClick这样的广告配置公司（ad placement company）定立关系（现在已近为谷歌所有）。那些广告可以同样好的对Wed 2.0提 供商业模式。个人可以使用亚马逊的CloudFront 去 散布Web 内容，而不是和一个类似Akamai的内容分布网络建立一个关系。
亚马逊的Web Services通过提供无需合同的现收现付计算，在2006 对此进行了投资：客户所需的全部仅仅是一张信用卡。第二个创新就是卖硬件级虚机，允许用户选择他们自己的软件栈共享相同的硬件而不会互相影响，从而降低了未来的支出。
当我们还可以从更本上看到云计算所驱使的应用新类型时，我们相信已存在的应用之诸多重要类在云计算下会变得更有竞争力，作出更多的共享。当Jim Gray 检查了2003 的技术趋势时【参见21 分布式计算的经济学】，他总结认为经济需要命令要把数据在应用的就近存放，这番话是源于：广域网支出的下降（而且仍旧保持在较高的水平上）较之其它的IT硬件支出显得很慢。尽管硬件支出自从Gray的分析之后改变了，但是他关于“损益两平点（breakeven point）” 的思想还没有过时。尽管我们把有关云计算经济学的更彻底讨论延后到节6，我们仍旧借鉴了Gray于“审视何种类型的应用代表了特别好的机会，及其是对云计算的驱动 ”的眼光。
移动交互应用（Mobile interactive applications. ）。Tim O’Reilly 认为“未来是属于实时对由用户或非人类感知器提供的信息进行反映的服务”【参见38】。这样的设备对云计算是有吸引力的，不仅仅是因为它们必须是高度可用的，而且是因为这些服务通常是依赖于大型的数据集，而这些数据集是留驻在大型数据中心里头的。这特别是联合两个或多个数据源或其它类似mashups这样服务的例子。尽管不是所有的移动设备能够100%的时间中和云相连，无连接操作的挑战已经在特定应用域得到了成功的因应【尾注2】，所以我们不把这个看作是对移动应用的显著障碍。
并行批处理（Parallel batch processing.）。尽管迄今为止（thus far）我们为了SaaS已关注于使用云计算，云计算对批处理与分析作业提供了一个独特的机会，分析太字节 terabytes 的数据节只要数小时就能完事。如果应用中有足够的数据并行，用户就可以利用云新的所谓“支出结合性（cost associativity）”：在短时期内使用数百台机器和在一大段时间上使用少数机器，其开销支出是一样的。打个比方，Peter Harkins，位于Washington 的一个高工，使用200个EC2 实例（1407服务小时）去把17481页 Hillary Clinton的旅行文件转换到更适合在WWW 上使用的形式，需要的耗时是放出这些文件后的9小时内【参见3】。类似谷歌MapReduce 【参见：16】这样的程序抽象以及其开源实现Hadoop 【参见：11】允许程序员去表达这种任务，同时隐藏了“在数百计的云计算服务上设计并行执行”的操作细节。实际上，Cloudera 【参见1】正在寻求该领域内的商业机会。再一次，借鉴一下Gray的眼光，开支/效益分析（the cost/benefit analysis）必须在“大型数据集合移动到云里面的开支”和“对数据分析的潜在加速所取得的利益”之间作出权衡（译注：不见兔子不撒鹰）。当我们稍后折回到经济模型之时，我们将推测亚马逊那部分（指，大型的公共数据集寄宿在免费上头【参见：8】）的动机，可能是减缓这种分析的成本方面，从而吸引用户购买这个数据附近的云计算周期（purchase Cloud Computing cycles near this data）。
分析的崛起（The rise of analytics.）。计算密集型批处理的一个特定案例就是商业分析（business analytics）。当大型数据库工作起初是由事务处理统摄的时候，这种需求呈平稳状态（leveling off）。现在，有理解能力的客户，供应链，购物习惯，排名以及诸如此类，增加了计算资源的共享。因此，尽管在线事务卷仍旧会慢慢的增长，决策支持却是在快速的增长， 把来自事务的数据库处理中的资源平衡转换到商业分析上去（shifting the resource balance in database processing from transactions to business analytics.）。
计算密集形桌面应用扩展（Extension of compute-intensive desktop applications.）。数学软件包Matlab 和Mathematica 的最新版本已经可以使用云计算来执行昂贵的评估了。其它桌面应用可能会类似的从无缝扩展到云中而获益。再一次，一个合理的测试是，对照“在云中进行计算的开支加上把云里云外的数据作移动的开支（the cost of computing in the Cloud plus the cost of moving data in and out of the Cloud），以及使用云所节省的时间（the time savings from using the Cloud）”。符号数学涉及了数据单元（unit of data）的大量计算，这使得其会是一个蓝海（a domain worth investigating）。一个有趣的替换模型可能会把数据保留在云中，并依赖于有足够的带宽支持适当的形象化并把反馈的GUI给到人类用户。离线图像渲染或者3D动画可能会是一个类似的例子：给定在3D场景中一个对象的紧凑描述以及光线资源的特色， 对图像的渲染就是让人局促的带高比特计算率的（a high computation-to-bytes ratio）并行任务。
地面应用（“Earthbound” applications. ）。某些应用在其它情况下对云的弹性以及并行而言，会是好的候选，这些应用可能会被“数据移动的支出， 进入或者移除云两者的本质延迟限制” 挫伤（译注：指不是好的候选了？）。比如，虽然相关于长期金融决策的分析对云和适合，不过对需要微秒级别决策的股票交易不是合了（译注：是否实时数据库可作此用？）。直到广域数据传输的开支（以及可能的延迟性）下降（见节7），这种应用对云可能不是好的候选。
5效用计算的级别（Classes of Utility Computing）
任何应用都需要一个计算模型，一个存储模型，并假设该应用分布细节甚多，一个通讯模型。所谓“统计多路复用”对达到弹性是必须的，且无限容量的幻象使得资源需要虚拟化，所以程序员无需了解它们（译注：指resources）是如何进行多路复用以及共享的细节可以。我们的观点是，不同的效用计算之供给可以在“提供给程序员的抽线级别，与资源管理级别”上作出区分。
亚马逊EC2 就处于这个谱线的一端。一个EC2 的实例看上去很像是一个物理硬件，而且用户可以控制几乎整个软件栈，从上游的kernel 起。暴露的API 是“瘦的（thin）”：少数API调用了请求以及配置了虚拟化硬件。对何种应用可以寄宿没有先入为主的限制（a priori limit）：虚拟化的低层“原始CPU周期，块设备存储， IP级别的链接”允许开发者对任何他们所想进行编码。另一方面而言，这使得其成为“对亚马逊提供自动扩展与宕机恢复而言的”内在困难，因为相关于复制件的语义以及其它状态管理问题都是高度依赖于应用的。
AWS确实提供了一些高层管理服务，包括配合EC2的多个不同管理状态服务的使用，比如SimpleDB。然而，这种供给有更高的延迟性（latency）以及非标准API，就我们所理解的，它们（译注：指那些较高级别的管理服务）不像AWS的其它部分那样有广泛的使用。
在这个谱线的另外一端是应用域，类似Google AppEngine和Force.com，SalesForce 商用软件开发平台这样的特定平台。AppEngine 排它的关注于传统网络应用，强制应用结构在“一无状态计算层和一有状态计算层”之间作清晰区分。进一步而言，AppEngine 应用期望成为基于回复的（request-reply based），同样的，关于它们于一可以使用多少CPU时间特定请求进行服务这点上，它们（译注：指AppEngine的应用）被严格的供给。AppEngine让人印象深刻的自动扩展和高可用机制，以及MegaStore的（基于BigTable）数据存储对AppEngine 应用是可得的这种所有权，都建基于这些约束。因此，AppEngine 对通用目的的计算（general-purpose computing）是不适合的。类似的，Force.com 设计成支持商业应用，以与salesforce.com 数据库竞争，无它。
Microsoft的Azure 是在这个“灵活性VS程序员便利性”谱线当中起媒介作用的中间点（an intermediate point）。Azure应用是用 .NET库写的， 并被编译成公共语言运行时（Common Language Runtime），一个独立于语言的管理环境。 该系统支持通用目的计算（general-purpose computing），而非单一类型的应用。用户可以选择语言，但是不能控制基底的操作系统或运行时。该库一定程度上提供了自动网络配置以及宕机恢复/扩展性，但是需要开发者详细的说明一些应用的属性以使得可以这样做。因此，Azure 是介于“谱线一端像是AppEngine 这样的，完全应用框架”与“谱线另外一端的像是EC2这样的，硬件虚拟机器”之间的中间物（intermediate ）。
表4 总结了这三种级别如何进行虚拟计算，存储以及网络。任意提供的扩展存储显明了：带“相较于SQL丰富度的API”之扩展存储（scalable storage with an API comparable in richness to SQL）仍旧是个开放性研究问题（见节7）。亚马逊已经开始提供寄宿在AWS上的Oracle 数据库， 不过该产品的经济学以及许可证模型使它和云计算不相契合（makes it a less natural fit for Cloud Computing）。
表4：云计算供应商的例子，以及它们各自提供的虚拟化资源（计算、存储、网络），且保证了这些资源的扩展性和高可用性。
在云计算空间中，可能会有一个模型从其它模型中胜出么？我们可以用编程语言和框架作类比。类似C、汇编这样的低级语言允许和裸体硬件作精细控制、紧密通讯，不过如果开发者是在写一个网络应用、 管理套接字的技术机制、分发请求，诸如此类就对即便是一个好的库而言也是繁重累赘的了。另一方面而言，类似Ruby on Rails这样的高级框架使得这些技术机制对程序员是透明的（invisible），仅仅在“如果应用很容易和请求/回复结构，以及Rails提供的抽象相契合 ”时候是有用的；有任何的偏离话，最好需要跳到框架里面去看个究竟，但对编码可能是很难的。Ruby 开发者没有对C之于某些任务的优越性之合理反驳，反之亦然。相应的，我们相信不同的任务会导致对效用计算的不同级别的需求。
继续语言的类比，正如高层语言可以由低层语言来实现一般，高度管理的云平台可以寄宿在更少管理的云平台之上。打个比方，AppEngine 可以寄宿在Azure 或者EC2上头；Azure 可以寄宿在EC2上头。当然，AppEngine 和Azure 各自都提供了专利所有权特性（AppEngine的扩展性，宕机恢复以及MegaStore 数据存储），或者大且复杂的API (Azure的.NET库)，实现上没有免费午餐，所以任何试图对AppEngine 或Azure 的克隆，会需要再次实现这些专利权中的特性，或者API中的，这是一个令人敬畏的挑战。
6 云计算经济学（Cloud Computing Economics）
在这一节我们来观察一下云计算的经济模型：
在决定是否把某个服务寄宿到云里头就长期而言会有意义时，我们认为云计算所激发的细粒度经济模型使得决策权衡更加的不固定，尤其是云服务在转移风险时所提供的弹性（elasticity）。
同样的，尽管硬件资源的支出持续的下降， 但是下降的速率是各异的；比方说，计算与存储的支出较之WAN 的支出下降的更快。云计算可以跟踪这种变化，并潜在的把它们转移到用户上去，这比构建自己的数据中心更加的有效，导致了和实际资源使用更匹配的支出。
在决策是否把已存在的服务搬到云里头时，还必须检查期望的平均值和峰值资源的利用，特别是于资源请求有高度可变的峰值这样的应用之时；真实世界中所购设备的使用之实际限制；以及基于所考虑的云环境类型之各异的作花费 。
6.1 弹性：转移风险（Elasticity: Shifting the Risk）
尽管云计算的经济吸引力常常被描绘为“把资本开支转化为操作开支（CapEx 到 OpEx）”，我们相信“现收现付（pay as you go）”这个短语对购买者而言，是更直接的捕获了经济利益的。通过云计算的小时购买可以非统一（non-uniformly）式的及时被散发（比如，今天使用了100个服务－小时，明天一点也不用，仍旧对你所使用的进行支出）；在网络社区，这种卖带宽方式早就被称为基于使用的价格（usage-based pricin）【尾注3】。而且，预付资本开支的缺位可以使得资本重新定位到核型商业投资（the absence of upfront capital expense allows capital to be redirected to core business investment）。
因此，即便Amazon的现收现付价格（打比方）可能比对“相同周期的一个相当服务”的购买以及贬值更加贵，我们认为“极端重要的云计算的弹性经济利益和转换风险”其成本更有价值 （the cost is outweighed by the extremely important Cloud Computing economic benefits of elasticity and transference of risk），特别是“过度供给overprovisioning （即未充份利用 underutilization）和未充份供给underprovisioning （ 饱和 saturation）”的风险。
我们开始探讨所谓“弹性（elasticity）”。关键的观察就是云计算在精细粒度上添加或移除资源的能力（EC2一次一个服务），且提前了数分钟而非数周，允许将资源更近的匹配到工作负载（matching resources to workload much more closely）。真实世界的资产服务利用在数据中心里头范围是从5% to 20%【参见37，38】。这听上去低的让人震惊，但是它和“对许多服务而言，峰值工作负载超过了平均2到10个因子”的观察是一致的。（译注：指峰值负载是平时的2到10倍倍，由于没有实现多路复用的思想，所以数据中心里头的机器配置是按照峰值时来设置的，该情况下即有资产服务利用率是50%到10%）。很少有用户的提供会故意少于期望峰值，就是说它们必须对峰值进行提供，并允许资源在非峰值时间中空闲。差异越显著，浪费也就越多。一简单的例子显示说“弹性是怎样减少这种浪费的（how elasticity allows reducing this waste）”并因之可以从现收现付式vs.购买式的每服务小时的潜在更高开支中 得到更多的补偿(more than compensate for the potentially higher cost per server-hour of paying-as-you-go vs. buying.)。
—————————————————————————————————
例子：弹性。假设我们的服务有一个每日可预测的需求，其峰值为中午需要500 台服务器，但是在午夜就只需要100台服务器了，入图2(a)所示。整个一天中的平均利用是300台服务器，整个一天中的实际利用率是300 × 24 = 7200个服务小时；但是由于我们必须对峰值的500台服务器进行供给，所以我们支付了500 × 24 = 12000个服务小时，是我们所需多了1.7倍。因此，只要对服务小时的现收现付开支持续3年以上【尾注4】，就会抵得上购买服务器的支出的1.7倍，我们可以使用效用计算来节省开支。
——————————————————————————————————
实际上，以上的例子低估了弹性的收益，因为于简单的日间模式而言，大多并非琐碎的服务同样经历了季节性的或者其它周期各异的需求（比如，电子商务峰值是在12月，照片共享网站的峰值是在假期以后）以及其它由于未预料到的外部事件引发的需求井喷（如，新闻事件）。由于需要数周来对新设备上架（rack），唯一应对这种峰值的方式是提前供给。我们早就看到即便如果服务操作者提前正确的预知了峰值，资本仍旧被浪费了，如果他们高估了他们所供给的那个峰值话，情况就更糟了。
他们也可能低估了峰值（图2(b)），即不管怎样，偶然的关闭了超出的用户。尽管高估的财政效应很容易测量，那些低估还很难衡量但仍是潜在相当严重的：不但拒绝了客户生成0收益，他们可能永不会回应这种贫乏的服务了。图2（c）就捕获了这种行为：用户会放弃供给以下的服务，直到峰值用户装载与数据中心的可用容量相等，在该点处用户再一次收到了可接受服务，但是潜在的用户少了。
图2：(a)即便是峰值装载可以正确的预测，若没有弹性（elasticity），我们会在非峰值期间浪费资源（阴影区域）。（b）供给以下的情形1：来自用户的潜在收益（阴影区域）牺牲掉了。(c)供给以下的情形2：一些用户在经历了贫乏的服务后，永远的丢弃了站点；这种损耗以及可能的负面压力导致收入流的一部分永远流逝。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
例子：转换风险。假设“由于供给以下（underprovisioning）而受到了贫乏的服务”用户中只有10%是永久流逝了，即，用户会仍旧是有更好体验的经常访问者。站点最初的提供的把握是期望峰值40万用户（每个服务1000用户×400个服务），但是在第一个小时内有未曾预料的50万用户的压力。当然这10万用户可能会被服务拒绝或者收到了恶劣的服务，由我们的假设，有1万用户永久的丢失了，就是仍有39万用户保持活跃。下一个小时看到了25万新的独特用户这头1万做的很好，但是仍旧是有24万用户的大小超过了容量。结果就是有24万的用户丢失，留下37.6万（译注：？）的永久用户。如果这个模式继续下去的话，在lg500000 或19小时之后，新用户的数量会触碰到0且站点容量会处于平稳状态。很明显，服务操作者在逝去的19小时中的收集，少于为了维持稳定收入流的40万用户，然而，再一次显示了未充份利用的论据 － 更不肖说来自不满用户之坏名声了。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
这样的场景真的会在实际中发生么？当Animoto 【参见4】通过Facebook使得其服务可用，它经历了一次需求的激增，导致了其服务器在3天内从50台增加到3500台。即便每台服务器的平均利用率很低，没人可以预见到，资源需求会在3天内以每12小时突然之间翻番。当峰值减弱下来后，通信量就降低到明显低于峰值的级别了。所以在这个真实世界的例子中，按比例扩大的弹性（scale-up elasticity ）不是一个成本优化而是一个操作需求，而且，按比例来缩小的弹性（scale-down elasticity）允许不变的支出更接近的匹配不变的工作量。
弹性于已建立的公司而言是一个好的开始，对开始也是这样。比方说，Target，美国的第二大零售商，对Target.com站点就使用了AWS 。当其它的零售商有多个性能问题而且在黑色星期五间歇性的不可用（10月28日），Target的和亚马逊的站点仅仅慢了50%【尾注5】。类似的，Salesforce.com 寄宿的客户范围是从2座到4万+座。
即使更温和的案例都足以显明云计算的这个关键效益：错误评估工作负载的风险从服务操作者那里转移到云供应商那里(shifted from the service operator to the cloud vendor)。云供应商可能就这种假设的风险收取额外费用（思考相较于3年期购买开销的一个每服务小时的更高使用开销）。我们建议用以下的简单公式来概括所有以上的情形。我们假设云计算供应商才用的是基于使用的价格（usage-based pricing），即其中的客户是按比例的就时间量以及他们所使用的资源量作支付。同时有一些赞成为基础架构服务的更加精密复杂价格模型【参见28，6，40】，我们相信基于使用的价格（usagebased pricing）会持续下去，因为它更简单易懂，类似电力以及燃气公司对其的广泛使用就是明证。类似的，我们假设用户的税收和用户时间的总数量成比例。这种假设和“支持广告的税收模型（the ad-supported revenue model）”相一致，该模型中所服务的广告数量大概是和终端用户在该服务上的总访问时间成比例的。
云端的用户使用时间 × (税收 － 云端的成本) ≥数据中心的用户时间 ×（税收 － 数据中心的成本/效用）（2）
左手边是“通过用户小时数”乘上“每用户小时税收收益（税收被认为是每用户小时减去对每用户小时的云计算成本支出）”。右手边执行的只是对一个固定容量的数据中心而言的相同计算，把包括了非峰值的工作负载的平均利用率作为因子（by factoring in the average utilization）。无论哪一边都代表了更高利润的机会。
很显然，若利用率（Utilization ） = 1.0（数据中心的设备100%的被利用），那么公式的两边看上去就是一样的。不过，基础队列理论（basic queueing theory）告诉我们，当利用率（utilization）接近1.0时,系统反馈时间也会接近无限长。在实践中，一个数据中心（没有妥协的服务 compromising service）可用的容量典型的会是0.6到0.8【尾注6】。鉴于一数据中心必定必然要过渡供给（overprovision），以对这种“经常费用（overhead）”负责，云供应商可以简单的把这个作为因子计入云成本中。这种“经常费用 overhead ”能解释为什么我们使用“现收现付 pay-as-you-go”这个短语，而不是就效用计算而言的租用或租赁 rent or lease。后者短语包含了这种不可用的经常费用，而前者则不包含。因此，即便你租用一个100 兆比特每秒的英特网链接，你实际上可能只是使用了60到80 Mbits/s。）。
该公式显明了我们所有例子中的常用元素是：一种控制用于该操作服务的每用户小时的成本之能力（the ability to control the cost per userhour of operating the service ）。在例子1中，不带弹性的每用户小时成本很高，是因为资源的高闲置成本，和同样数量的用户时间（because of resources sitting idle—higher costs but same number of user-hours）。同样的事，在对需求的高估导致了对工作量的供给并没有实际产出时，会发生。在例子2中，作为低估了峰值的结果，每用户小时增加了成本，且不得不关掉用户：由于某些原因这些用户再也不会回来了，固定成本仍保持一致，但现在是在少数的用户小时上进行摊销了（the fixed costs stay the same but are now amortized over fewer user-hours）。这，在直面任何工作负载的并非不重要的突发性之时，揭示了“购买”模型的本质限制 。
最后，对云计算用户而言还有两项收益，这是缘于能够“对其资源的使用进行基于小时去扩展而不是基于年的这种”改变。所以这么说是因为首先，意料之外的缩减（临时为充分利用的设备之处理），比方说由于经济减速或者反过来说由于软件效率的增速，常常带来是经济上的恶果。随着3年期折旧，一个$2,100 的服务在表示了1年操作的$1,400所谓“罚金（penalty）”后，将退役。云计算消除了这种罚金（penalty）。
所以这么说的第二个原因是，技术趋势（technology trends）显示说超过了一些购买的设备之可用生命周期以后，硬件成本会下降而且新的硬件与软件技术会变得可用。那些在节3中描述的已经享用着以规模经济购买能源的云供应商，可以潜在的把这些节省传递到它们的用户（potentially pass on some of these savings to their customers）。实际上，AWS 原始存储的重度用户的成本在过去2.5年中下降了20% ，而且网络成本下降了50% ，而且在1年以内新添加了9个服务或AWS的新特性【尾注7】。如果新的技术或者价格计划对云供应商那个变的可得话，已经存在的应用和客户可以潜在的从它们中直接获益，而不涉及资本开支。在少于2年内，亚马逊的Web Services 将不同类型的计算机服务器（“实例”instances）的数量从1增加到5，且在1年内他们添加了7个新的基础架构服务以及两个新的操作支持选项【尾注8】。
6.2 成本比较：我应该搬到云里面去么（Comparing Costs: Should I Move to the Cloud?）
鉴于前一节试图去量化“比如弹性这样的，特定云计算收益所能带来的经济价值”，这一节就处理一个相同重要性的但是更大的问题：把我的已存数据中心寄宿服务搬到云里头去，或者把它保存在数据中心里头，经济么？
表5把Gray在2003年中的成本数据【参见21 分布式计算的经济学】更新到2008年，使得我们可以跟踪在最近5年中（译注：作文于2009年）对云计算而言的核心技术改变率。要注意，如所期望，广域网的成本在最近的5年中提高了，少于3倍（by less than a factor of 3）。当计算成本在过去的5年中提高了时，使用额外计算能源的能力（the ability to use the extra computing power ）基于这样的假设：程序可以利用计算机中所有的双核心套接字（programs can utilize all the cores on both sockets in the computer）（译注：什么假设？）。该假设大概对“许多虚机服务于成千上万的客户”的效用计算而言会更真一点，而不是驻留在单一公司的数据中心里头之程序。
表5：我们更新了Gray的2003年计算资源成本到2008，对$1在2003 vs. 2008可以买什么作了规范化，并比较了2008 的价格计算的AWS 上 $1价值的资源之支出成本。
为了帮助运算（calculations），Gray 对1美元在2003年中的购买力作了估算。表5显示了他的数字VS 2008以及和 EC2/S3收费相对照。初次一瞥，看上去如果用于购买2008年的硬件而不是在2003年购买相同的硬件话， 一美元会买到更多。不过，这种简单的分析掩盖了（gloss over ）多个重要的因素。
每一种资源的支付都是独立的。大多数应用并不会对计算、存储以及网络带宽进行等量的使用；有些是CPU饱和的，其它是网络饱和的，诸如此类，可能在某些资源饱和的情况下另一些却未作充份利用。现收现付（Pay-as-you-go）云计算可以分别就资源类型各异的应用进行收费，减少未充份利用带来的浪费。当精确的节省依赖于应用时，假设CPU 只使用了50%，与此同时网络能力饱和；那么在一个数据中心里你相应的就要支付实际被使用的CPU周期的翻番的价格。所以较之这样说“支出$2.56去租用只值 $1的CPU”，更准确的说法是支出$2.56去租用值$2的CPU。作为一个边注（a side note），针对广域网，AWS价格就“为相同带宽进行支付的中型公司”而言，更具竞争力。
能源，致冷以及物理设施成本。能源、致冷成本，以及建筑的分期偿还成本到目前位置还没有出现在我们的简单分析之中。Hamilton 评估了CPU、存储和带宽的成本，当这些成本在建筑的生命周期中被摊销时大概会翻番【参见23，26】。采用该评估，在2008年购买128 小时的CPU之真实成本是$2而非$1，相较于EC2上的$2.56。类似的，10 GB磁盘空间的成本是$2而非$1，相较于S3上每月的$1.20–$1.50。最后，S3 为了所谓的“性能和持久性（urability and performance）”，而在实际上把数据复制了3次，并还会就性能方面有高需求的数据作进一步的复制。这就意味着当购买时成本是$6.00，相较于S3上的每个月$1.20到$1.50。
操作成本。今天，硬件操作成本非常的低 －重新启动服务很容易么（比方说，IP可寻址移动式插座 addressable power strips， 独立于带控制器 separate out of sband controller，诸如此类）。最低限度受训的员工就可以把“机架级或服务器级”的坏掉组件替换掉或者。一方面，由于效用计算使用了虚拟机而取代了物理机器，从云用户的观点来看，这些任务被转移到云供应商那里去了。就另一方面而言，基于虚拟化的级别，大多数软件管理成本还是存在的－更新，打补丁，诸如此类。返回到节5所讨论的“托管vs.非托管”，我们相信对托管环境（比如，Microsoft Azure, Google AppEngine, Force.com）而言，成本较“硬件级别的效用计算（比如，亚马逊EC2）”更加的低，不过看上去还很难对这些收益进行一种大家都能同意的量化。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
例子：移动到云里头。假设有一个生物实验室对每个潮湿实验室试验生成了500GB的新数据（Suppose a biology lab creates 500 GB of new data for every wet lab experiment）。 以一个EC2 实例的速度运行的一台计算机对处理这些新数，以每GB计据耗费2小时。实验室在本地有相当于20个实例，所以评估该试验的时间就是500×2/20，就是50小时。他们可以“在AWS中的1000个实例中，以一个小时处理它”。处理一个试验的成本正是1000×$0:10，即$100的计算，还有 500×$0:10即$50的网络传输费用。到目前位为止，一切OK。他们衡量了从实验室到AWS的传输速率，是20兆比特每秒【参见19】。这种传输时间是 (500GB × 1000MB/GB × 8bits/Byte)/20Mbits/sec = 4,000,000 / 20 = 200,000秒，就是长于55个小时。因此，在本地会费50小时，而在AWS上会费55+1就是56小时，所以他们不会移动到云上去（译注：本例中应该只考虑单一次试验数据使用情形）（下一节对如何克服传输延迟障碍提供了一个机会）。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
7. 云计算的前10个障碍与机遇（Top 10 Obstacles and Opportunities for Cloud Computing）
在这一节里，我们提供了一个关于相伴云计算而生的障碍之级别列表。各有一个机会和每个障碍相伴生，这种机会是我们对如何克服该障碍的见解，其范围从直接产品开发到主要的研究项目。表6总结了头10个障碍与其机遇。头三个是关于采用云计算的技术障碍，接下来的5个是对一旦采用后的云计算增长而言的技术障碍，最后两个是对采用云计算而言的政策与商业上的障碍。
表6：采用并培植云计算的前10个困难以及机遇（译注：与表一同）
第一个障碍：服务可用性（Availability of a Service ）
组织担心效用计算服务是否足够可用，这部分的引起了对云计算的担忧。有点讽刺的反过来说，存在的SaaS 产品在这方面设定了一个高标准。谷歌查询能有效的接入英特网（the dial tone of the Internet）：如果某人去谷歌作查询而且不可得，他们会认为英特网断掉了。用户对新的服务期望相似的可用性，这很难做到。表7显示了在2008年中“亚马逊简单存储服务（Simple Storage Service，short for S3），AppEngine 以及Gmail” 所记录的运行中断，并对这种运行中断作了解释。要注意尽管由于这种运行中断的负面公众影响，仍旧有少数的IT基础架构公司表现良好。
表7：AWS, AppEngine, Gmail的运行中断
就像大型的英特网服务供应商使用多个网络供应商一样，所以一个单独公司的失效不会把它们从空中摔下来，我们相信之于“非常高可用性的（very high availability ）”的唯一貌似可行解决方案是：多个云计算供应商。高可用性计算社区坚信“不存在单独资源失效（no single source of failure），”不过有单一公司进行的一个云计算服务的管理实际上就是“一单点失效（a single point of failure）”。即便公司在不通地理域上分布有多个数据中心，使用了不通的网络供应商，它仍可能有公共软件基础架构以及账户系统（common software infrastructure and accounting systems），或甚至公司离开了生意（the company may even go out of business）。若非对这种情形有一个商业上可持续的策略的话，大型客户对迁移到云计算会不大情愿。我们认为对独立软件栈（independent software stacks）而言最好的机会是：由不通的公司去供应，因为让一个公司去同时满足“以软件依赖的名义生成以及维护两个栈（creating and maintain two stacks in the name of software dependability）”是困难的。
另一个可用性障碍就是分布式服务拒绝（Distributed Denial of Service short for DDoS）攻击。犯罪威胁“通过使它们的服务不可用”切断SaaS 供应商的输入 ，敲诈$10,000 到 $50,000 以防止发动DDoS攻击。这种攻击典型的使用了大型的所谓“僵尸网络（botnets）”，在黑市上以$0.03的单价租用所谓“僵尸（模仿伪币使用者）”一周【参见36】。效用技术给SaaS供应商提供了一个机会通过“快速扩大（quick scale-up）”去因应DDoS攻击。假设一EC2 实例可以控制500个bots，且发起了一个生成“额外1GB每秒的伪网络带宽，和50万个bots（an extra 1 GB/second of bogus network bandwidth ） ”的攻击。每个bot是$0.03，这种类型的攻击对攻击者而言最初的投入是$15000。（译注：战争是政治的延续，政治是经济的延续，在器物层面上，经济有赖于工程技术，工程有赖于科学）。以AWS的当前价格，这种攻击会使受害者对网络带宽支付额外的$360/每小时，以及额外的$100/每小时（1000个实例）的计算。这种攻击因此会持续32小时，因为这样潜在受害者的成本就会比勒索者的高（blackmailer）。一所谓“僵尸网络攻击”持续这么久是很困难的，那是因为攻击持续的时间越长，要识别出并对它反击就越是容易，且攻击用的bots不能立即对同一个供应商的其它攻击作重复使用。当有了弹性（elasticity）后，云计算就把这种攻击目标从SaaS供应商转嫁到效用计算供应商头上去了，云计算供应商可以更好的消化它（译注：指攻击的目标）并且（如我们在节3所述）很可能让已存在的对DDoS之防护作为核型能力。
第二个障碍：数据锁入（Data Lock-In）
软件栈已经发展出了介于平台之间的互操作性，不过对云计算本身而言的APIs仍旧本质上是专有的，或者至少不是活跃标准关注的主题。因此，客户不容易就“从一处到另一处（from one site to run on another）”的数据以及程序作萃取 。关注到从云里面萃取数据的困难性（Concern about the difficult of extracting data from thecloud ），这阻碍了某些组织采用云计算。客户锁入（lock-in）可能会对云计算供应商有吸引力，不过云计算用户在价格增长面前是很脆弱的（象Stallman 所警告的那样），在可靠性方面，或者即便离开生意的供应商而言，亦然。
比如，一在线存储服务叫做“连上（The Linkup）”由于损失了45%的用户数据而在2008年8月8日关门了【参见12】。“连上”，其又是基于叫做Nirvanix 的在线存储服务来存储客户数据的，所以现在就出现了这两家公司互相指责（finger pointing）为什么客户数据会丢失了。与此同时，“连上”的2万用户被告知服务不再可用，并被迫使试试其它的服务站点。
很明显的解决方案就是把 APIs作标准化，从而一个SaaS 开发者可以把数据与服务部署到诸云计算供应商里头去，从而单一公司的失效不会l连累到把客户的所有数据都给毁了。明显的担忧是这将导致云计算价格的所谓“竞次（race-to-the-bottom）”（译注：一种经济学上定义的恶性竞争），肯定会让云计算供应商惨淡经营（flatten the profits ）。我们对这种担忧提供两个论据。
这种担忧的第一个论据是，一项服务的质量是和价格相关的，所以客户不可能转到最低费用的服务上去。有些英特网服务供应商如今所以会付出比比人多10倍的开支，那是因为它们是更可靠的，并对提升可用性（usability）提供了额外的服务。
这种担忧的第二个论据是，除了缓解了数据锁入的关注外（in addition to mitigating data lock-in concerns），APIs 的标准化使得新的“相同的软件体系架构同时可用于私有云与公有云”的使用模型成为可能【尾注9】。这种操作使得所谓“涌计算（Surge Computing）”成为可能，这之中公有云用于捕获额外的，由于临时繁重工作量， 不容易在数据中心（或者私有云）中去运行的任务 【尾注10】。
第三个障碍：数据机密性与可审核性（Data Confidentiality and Auditability）Data Confidentiality and Auditability
“我的敏感公司数据永远不会到云里头去”这作为轶事我们已经听过很多次了。当前的云所提供的从本质上讲是公共（而非私有）网络，其暴露的系统更容易遭到攻击。从“Sarbanes-Oxley，以及健康人与类服务的健康保险流通与责任法案（Health Insurance Portability and Accountability Act short for HIPAA） 条例之，对必需被移到云里头的法人数据必需要提供”的意义上来说，对可审核性亦有需求。
我们相信在构建云计算环境中没有什么本质上的障碍 ，就像绝大部分的内部IT环境一样的安全（as secure as the vast majority of in-house IT environments），而且这些困难中有许多可以立即克服，只要很好的理解了类似“加密存储（encrypted storage），虚拟局域网，和网络中间件 middleboxes （比如防火墙、数据包过滤器）”这样的技术话，打个比方，在把数据放到云里头之前对其加密，这可能会在本地数据中心里的比非加密数据更加的安全；TC3是一家“需要获取敏感病人的记录”的医疗保健公司，当把它们和HIPAA相符的应用搬到AWS中时【参见2】，TC3声称：这种方法在公司成功的被运用过 。
类似的，可审核性（auditability ）可以被作为虚拟化的客户OS（或虚拟化应用环境）可抵达之上的附加层，提供了比那些内建于应用本身( those built into the applications themselves)更安全的工具，并把软件责任相关的机密性与可审核性中心化到单一逻辑层次中（centralizing the software responsibilities related to confidentiality and auditability into a single logical layer.）。这种新特性强化了云计算之于“把我们的眼球从特定硬件转到被提供的虚拟容量上来（changing our focus from specific hardware to the virtualized capabilities being provided）”的观点。
相关的一个考虑就是许多国家都有“需要SaaS 供应商把客户数据与有版权的资料保持在该国范围内”的法律。类似的，一些生意业务不可能有国家的实力以通过法院系统获取其数据；比方说，考虑到美国的爱国者法案（USA PATRIOT Act），一欧洲的顾客可能会关心SaaS在美国使用情况 。
云计算供“SaaS 用户以及其供应商”以放置其存储的极大自由。比方说，亚马逊提供了S3服务，物理地点是在美国和欧洲，允许供应商如其所好的进行放置。在AWS 地区，一个简单的配置变更，避免了需要找到海外宿主供应商（a hosting provider overseas）并进而与其协商。
第四个障碍：数据传输瓶颈 （Data Transfer Bottlenecks）
应用将会继续变得更关注数据（data-intensive）。如果我们假设应用会被从云的范围上撕裂出来一部分的话，这可能会使数据放置以及运输复杂问。以每太字节（terabyte）的传输是$100到$150算，这些花费会很快飙升，这使得数据传输的成本立即成为一个重要的议题。云用户和云供应商，如果他们想最小化成本的话，就必需要对“涉及到放置，以及系统中每一级别的通信量”进行思考。这种推理可以从亚马逊最近开发的Cloudfront 服务中看得出来。
一个克服英特网高成本传输的机会是所谓“运送磁盘（ship disks）”。Jim Gray发现传送大量数据的最便宜的方式就是“把磁盘带走（physically send disks）”，或者就是通过通宵递送服务（via overnight delivery services ）“把计整个算机带走”【参见22】。尽管没有来自磁盘供应商或计算机的确保说“你可以这样来传送数据”，但是他在400多次的尝试中只经历了1次失败（而且即便是这次失效，也可以通过“运送类似RAID方式中的有冗余数据之额外磁盘”来降低的）。
为了满足该论争（To quantify the argument），假设说我们想要从加大伯克利分校运输10TB的数据到西雅图和华盛顿的亚马逊。Garfinkel 从3个站点测量了S3的带宽，并发现平均写带宽是5到18兆每秒【参见19】。假设我们在一个WAN 连接之上获得了20兆比特/秒的速率。这将会耗费掉 10 * 1012 Bytes / (20 * 106 bits/second) = (8 * 1013)=(2 * 107)= 4,000,000秒，也就是多于45天用于传输这些数据。当亚马逊收到这些数据的时候，也会对你收取$1000的网络传输费。
如果我们用通过通宵运送（overnight shipping）方式传输10个1 TB的磁盘来代替的话，那么不消一天就可以传送10TB数据，成本大约是$400，其实际带宽大约是1500兆比特每秒【尾注11】。因而，“之于云计算的网飞（Netflix ）”可以把大块转移到云中的成本减半计入（halve costs of bulk transfers into the cloud），但更重要的是它把延迟性减缓到45分之一（reduce latency by a factor of 45.）。
回忆一下节6中生物实验室的例子，写一个磁盘会花掉1小时，快递（FedEx）一个磁盘是16小时，读取500GB的数据花费约1小时，然后用1小时处理它。因此，处理该试验所用总时间是20小时而不是50小时，而且其成本大约是每个试验$200，这样他们就终究决定要移动到云里头去了。由于磁盘容量以及每十亿字节（gigabyte）的成本增长的远较“网络性能的成本”为快，“通过表5可知在过去5年中一个增长了10倍，另一个只增长了还不到3倍（10X vs. less than 3X ）”，所以对大型数据转移的快递磁盘服务会变得一年年的更有吸引力。
另一个克服英特网高成本传输的机会就是找出“把数据保持在云理由是有吸引力的”理由，无论出于什么原因，一旦数据待在云里头了，这就不会再是一个瓶颈，并且会使得“购买云计算周期”的新服务成为可能。亚马逊最近开始把免费大型公有数据集（比如美国人口普查数据 US Census data）寄宿到S3上去；由于在S3 和EC2之间传输数据没有什么开销，这些数据集可能会“吸引”EC2 周期。另一个例子就是，考虑非现场（off-site）归档和备份服务。由于类似Amazon, Google, 和 Microsoft这样的公司相对于它们收到的数据，很可能会发送的更多，准许进入的带宽成本（the cost of ingress bandwidth）可能会小很多。因此，比方说，如果每周完全备份通过移动物理磁盘的方式来移动，且压缩后的每日增量备份（compressed daily incremental backups）是通过网络来传送的，云计算就可能能够提供一个能复旦的起的场外（off-premise）备份服务。一旦备份数据进入到云里头了，成为可能的那些新服务会导致卖出更多的云计算周期，譬如你所有的归档数据之可查询目录，或者在你所有的归档相片上执行图像识别，以将它们通过谁出现在每个相片上将它们分组【尾注12】。
第三个克服英特网高成本传输的更加激进的机会，试图更快的降低WAN带宽的开销。一个评估是WAN 带宽的三分之二的开销是花在了高端路由器上，与此同时，只有三分之一是花在了光纤成本上了【参见27】。研究者正在开发更来自带中心控制商业组件的简单路由（simpler routers built from commodity components with centralized control），作为对 高端分布式路由（high-end distributed routers）的低成本替代【参见33】。如果这样的技术被WAN供应商采用了话，我们将会看到WAN 的成本会比历史上所显示出来的下降的快很多。
对“WAN 带宽成为一个瓶颈”还有些话要说，云中的网络技术也可能会是一个性能瓶颈（intra-cloud networking technology may be a performance bottleneck as well）。当今的数据中心里头，典型的在一个机架中的20-80处理节点是通过“机架顶上的转换器（ a top-of-rack switch）到一个二级汇聚交互器（a second level aggregation switch）”互联的。这些接着是通过“到存储区域网络的路由（routers to storage area networks ），以及广域连接（wide-area connectivity）”进行连接的，比如英特网或数据中心内部的WANs。并不昂贵的1吉比特以太网（Gigabit Ethernet, short for 1GbE） 可以在聚合的较低层次上进行全面部署（is universally deployed at the lower levels of aggregation.）。这种带宽可以表现出以下的一个执行瓶颈：为了“包在内部互联之上的喷发”的内部节点处理模式（for inter-node processing patterns that burst packets across the interconnect），类似于发生在Map和Reduce 两个处理之间的所谓“拖曳（shuffle ）”步骤。另一个需要更高的带宽的批处理应用集（set of batch applications）就是所谓“高性能计算应用（high performance computing applications）”；带宽的匮乏是少数科学家使用云计算的一个原因。
10吉比特以太网（10GbE）典型的用于云网络中的聚合链接（the aggregation links in cloud networks），不过现在对独立服务（servers）来说，用于部署还是太昂贵了。（现今对10 GbE服务连接大约是$1000，比对1GbE 连接是大约$100）。不过，当每10 GbE 服务连接的成本如期望的那样会在2010年跌破$200的话，它会在云中获得广泛的部署，因为之于“减缓数据传输延迟性以及网络连接”方面，对它有很高的期望。这将会反过来使 “使得通过扩展该网络，有更多的核心和每个物理服务器节点的虚机（enables more cores and virtual machines per physical server node by scaling up the network.）”成为可能。同样在2010年，40 GbE 和100 GbE 会在更高的汇聚层出现【参见10】。
第五个障碍：性能不可预测（Performance Unpredictability）
我们的经验是在云计算中，多个虚机很好的共享了CPU以及主存，但是 I/O共享仍旧是一个问题。图3(a)显示了“75个运行所谓流基准的EC2实例（75 EC2 instances running the STREAM memory benchmark）”的平均内存带宽【参见32】。带宽的中位值是1355 兆字节每秒，标准差是 52兆字节每秒，不倒中位值的4%。图3(b)显示了对“ 75 个EC2实例，每个都把1 GB 文件写到本地磁盘”而言的平均磁盘带宽。磁盘写带宽的中位值接近55兆比特每秒，其标准方差稍微超过点9兆比特每秒，超过了中位值的16%。这显示出在虚机之间的I/O冲突问题（the problem of I/O interference between virtual machines）。
图3：(a) 左边是，在用75台虚拟机去跑流基准“（the STREAM benchmark）”的内存性能基准测试 ；(b)右边是，写1GB的文件到75台虚机的磁盘性能。
性能不可预测带来的一个机会是提升架构和操作系统，使虚机中断和I/O通道能有效化（efficiently virtualize interrupts and I/O channels）。类似PCIexpress 这样的技术很难虚拟化，但是对云确实至关重要的。一个有希望的理由是这样的：IBM 大型机（mainframes ）和操作系统在1980年代就大体上克服了这些问题，所以我们有足以消效仿的榜样。
另一个可能的原因是闪存会降低I/O冲突（interference）。所谓“闪存（Flash）”是一个半导体，或者当类似机械硬件磁盘这样的关机时能保存信息的内存 ，不过由于它没有移动的部分，所以用于获取就快的多（微妙级和毫秒级的差别），而且能量也使用的更少。闪存可以支持远较磁盘可以支持为多的“每秒每吉比特的存储的I/Os”，所以有随机I/O工作负载冲突的诸虚机，可以在同一台物理计算机上更好的共存而没有和我们所见的机械磁盘之干扰（interference）。缺少了我们在图3(a)中所见的和半导体主存的交互，这也可能会波及半导体存储（might extend to semiconductor storage as well），因而增加了可以很好的在VM上运行的，即共享了单一计算机应用之数量。这种好处在于降低了云计算供应商的成本，最终会是使云计算客户收益。
另一个不可预测的障碍关注的是“对某些级别的批处理程序，特别是高性能计算而言，所谓虚机排产（the scheduling of virtual machines ）”。假定高性能计算是用于“政府花了1亿美元采购的有10,000到1,000,000个处理器的超级计算机中心”的， 铁定会有许多并行任务会从弹性计算中获益（ many tasks with parallelism that can benefit from elastic computing）。成本相关（Cost associativity）是指对于“使用20倍的时间和使用1/20th 的时间用于计算（using 20 times as much computing for 1/20th the time）”而言，不存在惩罚成本（no cost penalty）。潜在会获益的应用包括了那些有非常高的潜在金融回报的－金融分析（financial analysis），石油勘探（petroleum exploration），影视动画（petroleum exploration）－只要付适量的保费就能得到20倍增速的回报率（could easily justify paying a modest premium for a 20x speedup）。另一个评估是当今服务市场的三分之一高性能计算【参见10】。
对吸引HPC（译注：指高性能计算） 而言的障碍是没有使用集群（clusters）；现今大多数并行计算都是在大型集群用“消息传递接口 (message-passing interface ，short for MPI)”上完成的。问题是许多HPC 应用需要确保说一个程序的所有线程要同时在跑，而且今天的虚机和操作系统还没有提供给程序员可视化的操作方式来确保这一点。因此，克服性能不可预测性这个障碍的机会就是提供某种类似所谓“帮排产（gang scheduling） ”的东西给云计算【尾注13】。
第六个障碍：可扩展存储（Scalable Storage）
本文早先提到，我们识别出了三个属性，这三个属性的组合让云计算变得有吸引力：短语使用（short-term usage ）（这暗示出当资源不再需要时候的屈伸），没有预先开销（up-front cost），以及没有无限的随需容量（Infinite capacity on-demand）。直接面对的就是当应用到计算时这意味着什么，关于“如何把它应用到持久存储”还不是很明显。
如表4所示，有许多“从查询与存储API的丰富度（the richness of the query and storage API’s），到提供性能防护（the performance guarantees offered）以及能由存储系统直接支持的数据结构复杂性（例如，无模式blobs 比对面向列的存储）【尾注14】”的回答该问题努力。可扩展存储障碍所面临的机会目前还是一个开放性的研究问题（译注：指尚未定论的问题）：生成一个“不仅会符合需求，而且会运用云在随需自动扩缩 方面的优势来合并那些需求的” 存储系统。同时符合程序员之于就“扩展性，数据持久性以及高可用性（scalability, data durability, and high availability）”的资源管理方面的期望。
表4：云计算供应商的例子，以及它们各自提供的虚拟化资源（计算、存储、网络），且保证了这些资源的扩展性和高可用性。
第七个障碍：大规模分布式系统的故障（Bugs in Large-Scale Distributed Systems）
云计算的一个困难的挑战是从这些非常大尺度的分布式系统上移除错误。一个常见的发生情形是这些故障在更小的配置下不能被重复（these bugs cannot be reproduced in smaller configurations），从而调试也必需在生产数据中心的规模上发生。
大规模分布系统的故障这个障碍的一个机会就是依赖云计算中的虚机。许多传统的SaaS 供应商（译注：Gmail就是一个例子）在不使用虚机情况下开发出了他们自己的架构，即是因为他们比最近流行的虚机先走了一部，也是因为他们觉得负担不起虚机的性能损失（felt they could not afford the performance hit of VMs.）。由于虚机在效用计算中扮演了礼节上需要的角色（VMs are de rigueur in Utility Computing），那种级别的虚拟化可能使得它可能去以捕获一种若无 虚机就不可能捕获的有用信息。
第八个障碍：快速的扩展（Scaling Quickly）
现收现付（Pay-as-you-go）必然应用到存储以及网络带宽中，这两者都对使用的比特进行计数。计算基于虚拟化级别（virtualization level）就有些微的不同了（译注：虚拟化有哪些级别？）。谷歌的AppEngine 自动扩展以对“装载的增加与减少”进行反应，且用户是通过使用的周期来收费的。AWS 是通过你占用的实例数的时间收费的，即便你的机器是空闲的。
这样，快速扩展障碍的一个机会就是：快速的扩缩以对装载进行反应以便省钱，但不会和服务级别协议相冲突（without violating service level agreements.）。实际上，RAD实验室的一个关注点就是：允许动态扩展的“作为诊断与预测工具的普遍进取的使用的”统计机器学习（statistical machine learning ），对性能和调正问题的自动反馈（automatic reaction to performance and correctness problems），以及这些系统的许多方面的普通自动管理。
另一个扩展的原因是像节约物力一样节约财力。由于一空闲的计算机使用了相当一繁忙计算机大约三分之二的能源，对资源的仔细规划可以减少数据中心对环境的影响，这目前广为大众所诟病。云计算供应商已对其资源消耗做了小心翼翼的有关低日常开销台帐和其它方面的规划。通过利用每小时与每字节成本，效用计算鼓励程序员关注效率（例如，只有在需要的时候才释放和获取资源），并允许更直接的对操作和开发中的低效作测量。
清楚的了解成本是进行保护（conservation）的第一步，但是关于“结构使得成本试图去从空闲机器中没日没夜的遗失（configuration make it tempting to leave machines idle overnight）”的这个争辩，使得 开发者下一天回到工作中来的开始时什么都不能做。一个快速易用的重启工具可能会进一步保护计算机资源。
第九个障碍：荣誉命运共享（Reputation Fate Sharing）
荣誉（Reputations ）还不能很好的虚拟化。一个客户的不良行为会影响整个云的荣誉（译注：一粒老鼠屎坏了一锅粥）。比方说，由防间谍服务之EC2 IP 地址黑名单【参见31】可以限制何种应用可以有效的寄宿。一个机会就是生成，类似于当前提供的（收取一定费用）受信电子邮件服务（“trusted email” services）的，荣誉防护服务（reputation-guarding services）对经历了该问题的缩小版的，寄宿在更小的ISP上的（译注：指荣誉虚拟化？）进行服务。
另一个法律议题是法律责任的转移（transfer of legal liability），云计算供应商希望法律责任仍旧保存在客户那里而不是转到供应商的头上（即，是发送垃圾邮件的公司应该负法律责任，而不是亚马逊）。
第十项困难：软件证书（Software Licensing）
目前的软件证书常常对软件运行于其上的那些计算机作了约束。用户对软件付费，然后对每年维护费再收费。实际上，SAP 宣称它会至少增加其年度维护费到购买该软件价格的22%，以和Oracle的价格相配【参见38】。因此，许多云计算供应商最初都部分的把开源软件作为其靠山，因为对商业软件的证书模式并不能很好的匹配于效用计算。
首要的机会是可以使开源仍旧流行或简单的使商业软件公司变更它们的证书结构以更好的适用云计算。比如，Microsoft 和Amazon 现在对处于 EC2上的Windows Server 和Windows SQL Server提供现收现付软件证书。一个运行于Microsoft Windows上的EC2实例成本是$0.15 每小时，取代传统的开源版本其每小时是$0.10【尾注13】。
一个相关的障碍是鼓励软件公司的销售势力如何把软件卖到云计算上去。现收现付看上去和追踪用于衡量绩效的季度销售，基于一次性购买，有矛盾，云计算供应商的机会只是对可以打折的大量使用提供了简单的预付计划。比如，Oracle的销售人员可能售出10万接下去2年中使用ORACLE的实例时间，这种成本较之“客户自己购买10万小时（the customer were to purchase 100,000 hours on their own）”而言为低。它们在那时就可以符合它们的季度配额，使得从云中销售的佣金（make commissions）和从传统软件销售中一样，这潜在的把面向客户的公司那部分从唱反调（naysayers）转换云计算的鼓吹者。
8 关于明日之云的一些问题和结论（Conclusion and Questions about the Clouds of Tomorrow）
作为一种效用的计算这一长久梦想最终正在浮出水面。当工作负载可以增长远较20年前为快的时候，，所谓“效用的弹性（The elasticity of a utility）”就符合了“直接给处于英特网上客户提供服务”的商业期望。曾经把一幢生意发展到数百万客户要花数年，现在只需要几个月。
从云供应商的观点来看，在低成本站点的非常大数据中心的构建，使用商业计算、存储和网络揭开了“以现收现付模式能低于许多中心数据中心去销售那些资源，通过在一大组客户上作统计多路复用来盈利”这样一种可能性（the construction of very large datacenters at low cost sites using commodity computing, storage, and networking uncovered the possibility of selling those resources on a pay-as-you-go model below the costs of many medium-sized datacenters, while making a profit by statistically multiplexing among a large group of customers. ）。从云用户的观点来看，一个新软件开始构建自己的数据中心是很吃惊的，这由于为了一硬件启动要构造自己的制造线。除了开启（startups）之外，许多其它建立的组织会从正规的云计算弹性中获益，包括了像华盛顿邮报这样的新闻报纸，像皮克斯（Pixar）这样的影片公司以及向我们这样的大学。我们的实验室极大的从“会议截止期之前能作完整研究的这种能力，以及调整学期资源以适应课程截止期”中获益。作为云计算用户，我们被（译注：云计算模式）减轻了处理我们内部的数据中心的“过渡供给和供给不足”之孪生危险。
一些关于“诸如来自搜索引擎的广告收入和传统包装软件”的，是否公司能适应高利润生意的问题在云计算中将不再是问题（can compete in Cloud Computing）。首先，这些问题假设云计算是基于其低成本上的薄利多销。考虑到中型规模数据中心的典型利用率，以经济规模而论潜在的因子是5到7，以及在选择云计算数据中心位置时的未来节省，表面的提供给客户的低成本仍旧能使云供应商获得高的回报。其二，这些公司已经有其主导业务的数据中心、网络和软件基础设施了，所以云计算代表了一个机会：只需一点额外的成本就有更多的入账。
尽管云计算供应商可能与表6总结的障碍相冲突（run afoul of），我们还是相信长期最终，可能通过成功的开掘相应于哪些障碍的机会，云计算供应商能成功的驾驭这些挑战，并作出榜样的姿态。
因此，开发者设计他们部署于云里头的下一代系统是明智的。总体上来说，强调的重点在于水平的扩展成百上千的虚机，而不是在单一虚机上的系统效率。还有一些明确的蕴涵式要说：
未来的应用软件（Applications Software of the future）很可能会是其一块会运行在客户端，另一块运行于云里头。云里头的那一片需要可以快速的屈伸，这将会是软件系统的新需求。客户端的一块需要在“连接从云中断开”时被用到，这不是当今Web 2.0许多应用的例子。这样的软件也会需要一个按需付费（pay-for-use）模型以和云计算相匹配。
未来的基础架构软件（Infrastructure Software of the future）需要认识到它不再是运行在裸金属上了，而是在虚机之上。还有，在开始的时候要砸许多钱（数十亿美元），这对改进会计系统来说会很难。
未来的硬件系统（Hardware Systems of the future）需要在容器（至少是一打机架）的尺度进行设计，而不是在单一的1U 盒子（译注：？）或单一机架尺度上设计，因为那会是被采购的最小单元。操作成本会和性能相匹配，购买成本会在购置决策时变得越来越重要（cost of purchase in importance in the acquisition decision.）。因此，他们需要通过把 内存、存储和网络的空闲部分放到低能量模式争取与能源相称【参见9】 ，这在今天的微处理器上早就是已近发生了。硬件同样应该被设计成假设最低级别的软件会是虚机而不是单独的天然操作系统，而且硬件会需要把闪存作为内存层次中的介于DRAM和磁盘的新的一层（译注：高速缓存的地位？）。最后，我们需要数据中心交换器和WAN 路由器两者的带宽和成本方面的提升。
虽然我们对云计算的未来很乐观，我们仍旧很愿意通过一个水晶球去看看在未来的5年它有多热和它长啥样：
技术和价格随时间的变更（Change In Technology and Prices Over Time）：对高层虚拟云而言数十亿单元看上去像是什么（What will billing units be like for the higher-level virtualizationclouds）？表5中，追踪不同资源的相关价格，它看上去会是怎样？很明显，每个芯片的核型数会随时间而增加，每2到4年会翻番。闪存有“之于经典的内存层次添加另一个相关的快速层”的潜力（译注：闪存连接了哪两个运行速度有量级差的设备？）；它的数十亿单元会是什么？技术或商业的革新会加速网络带宽的价格么？什么是当前发展最慢的技术？（译注：准备去涅软柿子了？）
虚拟化层次（Virtualization Level）：云计算会被类似“亚马逊EC2这样的低层硬件虚机，Microsoft Azure这样的中间语言，或者像Google AppEngine这样的高层框架 ”所统摄么？或者我们会有许多虚拟层以匹配不同的应用么？通过“类似RightScale和Heroku或来自效用计算的EngineYard ”这样的独立公司的附加值服务可能么？或者成功的服务完全是由云供应商指派可能么？如果它们确实巩固到单一虚拟层，多个公司会共举一个标准么（译注：2年后的今天看来是似乎确实如此）？这会导致价格上的恶性竞争（a race to the bottom ），从而对云计算供应商失去吸引力么？或者为了保持利润，它们会对服务和质量进行区分么？
致谢（Acknowledgments）
我们都工作在RAD 实验室。这个实验室的存在是由于Google，Microsoft和Sun Microsystems这些创办成员的慷慨支持，以及相关的有AmazonWeb Services, Cisco Systems, Facebook, HewlettPackard, IBM, NEC, Network Appliance, Oracle, Siemens, 和 VMware； 加利福尼亚州 MICRO项目基金和加州工业大学/大学合作研究项目（加州发现）；以及国家科学基金。我们也感谢赵峰（Feng Zhao）等人（译注：赵峰为音译，“等人”为译者略去）。
尾注 (NOTE)
【1】相关的术语“网格计算”来自于高性能计算社区， 建议协议给出长程共享通讯与存储，但这些协议不会导致软件环境的成长超出其社区。另一个从云计算文献发现的术语是多租户（multitenant），这简单的指多个来自不同公司的客户在使用SaaS，所以客户及其数据需要作保护。
【2】无连接操作的挑战对云计算而言不是新玩意：扩展研究已经检查了，根植于终曲文件系统【参见30】和河口数据库【参见18】的，无连接操作的问题。我们只简单的指出满足应用级与协议级的解决方案已开发出来了，并应用在了许多领域，包括了消息访问协议（IMAP）的电子邮件，CalDAV 日历，类似 CVS和Subversion这样的版本控制系统， 最近为嵌入浏览器的JavaScript之 Google Gears可以无连接方式运行。我们很有信心，当移动应用的需求是期望使用云时类似的途径会开发出来。
【3】 基于使用的价格和租用是两码事。租用一资源涉及到对在某时间周期内拥有资源，支付一协商价格，无论你是否使用了这个设备。现收现付涉及测量使用和基于实际使用的承担， 使用的发生独立于时间周期。亚马逊AWS 把他们的总帐聚集到最近的服务小时或吉比特月（rounds up their billing to the nearest server-hour or gigabyte-month），但是相关的美金量是足够的小（便士）以使得AWS 称为真正的现收现付服务。
【4】US最长使用的经济模型是允许资本开支超过3年周期线性的贬值（扣除税务）（a capital expense to be depreciated linearly over a 3-year period），从而我们使用了这个图景作为我们开支比较的设备生命周期之评估。
【5】根据由Keynote 系统公司于2008年黑色星期五（11月28日）收集而得的统计数据，Target 和Amazon的电子商务站点在星期五变慢了 －“上周只需25秒的一个事务在星期五早上就需要30秒了”。【参见5】
【6】第二版的Hennessy/Patterson 有关于存储系统的以下经验法则（rules of thumb）：
? I/O 总线 < 75%
? 磁盘 总线 SCSI < 40% (当对每个总线附加多个磁盘)
? 磁盘臂搜索 < 60%
? 每秒磁盘IO或MB/s < 峰值的80%
因此，60%到80%是安全的上界。
【7】表8显示了AWS S3存储和网络在过去2.5年中的价格变更
【8】表9显示了新的服务和AWS在2008年新添支持选项，并对每个的日期作了介绍。表10显示了不同类型的AWS 计算实例以及介绍了每种类型的数据。
表9：新AWS服务
表10：EC2实例随时间显示出来的差异
【9】 当这样的标准可以对效用计算在全谱线范围内发生时，云供应商中的领导者们的能力在“分布软件以匹配标准API（distribute software to match standardized APIs ）”上是各异的。Microsoft 处于软件分布业（software distribution business），所以看上对它来说“从Azure 到公布所有APIs，并且提供在数据中心里头跑的软件”是一小步。对AWS 和Google AppEngine来说，很有趣的是，最好的标准化APIs 的例子来自于这些公司外之外－开源的努力（open sources efforts ）。Hadoop 和Hypertable 是一种之于谷歌架构的努力重构【参见11】，Eucalyptus 则是对EC2 API 之重要特性进行重构【参见34】。
【10】实际上，让我们回到节2，“涌芯片制造（surge chip fabrication）”是类似TSMC这样的制造公司“无晶圆（chip-les)”的一种通称。
【11】一个1TB 3.5寸磁盘重1.4磅。如果我们假设包装重量增加了20%的总重，则运送10个磁盘的重量就是17磅。FedEx 对于下一天早上10.30递送这样一个包裹收取$100，在2天递送到收取$50。和网飞（Netflix）类似，亚马逊也可以让你在需要的时候借用所谓“磁盘船（disk boat）”。因此，亚马逊之于你的磁盘集和你取回磁盘的双程船运成本是$150，假设从亚马逊回来的递送以及通宵递送到亚马逊是2天。亚马逊然后会花掉大约2.4小时去将该数据内容备份（dump）到它们的数据中心里头。（一个1TB磁盘可以以115 兆比特每秒的速率进行传输）。如果每个磁盘都涵盖整个文件（比如，一个Linux ext3或者Windows NTFS文件系统），那么所有的磁盘都可以并行的读和写。虽然很难去算内部数据中心的LAN带宽成本，不过可以肯定至少比使用WAN 带宽省了百倍。然我们假设用于开包、装载磁盘从而它们可读，以及重新打包的人力成本是每个磁盘$20。
总的延迟就小于1天（2.4小时用于写，14-18小时用于通宵船运，2.4小时用于读）花费大约是$400 （$50是用于从亚马逊收磁盘的，$100适用于发磁盘给亚马逊的，$200用于人工，$40用于内部亚马逊 LAN 带宽和人工收费）。
如果不是运送磁盘的话，另一个选择就是运送整个磁盘阵列，包括了金属架（sheet metal），风扇（fans），能源供给器（power suppliers），以及网络接口。额外的组件会增加运输的成本，但是也会简化到云、本地设备的连接存储并节约了人力。要注意你将会期望比通常的磁盘阵列所需要的多得多的网络带宽，这是因为你不希望装载或卸载数据的时间蔓延开来。
【12】相关的新的公司数据域对增加的备份使用了特定压缩裁剪算法，这可以减低对这些备份大小为原来的20分之1（by a factor of 20）。要注意压缩同样可以减缓效用计算供应商的标准存储产品之成本。无损压缩（Lossless compression）可以把大多数数据类型的数据需求减低到原来的2分之1到3分之1（by factors for two to three），对对其他类型来说更是高了。云计算供应商可能在许多时候有少量的计算周期可用于压缩不常用的数据。因此，实际的存储成本可能会比客户所认为存储的要少2到3倍。尽管客户也可以进行压缩，他们已经为压缩和解压缩在计算周期上花了钱，没有免费计算这种奢侈品。
第二个客户所不能拥有的优势就是在诸客户上“删除（de-dupe）”文件。这种方式的存储会对每个文件计算一个签名，然后只把单一的拷贝存到磁盘上去。可以在许多客户上是同一的文件例子包括了大众程序和大众图像以及其它媒体的binaries 。
【13】比如，为了简化并行编程，通常的做法是，在所有线程计算时分阶段，然后线程作交互（have phases where all the threads compute and then all the threads communicate）。计算和交流阶段是由同步隔离（a barrier synchronization）来区分的，其时每个线程必需等待，直到最后一个线程结束了计算和通讯为止。如果这个帮的一些线程不跑了，那会减慢这些阶段直到它们都跑起来为止。尽管我们可以要求高性能计算程序员使用更放松的同步（more relaxed synchronization）去重写它们的程序，如在谷歌的 Map Reduce所发现的，“一个更短的术语选项”可以让云计算供应商去适用于象“一效用计算操作”一样，提供之于虚机的“同步帮服务”（a shorter term option would just be for the Cloud Computing provider to offer simultaneous gang scheduling of virtual machines as a Utility Computing option）。
【14】亚马逊早期最先提供的是S3，一个对大型的二进制对象的主键唯一存储。尽管S3控制自己的复制件，失效掩饰和供给，纲领性的API是一个键值对存储（即，一个哈希表），反馈时间对客户服务器应用来说是不足够的，且存储在S3中的数据从存储系统的视角看是不透明的（即，你不可以基于除了其任意主键的任何其它属性去询问或者管理数据）。亚马逊的弹性块存储服务允许客户在虚拟块设备上生成文件系统，不过资源管理和长期冗余就留给了各个应用的程序员；这个和应用开发人员相关的问题被描述为所谓“阻抗失配（impedance mismatch）”（译注：参看对象关系阻抗失配），应用开发程序员还理性常规的依赖存储系统去执行附加资源管理，并提供表达存储数据的结构之一套API。亚马逊S3 和Google BigTable是自动做这事的，但是它们的纲领性APIs 并不过多的暴露出存储数据的结构，作为对比，就是诸如Amazon SimpleDB或者 Microsoft SQL Data Services这样的关系型数据库。
【15】AWS 之于Oracle 产品证书的声明仅应用于在他们的本地电脑上已经是Oracle用户的那些人。
索引 （References）
[1] Cloudera, Hadoop training and support [online]. Available from: http://www.cloudera.com/.
[2] TC3 Health Case Study: Amazon Web Services [online]. Available from: http://aws.amazon.com/solutions/
[3] Washington Post Case Study: Amazon Web Services [online]. Available from: http://aws.amazon.com/
solutions/case-studies/washington-post/.
[4] Amazon.com CEO Jeff Bezos on Animoto [online]. April 2008. Available from: http://blog.animoto.com/2008/
04/21/amazon-ceo-jeff-bezos-on-animoto/.
[5] Black Friday traffic takes down Sears.com. Associated Press (November 2008).
[6] ABRAMSON, D., BUYYA, R., AND GIDDY, J. A computational economy for grid computing and its implementation in the
Nimrod-G resource broker. Future Generation Computer Systems 18, 8 (2002), 1061–1074.
[7] ADMINISTRATION, E. I. State Electricity Prices, 2006 [online]. Available from: http://www.eia.doe.gov/neic/
rankings/stateelectricityprice.htm.
[8] AMAZON AWS. Public Data Sets on AWS [online]. 2008. Available from: http://aws.amazon.com/
[9] BARROSO, L. A., AND HOLZLE, U.
计算的能量比率案例
The Case for Energy-Proportional Computing.
IEEE Computer 40, 12 (December 2007).
[10] BECHTOLSHEIM, A.
云计算与云网络
Cloud Computing and Cloud Networking.
talk at UC Berkeley, December 2008.
[11] BIALECKI, A., CAFARELLA, M., CUTTING, D., AND O’MALLEY, O.
Hadoop: a framework for running applications on large clusters built of commodity hardware
Wiki at http://lucene.apache.org/hadoop.
[12] BRODKIN, J. Loss of customer data spurs closure of online storage service ’The Linkup’. Network World (August 2008).
[13] CARR, N. Rough Type [online]. 2008. Available from: http://www.roughtype.com.
[14] CHANG, F., DEAN, J., GHEMAWAT, S., HSIEH, W., WALLACH, D., BURROWS, M., CHANDRA, T., FIKES, A., AND
GRUBER, R.
大表：结构化数据的分布式存储
Bigtable: A distributed storage system for structured data
In Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation (OSDI’06) (2006).
[15] CHENG, D. PaaS-onomics: A CIO’s Guide to using Platform-as-a-Service to Lower Costs of Application Initiatives While
Improving the Business Value of IT. Tech. rep., LongJump, 2008.
[16] DEAN, J., AND GHEMAWAT, S.
Mapreduce：大规模集群上的简化数据处理
Mapreduce: simplified data processing on large clusters
In OSDI’04: Proceedings of the 6th conference on Symposium on Opearting Systems Design & Implementation (Berkeley, CA, USA, 2004), USENIX Association, pp. 10–10.
[17] DECANDIA, G., HASTORUN, D., JAMPANI, M., KAKULAPATI, G., LAKSHMAN, A., PILCHIN, A., SIVASUBRAMANIAN,
S., VOSSHALL, P., AND VOGELS, W.
发电机：亚马逊的高可用键值对存储
Dynamo: Amazon’s highly available key-value store.
In Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles (2007), ACM Press New York, NY, USA, pp. 205–220.
[18] DEMERS, A. J., PETERSEN, K., SPREITZER, M. J., TERRY, D. B., THEIMER, M. M., AND WELCH, B. B.
河口的体系结构：在移动用户间支持数据共享
The bayou architecture: Support for data sharing among mobile users.
In Proceedings IEEE Workshop on Mobile Computing Systems & Applications (Santa Cruz, California, August-September 1994), pp. 2–7.
[19] GARFINKEL, S.
对亚马逊的网格计算服务的一次评估：EC2, S3 和 SQS
An Evaluation of Amazon’s Grid Computing Services: EC2, S3 and SQS
Tech. Rep. TR-08-07, Harvard University, August 2007.
[20] GHEMAWAT, S., GOBIOFF, H., AND LEUNG, S.-T.
谷歌文件系统
The google file system
In SOSP ’03: Proceedings of the nineteenth ACM symposium on Operating systems principles (New York, NY, USA, 2003), ACM, pp. 29–43.
Available from: http://portal.acm.org/ft_gateway.cfm?id=945450&type=pdf&coll=Portal&dl=
GUIDE&CFID=19219697&CFTOKEN=50259492.
[21] GRAY, J.
Distributed Computing Economics
Queue 6, 3 (2008), 63–68. Available from: http://portal.acm.org/ft_gateway.cfm?
id=1394131&type=digital%20edition&coll=Portal&dl=GUIDE&CFID=19219697&CFTOKEN=50259492.
[22] GRAY, J., AND PATTERSON, D.
和Jim Gray的一次谈话
A conversation with Jim Gray
ACM Queue 1, 4 (2003), 8–17.
[23] HAMILTON, J.
大规模数据中心的能量开销
Cost of Power in Large-Scale Data Centers [online].
November 2008. Available from perspectives.mvdirona.com/2008/11/28/CostOfPowerInLargeScaleDataCenters.aspx.
[24] HAMILTON, J.
英特网尺度的服务效率
Internet-Scale Service Efficiency
In Large-Scale Distributed Systems and Middleware (LADIS) Workshop (September 2008).
[25] HAMILTON, J.
观点
Perspectives
[online] 2008. Available