云计算是一种新兴的技术，它允许我们通过互联网来使用计算机资源，就像用水和电一样方便。想象一下，你不需要自己建一个发电厂来发电，而是可以直接从电力公司购买电力。云计算也是这样，你不用自己买服务器和电脑硬件，而是可以直接从云计算公司那里租用这些资源。
云计算的好处有很多，比如：
- 节省成本：你不需要一开始就投入很多钱来买硬件，而是可以根据需要来租用，这样就不会浪费资源。
- 灵活性：如果你的业务需求突然增加，你可以迅速增加使用的云计算资源，而不需要等待购买和安装新硬件。
- 按需付费：你只需要为你实际使用的资源付费，这就像根据你喝了多少水来支付水费一样。
云计算可以分为几种类型：
- 公共云：像自来水公司一样，云计算公司提供的服务对所有人都开放，你可以根据需要随时使用。
- 私有云：某些公司可能会选择建立自己的云计算环境，只供自己内部使用，这就像他们有自己的私人水井。
云计算的挑战和机会包括：
- 服务可用性：云计算公司需要确保他们的服务始终可用，这样用户就不会遇到服务中断的问题。
- 数据安全：用户的数据存储在云端，云计算公司需要确保这些数据的安全，防止数据泄露或被未经授权的人访问。
- 性能：云计算公司需要提供高性能的服务，这样用户在使用云服务时才能获得良好的体验。
云计算的未来可能会看到更多的创新，比如：
- 软件设计：软件将需要能够快速适应资源的变化，并且能够根据使用情况来付费。
- 硬件设计：服务器和数据中心将需要更加高效和节能，以便更好地适应云计算的需求。
总的来说，云计算是一个不断发展的领域，它正在改变我们使用和思考计算资源的方式。随着技术的进步，我们可以期待云计算带来更多的便利和效率。
什么是云计算？
云计算指的是通过互联网作为服务交付的应用程序，以及提供这些服务的数据中心（数据中心）的硬件和系统软件。这些服务本身长期以来被称为软件即服务（Software as a Service，SaaS），因此我们使用该术语。数据中心的硬件和软件是我们所称的云。当云以按需付费的方式向公众开放时，我们称之为公共云（Public Cloud）；所销售的服务是公用计算（Utility Computing）。当前公共公用计算的例子包括亚马逊网络服务（Amazon Web Services，AWS）、谷歌应用引擎（Google AppEngine）和微软Azure（Microsoft Azure）。我们使用私有云（Private Cloud）一词来指企业或其他组织的内部数据中心，这些数据中心不对公众开放。因此，云计算是SaaS和公用计算的总和，但通常不包括私有云。我们通常使用“云计算”这一术语，只有在需要明确时才用其他术语替代。图1展示了作为这些云计算层级的用户或提供者的人的角色，我们将使用这些术语来帮助阐明我们的论点。
SaaS对最终用户和服务提供者的优势已被广泛理解。服务提供者享受极大简化的软件安装和维护以及对版本控制的集中管理；最终用户可以“随时随地”访问服务，更容易共享数据和协作，并将他们的数据安全地存储在基础设施中。云计算并未改变这些论点，但确实为更多的应用程序提供者提供了将其产品部署为SaaS的选择，而无需配置数据中心：就像半导体代工厂（semiconductor foundries）使芯片公司能够在不拥有制造厂的情况下设计和销售芯片一样，云计算允许部署SaaS并按需扩展，而无需构建或配置数据中心。类似于SaaS允许用户将部分问题卸载给SaaS提供者，SaaS提供者现在也可以将部分问题卸载给云计算提供者。从现在起，我们将重点关注潜在的SaaS提供者（云用户）和云提供者，这些角色受到的关注较少。
我们将避免使用诸如“X即服务（X as a service，XaaS）”的术语；我们在文献中见到的X值包括基础设施（Infrastructure）、硬件（Hardware）和平台（Platform），但我们甚至无法在内部就它们之间的精确差异达成一致。¹ 相反，我们在第5节中提出了一个简单的公用计算服务分类，侧重于从云提供者和云用户的角度在程序员便利性、灵活性和可移植性之间的权衡。
从硬件的角度来看，云计算有三个新的方面 [42]：
- 需求时可用的无限计算资源的幻象，从而消除了云计算用户提前进行配置规划的需求；
- 消除了云用户的前期承诺，使公司能够从小规模开始，只有在需求增加时才增加硬件资源；
- 能够按需按短期使用计算资源（例如，按小时计费的处理器和按天计费的存储）并根据需要释放它们，从而通过让机器和存储在不再有用时释放来奖励节约。
图1：云计算的用户和提供者
SaaS对SaaS用户和SaaS提供者的好处已被充分记录，因此我们关注云计算对云提供者和SaaS提供者/云用户的影响。顶层可以是递归的，因为SaaS提供者也可以是SaaS用户。例如，一个出租地图的混合提供者可能是Craigslist（克雷格列表）和谷歌地图服务的用户。
我们将论证，这三点对于云计算所带来的技术和经济变化都是重要的。事实上，过去的公用计算努力失败了，我们注意到在每种情况下，这三个关键特性中的一两个是缺失的。例如，2000-2001年的英特尔计算服务（Intel Computing Services）需要协商合同，并且使用期限比按小时计费更长。
作为一个成功的例子，亚马逊网络服务（Amazon Web Services，AWS）的弹性计算云（Elastic Compute Cloud，EC2）以每小时10美分的价格销售1.0 GHz x86指令集架构（ISA）“切片”，并且一个新的“切片”或实例可以在2到5分钟内添加。亚马逊的可扩展存储服务（Scalable Storage Service，S3）每月每吉字节（gigabyte，GByte）收费0.12至0.15美元，此外，向AWS通过互联网传输数据的带宽费用每吉字节为0.10至0.15美元。亚马逊的策略是通过统计复用（statistically multiplexing）将多个实例复用到单一物理机上，这样一台机器可以同时出租给许多客户，而这些客户通常不会相互干扰（见第7节）。
虽然对云计算用户（SaaS提供者）的吸引力显而易见，但谁会成为云计算提供者，为什么？首先，实现统计复用和批量采购所带来的规模经济需要建设极其庞大的数据中心。
建设、配置和启动这样一个设施是一项价值数亿美元的工程。然而，由于2000年代初网络服务的惊人增长，许多大型互联网公司，包括亚马逊（Amazon）、易贝（eBay）、谷歌（Google）、微软（Microsoft）等，已经在进行此类建设。同样重要的是，这些公司还必须开发可扩展的软件基础设施（如MapReduce、谷歌文件系统（Google File System）、BigTable和Dynamo [16, 20, 14, 17]）以及防范潜在物理和电子攻击的运营专长。因此，一个公司要成为云计算提供者的必要但不充分条件是，它不仅必须在非常庞大的数据中心中有现有投资，还必须在大规模软件基础设施和运营专长方面有投资，以运行这些数据中心。鉴于这些条件，各种因素可能会影响这些公司成为云计算提供者：
- 赚取大量利润。尽管每服务器小时10美分看起来很低，表2总结了詹姆斯·汉密尔顿（James Hamilton）的估计 [23]，认为非常大型的数据中心（数万个计算机）可以以中型数据中心（数百或数千台计算机）提供价格的1/5到1/7购买硬件、网络带宽和电力。此外，软件开发和部署的固定成本可以在更多机器上摊销。其他人估计价格优势为3到5倍 [37, 10]。因此，一个足够大的公司可以利用这些规模经济，以远低于中型公司的成本提供服务，并仍然获得可观的利润。
- 利用现有投资。在现有基础设施上增加云计算服务提供了一个新的收入来源，理想情况下，增量成本较低，有助于摊销数据中心的大额投资。事实上，根据亚马逊首席技术官（CTO）Werner Vogels的说法，许多亚马逊网络服务（Amazon Web Services，AWS）技术最初是为亚马逊的内部运营开发的 [42]。
- 维护特许经营权。随着传统服务器和企业应用程序拥抱云计算，拥有这些应用程序既定特许经营权的供应商将有动力提供自己的云选项。例如，微软Azure（Microsoft Azure）为微软企业应用程序的现有客户提供了一个立即迁移到云环境的路径。
- 攻击现有巨头。拥有必要数据中心和软件资源的公司可能希望在出现任何单一“800磅大猩猩”之前在这一领域建立据点。谷歌应用引擎（Google AppEngine）提供了一条云部署的替代路径，其吸引力在于它自动化了许多开发者可能需要自行构建的可扩展性和负载均衡功能。
- 利用客户关系。像IBM全球服务（IBM Global Services）这样的IT服务组织通过其服务产品拥有广泛的客户关系。提供品牌化的云计算服务为这些客户提供了一条无忧的迁移路径，保留了双方在客户关系中的投资。
- 成为一个平台。Facebook（脸书）的插件应用计划非常适合云计算，正如我们将看到的，事实上，Joyent是一家云提供者，是Facebook插件应用的一个基础设施提供者。然而，Facebook的动机是将其社交网络应用程序变成一个新的开发平台。
多个云计算（和传统计算）数据中心正在一些看似令人惊讶的地点建设，如华盛顿州昆西（Quincy，Washington，Google、微软、雅虎（Yahoo!）等）和德克萨斯州圣安东尼奥（San Antonio，Texas，微软、美国国家安全局（National Security Agency，NSA）等）。选择这些地点的动机在于电力、冷却、劳动力、物业购买成本和税收在地理上是可变的，而在这些成本中，仅电力和冷却就可以占数据中心成本的三分之一。表3显示了不同地区电力成本 [10]。物理学告诉我们，运输光子比运输电子更容易；也就是说，通过光纤电缆运输数据比通过高压输电线路运输电力更便宜。
表1：云计算增长的十大障碍及其机会的快速预览
| 障碍 | 机会 |
|---|---|
| 1 服务可用性 | 使用多个云提供商；利用弹性防止分布式拒绝服务攻击（DDOS） |
| 2 数据锁定 | 标准化应用程序接口（APIs）；兼容的软件以启用激增计算 |
| 3 数据机密性和可审计性 | 部署加密、虚拟局域网（VLANs）、防火墙；地理数据存储 |
| 4 数据传输瓶颈 | 快递磁盘；数据备份/归档；更高带宽的交换机 |
| 5 性能不可预测性 | 改进虚拟机（VM）支持；闪存；虚拟机群调度 |
| 6 可扩展存储 | 发明可扩展存储 |
| 7 大型分布式系统中的漏洞 | 发明依赖于分布式虚拟机的调试器 |
| 8 快速扩展 | 发明依赖于机器学习（Machine Learning，ML）的自动扩展器；用于节约的快照 |
| 9 声誉命运共享 | 提供类似于电子邮件的声誉保护服务 |
| 10 软件许可 | 按使用付费的许可证；批量使用销售 |
表2：2006年中型数据中心（≈1000台服务器）与非常大型数据中心（≈50,000台服务器）的规模经济 [24]
| 技术 | 中型数据中心成本（每月） | 非常大型数据中心成本（每月） | 比率 |
|---|---|---|---|
| 网络 | 95美元/Mbit/sec/月 | 13美元/Mbit/sec/月 | 7.1 |
| 存储 | 2.20美元/GByte/月 | 0.40美元/GByte/月 | 5.7 |
| 管理 | ≈140台服务器/管理员 | >1000台服务器/管理员 | 7.1 |
表3：按地区划分的每千瓦时电价 [7]
| 每千瓦时价格 | 地区 | 可能原因 |
|---|---|---|
| 3.6美分 | 爱达荷州（Idaho） | 水电；无需长距离输送 |
| 10.0美分 | 加利福尼亚州（California） | 电力通过电网长距离输送；湾区传输线路有限；不允许燃煤发电 |
| 18.0美分 | 夏威夷（Hawaii） | 必须运输燃料以发电 |
物理学告诉我们，运输光子比运输电子更容易；也就是说，通过光纤电缆运输数据比通过高压输电线路运输电力更便宜。
4 完美风暴中的云计算：为何如今，而非往昔？
虽然我们认为，建设和运营极大规模的商品计算数据中心是云计算的关键必要推动因素，但其他技术趋势和新商业模式在此次使其成为现实中也起到了关键作用。一旦云计算“起步”，便发现了之前不合逻辑的新应用机会和使用模式。
4.1 新的技术趋势和商业模式
伴随着 Web 2.0（Web 2.0）的出现，服务的提供方式从“高接触、高利润、高承诺”转变为“低接触、低利润、低承诺”的自助服务。例如，在 Web 1.0（Web 1.0）中，接受陌生人的信用卡支付需要与支付处理服务如 VeriSign（威睿签名）或 Authorize.net（授权网）签订合同；这种安排是更大商业关系的一部分，使得个人或非常小的企业在线接受信用卡支付变得繁琐。然而，随着 PayPal（贝宝）的出现，任何个人都可以在无需合同、无需长期承诺且仅支付适度按使用付费的交易费用的情况下接受信用卡支付。这些服务提供的“接触”程度（客户支持和关系管理）几乎没有，但这些服务现在个人可以轻松使用，这似乎使这一点变得不那么重要。类似地，个人的网站现在可以使用 Google AdSense（谷歌广告联盟）通过广告实现收入，而无需与如 DoubleClick（现被谷歌收购）的广告投放公司建立关系。这些广告也可以为 Web 2.0 应用提供商业模式。个人可以使用 Amazon CloudFront（亚马逊 CloudFront）分发网络内容，而无需与如 Akamai（阿卡迈）这样的内容分发网络建立关系。
亚马逊网络服务（Amazon Web Services，AWS）在2006年利用这一洞察，通过无需合同的按使用付费计算服务实现了这一点：所有客户只需一张信用卡。第二项创新是销售硬件级虚拟机（Virtual Machines，VMs）周期，允许客户选择自己的软件堆栈而不干扰彼此，同时共享相同的硬件，从而进一步降低成本。
4.2 新的应用机会
虽然我们尚未看到由云计算启用的根本性新型应用，但我们相信，几类现有的重要应用将在云计算的推动下变得更加有吸引力，并进一步促进其发展。当吉姆·格雷（Jim Gray）在2003年[21]审视技术趋势时，他得出结论，出于经济必要性，必须将数据置于应用程序附近，因为广域网络的成本下降速度（且仍相对较高）慢于所有其他IT硬件成本。尽管自格雷的分析以来，硬件成本有所变化，但他关于这一“盈亏平衡点”的观点仍未改变。虽然我们将更深入地讨论云计算经济学至第6节，但我们利用格雷的见解来审视哪些类型的应用程序特别适合作为云计算的机会和驱动力。
移动互动应用。蒂姆·奥莱利（Tim O’Reilly）认为，“未来属于那些能够实时响应用户或非人类传感器提供的信息的服务。”[38] 这样的服务将被吸引到云端，不仅因为它们必须高度可用，还因为这些服务通常依赖于最方便托管在大型数据中心中的大型数据集。这尤其适用于结合两个或更多数据源或其他服务的服务，例如混合应用（mashups）。虽然并非所有移动设备始终连接到云端，但特定应用领域中成功应对断开连接操作的挑战，我们认为这并不是移动应用吸引力的重大障碍。
并行批处理。尽管迄今为止我们主要关注将云计算用于互动的SaaS（软件即服务），但云计算为分析数TB数据并可能需要数小时完成的批处理和分析任务提供了独特的机会。如果应用程序中有足够的数据并行性，用户可以利用云的新“成本关联性”：使用数百台计算机短时间的成本与使用少数计算机长时间的成本相同。例如，华盛顿邮报（The Washington Post）的高级工程师彼得·哈金斯（Peter Harkins）使用200个EC2（亚马逊弹性计算云）实例（1,407服务器小时）在希拉里·克林顿（Hillary Clinton）的旅行文件发布后九小时内将17,481页文档转换为更适合在WWW（万维网）上使用的格式[3]。像谷歌的MapReduce（映射归约）[16]和其开源对应物Hadoop（哈杜普）[11]这样的编程抽象允许程序员表达这些任务，同时隐藏了在数百个云计算服务器上编排并行执行的操作复杂性。事实上，Cloudera（克劳德拉）[1]正在这一领域追求商业机会。同样，利用格雷的见解，成本/收益分析必须权衡将大数据集迁移到云端的成本与数据分析中潜在加速带来的收益。当我们回到经济模型时，我们推测亚马逊（Amazon）将大型公共数据集免费托管的部分动机[8]可能是为了减轻这一分析的成本方面，从而吸引用户在这些数据附近购买云计算周期。
分析的崛起。计算密集型批处理的一个特殊案例是商业分析。虽然大型数据库行业最初由事务处理主导，但这种需求正在趋于平稳。越来越多的计算资源现在用于理解客户、供应链、购买习惯、排名等。因此，尽管在线事务量将继续缓慢增长，决策支持却在快速增长，数据库处理中的资源平衡从事务转向商业分析。
计算密集型桌面应用的扩展。最新版本的数学软件包Matlab和Mathematica能够使用云计算执行昂贵的评估。其他桌面应用可能同样受益于无缝扩展到云端。同样，一个合理的测试是比较在云端计算的成本加上数据进出云端的成本与使用云端节省的时间。符号数学涉及大量每单位数据的计算，使其成为一个值得研究的领域。一个有趣的替代模型可能是将数据保留在云端，并依赖于足够的带宽以实现适当的可视化和响应式图形用户界面（GUI）回馈给人类用户。离线图像渲染或3D动画可能是类似的例子：给定3D场景中对象的紧凑描述和光源的特性，渲染图像是一个极易并行的任务，具有高计算与字节比率。
“地面”应用。一些本来适合云端弹性和并行性的应用可能会因数据移动成本、进入和退出云端的基本延迟限制或两者兼而有之而受阻。例如，虽然与制定长期财务决策相关的分析适合云端，但需要微秒级精度的股票交易则不适合。除非广域数据传输的成本（并可能是延迟）降低（见第7节），否则这些应用可能不太适合作为云端候选。
5 公用计算的类别
任何应用程序都需要计算模型、存储模型，并且假设应用程序即使是微不足道地分布式，也需要通信模型。实现弹性和无限容量幻象所需的统计复用要求对资源进行虚拟化，以便将它们如何被复用和共享的实现方式对程序员隐藏起来。我们的观点是，不同的公用计算（Utility Computing）产品将基于呈现给程序员的抽象层级和资源管理的水平来区分。
**Amazon EC2（亚马逊弹性计算云）**处于这个光谱的一端。一个EC2实例看起来很像物理硬件，用户几乎可以控制整个软件堆栈，从内核开始。所暴露的API（应用程序编程接口）是“薄”的：仅有几十个API调用用于请求和配置虚拟化硬件。对可以托管的应用类型没有先验限制；低层次的虚拟化——原始CPU周期、块设备存储、IP级连接——允许开发者编写任何他们想要的代码。另一方面，这使得亚马逊在提供自动扩展和故障转移方面本质上变得困难，因为与复制和其他状态管理问题相关的语义高度依赖于具体应用程序。
AWS确实提供了许多更高层次的托管服务，包括与EC2配合使用的几种不同的托管存储服务，如SimpleDB（简单数据库）。然而，这些产品具有更高的延迟和非标准的API，并且我们的理解是，它们的使用范围不如AWS的其他部分广泛。
光谱的另一端是应用领域特定的平台，如Google AppEngine（谷歌应用引擎）和Force.com（Force.com），SalesForce的商业软件开发平台。AppEngine专门针对传统的网络应用程序，强制应用程序结构在无状态计算层和有状态存储层之间进行清晰的分离。此外，AppEngine应用程序预计是基于请求-响应模式的，因此在服务特定请求时可以使用的CPU时间受到严格限制。AppEngine令人印象深刻的自动扩展和高可用性机制，以及可供AppEngine应用程序使用的专有MegaStore（巨型存储）（基于BigTable（大表））数据存储，均依赖于这些限制。因此，AppEngine不适合通用计算。同样，Force.com旨在支持运行在**Salesforce.com（销售力量公司）**数据库上的商业应用程序，仅此而已。
微软Azure（Microsoft Azure）处于这个灵活性与程序员便利性光谱的中间点。Azure应用程序使用.NET（微软开发框架）库编写，并编译到Common Language Runtime（通用语言运行时，CLR），一个与语言无关的托管环境。该系统支持通用计算，而不仅仅是一类应用程序。用户可以选择编程语言，但无法控制底层操作系统或运行时。库提供了一定程度的自动网络配置和故障转移/可扩展性，但要求开发者以声明性的方式指定某些应用属性。因此，Azure介于像AppEngine这样的完整应用框架和像EC2这样的硬件虚拟机之间。
表4总结了这三类如何虚拟化计算、存储和网络。可扩展存储的零散产品表明，具有与SQL相当丰富的API的可扩展存储仍然是一个开放的研究问题（见第7节）。亚马逊已开始在AWS上提供托管的Oracle数据库，但该产品的经济性和许可模式使其与云计算的自然契合度较低。
不同模型在云计算空间中的竞争
一个模型会在云计算空间中胜过其他模型吗？我们可以类比编程语言和框架。低级语言如C和汇编语言允许精细控制和与裸金属（物理硬件）的紧密通信，但如果开发者正在编写一个Web应用程序，管理套接字（sockets）、分派请求等机制即使有良好的库也是繁琐和乏味的。另一方面，高级框架如**Ruby on Rails（Ruby on Rails）**使这些机制对程序员来说不可见，但仅在应用程序轻松适应请求/响应结构和Rails提供的抽象时才有用；任何偏离都需要深入框架，且可能编写起来笨拙。没有合理的Ruby开发者会反对C在某些任务上的优越性，反之亦然。因此，我们相信不同的任务将导致对不同类别公用计算的需求。
继续类比语言，就像高级语言可以用低级语言实现一样，高度托管的云平台可以托管在管理较少的平台之上。例如，AppEngine可以托管在Azure或EC2之上；Azure可以托管在EC2之上。当然，AppEngine和Azure各自提供了专有功能（AppEngine的扩展、故障转移和MegaStore数据存储）或复杂的API（Azure的.NET库），这些功能或API没有免费实现，因此任何试图“克隆”AppEngine或Azure的尝试都需要重新实现这些功能或API——这是一项艰巨的挑战。
表4：云计算供应商示例及其如何提供虚拟化资源（计算、存储、网络）并确保资源的可扩展性和高可用性。
| 亚马逊网络服务（Amazon Web Services，AWS） | 微软Azure（Microsoft Azure） | 谷歌应用引擎（Google AppEngine） |
|---|---|---|
| 计算模型（虚拟机，VM） | 计算模型（虚拟机，VM） | 计算模型（虚拟机，VM） |
| - 基于X86指令集架构（ISA）的Xen虚拟机 | - 微软通用语言运行时（Common Language Runtime，CLR）虚拟机；在托管环境中执行的通用中间形式 | - 基于声明性描述（如哪些“角色”可以复制）的机器配置；自动负载均衡 |
| - 计算弹性允许可扩展性，但开发者必须构建相关机制，或依赖第三方增值服务商如RightScale提供 | - 预定义的应用程序结构和框架；程序员提供的用Python编写的“处理器”，所有持久状态存储在MegaStore（MegaStore，基于BigTable）中 | - 自动扩展和缩减计算和存储；网络和服务器故障转移；所有这些与三层Web应用结构一致 |
| 存储模型 | 存储模型 | 存储模型 |
| - 从块存储（Elastic Block Store，EBS）到增强的键/Blob存储（SimpleDB）范围广泛 | - 自动扩展程度从不扩展或共享（EBS）到完全自动扩展（SimpleDB，S3），取决于使用的模型 | - 一致性保证因使用的模型而异 |
| - API从标准化（EBS）到专有 | - API从标准化（EBS）到专有 | - SQL数据服务（SQL Server的受限视图） |
| - Azure存储服务 | - MegaStore/BigTable | |
| 网络模型 | 网络模型 | 网络模型 |
| - IP级拓扑的声明性规范；内部放置细节隐藏 | - 安全组允许限制哪些节点可以通信 | - 基于程序员对应用组件（角色）声明性描述的自动化 |
| - 可用性区域提供独立网络故障的抽象 | - 固定拓扑以适应三层Web应用结构 | - 固定拓扑以适应三层Web应用结构 |
| - 弹性IP地址提供持久可路由的网络名称 | - 自动扩展和缩减计算和存储；网络和服务器故障转移 | - 自动扩展和缩减计算和存储；网络和服务器故障转移 |
6 云计算经济学
在本节中，我们对云计算的经济模型提出一些观察：
- 在决定是否在长期内将服务托管在云端时，我们认为云计算所启用的细粒度经济模型使得权衡决策更加灵活，特别是云提供的弹性有助于转移风险。
- 此外，尽管硬件资源成本持续下降，但其下降速度不一；例如，计算和存储成本下降的速度快于广域网（WAN）的成本。云计算能够更有效地跟踪这些变化——并有可能将其传递给客户——比建立自己的数据中心更能实现支出与实际资源使用的紧密匹配。
- 在决定是否将现有服务迁移到云端时，还必须额外考察预期的平均和峰值资源利用率，特别是如果应用程序可能有高度可变的资源需求峰值；所购买设备的实际利用率的实际限制；以及根据所考虑的云环境类型而变化的各种运营成本。
6.1 弹性：转移风险
尽管云计算的经济吸引力通常被描述为“将资本支出转化为运营支出”（CapEx 转 OpEx），但我们认为“按使用付费”这一短语更直接地捕捉了买方的经济利益。通过云计算购买的小时数可以在时间上非均匀分布（例如，今天使用100个服务器小时，明天不使用任何服务器小时，仍然只为实际使用的部分付费）；在网络社区中，这种销售带宽的方式已被称为基于使用的定价。
此外，缺乏前期资本支出允许将资本重新分配到核心业务投资。因此，即使亚马逊的按使用付费定价（例如）可能比购买并在同一时期内折旧一个可比服务器更昂贵，我们认为这种成本被弹性和风险转移的极其重要的云计算经济利益所抵消，尤其是过度配置（资源利用不足）和配置不足（饱和）的风险。
我们从弹性开始。关键观察是，云计算能够以细粒度（每次一个服务器，使用EC2）和以分钟而非周为单位的提前时间增加或减少资源，从而更紧密地匹配资源与工作负载。数据中心中服务器利用率的实际估计范围为5%到20% [37, 38]。这听起来可能令人震惊，但与许多服务的峰值工作负载超过平均水平2到10倍的观察结果一致。很少有用户有意为低于预期峰值的需求进行配置，因此他们必须为峰值进行配置，并允许资源在非峰值时期保持闲置。变化越明显，浪费越多。一个简单的例子展示了弹性如何减少这种浪费，并因此能够弥补按使用付费与购买的潜在每服务器小时更高的成本。
例子：弹性。假设我们的服务有一个可预测的每日需求，其中峰值在中午需要500台服务器，而低谷在午夜只需要100台服务器，如图2(a)所示。只要全天的平均利用率为300台服务器，全天的实际利用率（曲线下的阴影区域）为300 × 24 = 7200服务器小时；但由于我们必须为500台服务器的峰值进行配置，我们支付500 × 24 = 12000服务器小时，比实际需要多1.7倍。因此，只要按使用付费的每服务器小时成本在3年内低于购买服务器成本的1.7倍，我们就可以使用公用计算节省资金。
事实上，上述例子低估了弹性的好处，因为除了简单的昼夜模式外，大多数非平凡的服务还会经历季节性或其他周期性的需求变化（例如，电子商务在12月达到峰值，照片分享网站在假期后达到峰值），以及由于外部事件（例如新闻事件）引起的一些意外需求激增。由于获取和架设新设备可能需要数周时间，处理这种峰值的唯一方法是提前进行配置。我们已经看到，即使服务运营商正确预测了峰值规模，容量也是浪费的，如果他们高估了峰值，他们的配置就更糟。而他们可能也会低估峰值（图2(b)），从而意外地拒绝了过量用户。尽管过度配置的货币影响易于衡量，但配置不足的货币影响则较难衡量，然而潜在的严重性同样高：不仅被拒绝的用户不会产生收入，他们可能由于糟糕的服务而永远不会回来。图2(c)旨在捕捉这种行为：用户会离开配置不足的服务，直到峰值用户等于数据中心的可用容量，此时用户再次获得可接受的服务，但潜在用户和收入减少。
例子：转移风险。假设只有10%的因配置不足而接受糟糕服务的用户是“永久失去”的机会，即如果他们有更好的体验，原本会继续成为常规访问者。该网站最初配置为处理预期峰值40万用户（每服务器1000用户 × 400服务器），但意外的积极宣传使第一小时内有50万用户涌入。在被拒绝或接受糟糕服务的10万用户中，假设其中1万永久失去，留下活跃用户基数为39万。下一小时看到25万新独特用户。前1万用户表现良好，但网站仍然超出容量24万用户。这导致额外的2.4万用户流失，留下37.6万永久用户。如果这种模式继续下去，经过19小时后新用户数量将趋近于零，网站将达到稳定状态下的容量。显然，服务运营商在这19小时内收集的稳态收入不足40万用户，但这再次说明了资源利用不足的论点——更不用说因不满用户带来的糟糕声誉了。
这些场景在实际中真的会发生吗？当Animoto [4] 通过Facebook提供其服务时，经历了一次需求激增，导致服务器从50台增长到3500台，仅用了三天。即使每台服务器的平均利用率较低，也没有人能够预见到资源需求会在3天内每12小时突然翻倍。在峰值消退后，流量下降到远低于峰值的水平。因此，在这个现实世界的例子中，规模上升的弹性不仅不是成本优化，而是一项运营要求，而规模下降的弹性则允许稳态支出更紧密地匹配稳态工作负载。
弹性对既有公司和初创公司都很有价值。例如，全国第二大零售商**Target（塔吉特）**使用AWS（亚马逊网络服务）托管其Target.com网站。其他零售商在“黑色星期五”（11月28日）遇到了严重的性能问题和间歇性不可用性，而Target和亚马逊的网站仅慢了大约50%。同样，Salesforce.com（销售力量公司）托管的客户范围从2座位到超过4万座位的客户。
即使是不那么戏剧性的案例也足以说明云计算的这一关键利益：误估工作负载的风险从服务运营商转移到了云供应商。云供应商可能会为承担这种风险收取溢价（反映为相比3年购买成本更高的每服务器小时使用成本）。我们提出以下简单方程式，概括了上述所有案例。我们假设云计算供应商采用基于使用的定价，客户按使用的时间和资源量按比例付费。虽然有些人主张基础设施服务应采用更复杂的定价模型 [28, 6, 40]，但我们认为基于使用的定价将会持续存在，因为它更简单、更透明，正如“真实”公用事业如电力和燃气公司广泛使用所证明的那样。类似地，我们假设客户的收入与总用户小时数直接成正比。这一假设与广告支持的收入模型一致，其中服务的广告数量大致与最终用户在服务上花费的总访问时间成正比。
UserHourscloud×(revenue−Costcloud)≥UserHoursdatacenter×(revenue−CostdatacenterUtilization)(2)\text{UserHours}_{\text{cloud}} \times (\text{revenue} - \text{Cost}_{\text{cloud}}) \geq \text{UserHours}_{\text{datacenter}} \times \left(\frac{\text{revenue} - \text{Cost}_{\text{datacenter}}}{\text{Utilization}}\right) \quad (2)UserHourscloud×(revenue−Costcloud)≥UserHoursdatacenter×(Utilizationrevenue−Costdatacenter)(2)
左边将每用户小时的净收入（每用户小时实现的收入减去支付云计算的每用户小时成本）乘以用户小时数，给出了使用云计算的预期利润。右边通过考虑数据中心的平均利用率（包括非高峰工作负载）对固定容量数据中心进行相同的计算。两边中较大的那一边代表了更高利润的机会。
显然，如果利用率 = 1.0（数据中心设备的利用率为100%），方程的两边看起来相同。然而，基本排队论告诉我们，随着利用率接近1.0，系统响应时间趋近于无限。在实践中，数据中心的可用容量（不影响服务质量）通常为0.6到0.8。虽然数据中心必须为考虑到这种“开销”而进行过度配置，但云供应商可以简单地将其因素计入Costcloud。（这一开销解释了为什么我们使用“按使用付费”而不是租赁或租赁的说法用于公用计算。后者包括这种不可用的开销，而前者则不包括。因此，即使你租用一个100 Mbits/秒的互联网连接，你实际上可能只能使用60到80 Mbits/秒。）
该方程清楚地表明，我们所有例子中的共同元素是控制运营服务的每用户小时成本的能力。在例1中，由于资源闲置，每用户小时成本较高——更高的成本但相同的用户小时数。同样，当过度估计需求导致为未实现的工作负载进行配置时也会发生同样的情况。在例2中，由于低估了峰值并不得不拒绝用户，导致每用户小时成本增加：由于部分用户永不返回，固定成本保持不变，但现在在更少的用户小时数上摊销。这说明了“购买”模型在面对任何非平凡的负载突发时的根本限制。
最后，云计算用户还有两个额外的好处，这源于能够按小时而非按年改变其资源使用。首先，意外地缩减规模（处置暂时利用不足的设备）——例如，由于业务放缓，或讽刺的是由于软件效率提高——通常会带来财务罚款。以3年折旧为例，一台在运营1年后退役的2100美元服务器相当于“罚款”1400美元。云计算消除了这种罚款。
其次，技术趋势表明，在某些购买设备的有用寿命内，硬件成本将下降，新硬件和软件技术将变得可用。云供应商，已经享有规模经济购买力，如第3节所述，可能会将这些节省的一部分传递给他们的客户。事实上，AWS的重度用户在过去2.5年中看到存储成本下降了20%，网络成本下降了50%，并且在不到一年的时间内，AWS增加了九项新服务或功能。
如果云供应商获得了新技术或定价计划，现有的应用程序和客户可能会立即受益，而无需承担资本支出。在不到两年的时间里，亚马逊网络服务（AWS）将不同类型的计算服务器（“实例”）的数量从一个增加到五个，在不到一年的时间内，他们增加了七项新的基础设施服务和两项新的运营支持选项。
6.2 成本比较：我应该迁移到云端吗？
尽管上一节尝试量化云计算特定经济利益（如弹性）的经济价值，本节将探讨一个同样重要但更大的问题：将我现有的数据中心托管服务迁移到云端是否更经济，还是继续保留在数据中心更划算？
表5更新了格雷（Jim Gray）2003年的成本数据 [21] 到2008年，使我们能够跟踪过去5年云计算关键技术的变化速度。注意，如预期的那样，广域网络（Wide Area Network，WAN）成本在5年内的改善最少，提升不足3倍。尽管计算成本在5年内改善最多，但使用额外计算能力的能力基于程序能够利用计算机双插槽上的所有核心的假设。这一假设对于公用计算（Utility Computing）来说更为真实，因为许多虚拟机（Virtual Machines，VMs）服务于数千至数百万客户，而对于单个公司的数据中心内的程序来说则不然。
为了便于计算，格雷计算了2003年1美元的购买力。表5显示了他2003年与2008年的数据，并与2008年AWS的EC2/S3费用进行了比较。乍一看，用于购买2008年硬件的1美元似乎比支付同样硬件的使用费用更划算。然而，这种简单的分析忽略了几个重要因素。
按资源分别支付。大多数应用程序不会对计算、存储和网络带宽等资源进行同等使用；有些是CPU密集型（CPU-bound），有些是网络密集型（network-bound），可能会饱和某一资源而低利用其他资源。按使用付费的云计算可以对每种资源单独收费，减少资源利用不足的浪费。尽管具体节省取决于应用程序，但假设CPU仅50%被利用，而网络带宽达到容量；那么在数据中心，您实际上为双倍数量的CPU周期付费。因此，与其说租用CPU成本为每1美元计算成本2.56美元，不如说租用2美元的CPU更准确。顺便提一下，AWS的广域网络定价实际上比中型公司为相同带宽支付的费用更具竞争力。
电力、冷却和物理设施成本。电力、冷却和建筑物的摊销成本在我们目前的简单分析中尚未考虑。汉密尔顿（James Hamilton）估计，当这些成本摊销到建筑物的生命周期时，CPU、存储和带宽的成本大致翻倍 [23, 26]。使用这一估计，2008年购买128小时的CPU实际上成本为2美元，而不是1美元，相比之下，EC2的成本为2.56美元。同样，10 GB的磁盘空间成本为2美元，而S3每月成本为1.20至1.50美元。最后，S3实际上至少将数据复制3次以确保耐久性和性能，并且在对数据有高需求时会进一步复制。因此，购买成本为6.00美元，而在S3上的每月成本为1.20至1.50美元。
运营成本。如今，硬件运营成本非常低——重启服务器很容易（例如，可通过IP地址控制的电源插座、独立的带外控制器等），经过最少培训的员工可以在机架或服务器级别更换故障组件。一方面，由于公用计算使用虚拟机而非物理机器，从云用户的角度来看，这些任务被转移到了云提供者身上。另一方面，根据虚拟化的水平，许多软件管理成本可能仍然存在——升级、应用补丁等。回到第5节关于“托管与非托管”的讨论，我们认为这些成本对于托管环境（例如微软Azure、谷歌AppEngine、Force.com）会比硬件级公用计算（例如亚马逊EC2）更低，但似乎难以以许多人认可的方式量化这些好处。
考虑到上述警告，以下是决定是否将服务迁移到云端的一个简单例子。
例子：迁移到云端。假设一个生物学实验室为每个湿实验创建500 GB的新数据。速度为一个EC2实例（亚马逊弹性计算云实例）的计算机每GB处理需要2小时。实验室本地拥有相当于20个实例的计算能力，因此评估一个实验所需时间为500 × 2 / 20 = 50小时。他们可以在AWS上使用1000个实例在1小时内完成处理。处理一个实验的成本仅为1000 × $0.10美元 = $100美元的计算费用和500 × $0.10美元 = $50美元的网络传输费用。到目前为止，一切顺利。他们测量了从实验室到AWS的传输速率为20 Mbits/秒 [19]。传输时间为（500GB × 1000MB/GB × 8bits/Byte）/ 20M bits/sec = 4,000,000 / 20 = 200,000秒，即超过55小时。因此，本地处理需要50小时，而在AWS上需要55 + 1或56小时，因此他们不迁移到云端。（下一节将提供如何克服传输延迟障碍的机会。）
相关的问题是，将数据从传统企业应用程序部分或全部迁移到云端的软件复杂性和成本。虽然迁移是一项一次性任务，但所需的努力可能相当大，需要作为决定使用云计算的一个因素予以考虑。这项任务已经为提供跨公共和私有云数据集成的新业务机会的公司带来了新的商业机会。
表6：云计算采用和增长的十大障碍及其机会。
| 障碍 | 机会 |
|---|---|
| 1 服务可用性 | 使用多个云提供商以提供业务连续性；利用弹性防御分布式拒绝服务攻击（DDOS） |
| 2 数据锁定 | 标准化应用程序接口（APIs）；提供兼容的软件以启用激增计算 |
| 3 数据机密性和可审计性 | 部署加密、虚拟局域网（VLANs）和防火墙；通过地理数据存储满足国家法律 |
| 4 数据传输瓶颈 | 快递磁盘；数据备份/归档；降低广域网路由器成本；更高带宽的局域网交换机 |
| 5 性能不可预测性 | 改进虚拟机（VM）支持；闪存；为高性能计算应用群调度虚拟机 |
| 6 可扩展存储 | 发明可扩展存储 |
| 7 大规模分布式系统中的漏洞 | 发明依赖于分布式虚拟机的调试器 |
| 8 快速扩展 | 发明依赖于机器学习（Machine Learning，ML）的自动扩展器；用于节约的快照 |
| 9 声誉命运共享 | 提供类似于电子邮件的声誉保护服务 |
| 10 软件许可 | 按使用付费的许可证；批量使用销售 |