零基础读懂云计算
Author: 纳扬•鲁帕拉里
Date: 2018-02-14T16:00:00+00:00

图书在版编目（CIP）数据

零基础读懂云计算 / (英) 纳扬·鲁帕拉里著 ; 王

雨阳译. -- 上海 : 文汇出版社, 2017.10

ISBN 978-7-5496-2339-6

Ⅰ. ①零… Ⅱ. ①纳… ②王… Ⅲ. ①云计算－普及

读物 Ⅳ. ①TP393.027-49

中国版本图书馆CIP数据核字（2017）第251009号

Cloud Computing by Nayan B. Ruparelia

Copyright: © 2016, by Massachusetts Institute of Technology

This edition arranged with MIT Press

Simplified Chinese edition copyright: 2017, Shanghai Dook Publishing Co., Ltd.

All rights reserved.

中文版权 © 2017上海读客图书有限公司

经授权，上海读客图书有限公司拥有本书的中文（简体）版权

版权登记号 图字：09-2017-898

零基础读懂云计算

作  者 ／ 【英】纳扬·鲁帕拉里

译  者 ／ 王雨阳

责任编辑 ／ 吴 华

特邀编辑 ／ 姜一鸣 乔佳晨

封面装帧 ／ 陈艳丽

出版发行 ／ 出版社

社  址 ／ 上海市威海路 755 号

邮  编 ／ （邮政编码 200041）

经  销 ／ 全国新华书店

印刷装订 ／ 三河市龙大印装有限公司

版  次 ／ 2018 年 1 月第 1 版

印  次 ／ 2018 年 1 月第 1 次印刷

开  本 ／ 890mm×1270mm 1/32

字  数 ／ 127 千字

印  张 ／ 8

ISBN 978-7-5496-2339-6

定  价 ／ 42.00 元

侵权必究

装订质量问题，请致电010-85866447（免费更换，邮寄到付）

目录

前 言

导 读

第一章 导 言

第二章 云计算的类别

第三章 云计算：范示的转移？

第四章 价格与效用模型

第五章 安全与监管

第六章 用例模式（一）IaaS与PaaS

第七章 用例模式（二）SaaS

第八章 用例模式（三）INaaS

第九章 用例模式（四）BPaaS

第十章 向云计算转型

第十一章 未来展望

第十二章 后记：思考

致 谢

词汇表

前 言

知道云计算为何物者寥寥无几。尽管关于这一话题的书籍、文章十分多，但少有真知灼见，有时我觉得连作者自己都一知半解。原因之一是大部分书籍和文章都是以相当技术化的视角讨论云计算，而并未从使用者的角度出发；另一原因是过度营销，各式各样的企业都把云计算当成卖点大肆宣扬。这就会引起很多困惑。通常当一项技术进入视野，并能带来重大的范示转移（paradigm shift）时，情况往往如此。本书的目的正是揭开层层包装，向你展示云计算的本来面目，以及如何从中获益。

也许你是一位投资者，因所投资的生意涉及云相关技术开发而希望对这类技术加深了解；也许你正处于创业阶段，希望利用云计算帮助初创企业轻装上阵，稳步发展；你可能是一位律师或法官，正在处理云计算的相关案件；你或许是一名技术人员，希望利用云计算规划新产品或新服务；你可能是一名商科学生，意图理解云计算对全球商业带来的巨大转变；也或许你只是个门外汉，仅对这个话题好奇而已——无论哪种情形，本书就是为你而写。本书将从使用者的角度出发帮助你理解云计算：何时当用、何时不当用，如何选择一项云服务，如何与其他云服务或传统互联网技术相整合，以及使用过程中的最优做法。

在本书中，我尽可能避免提及商业化的云服务或提供方，主要出于三点考虑：（1）稍不留意，本书就可能变成云服务供应商的软广告；（2）由于技术产业快速更迭的本质使然，有些供应商只是昙花一现，很快就退出市场；（3）本书的主旨在于提供基本概念，以帮助你在第一时间对此类服务做出最佳选择。

本书并不以技术为导向，主要目标读者为非专业人士，当然技术专家也能通过本书进一步理解云计算的广泛影响与考虑要素。因此阅读本书前，无须对云计算或其相关技术有预先了解，不过，我强烈建议读者首先阅读第1章，以便我们在对云计算的基本用语和基础理解上取得共识，这将对你阅读后续章节很有帮助。在读完第1章后，你就可以在各章间任意选读。

导 读

第1章是对云计算的概览，包括概念定义和对定义中各个组成要素的讨论、优势与应用简述，同时论及云计算价值链中的各类参与者或利益相关方。

第2章在第1章的基础上，按不同抽象层（abstraction）与部署模型对云计算的类型进行描述。我将运用我提出的一些新概念，如云模式（cloud patterns）和云单元（cloud cells），对各个模型要素的特征做进一步比较和对比，来说明如何建立或使用专业化云服务。为说明这些专业化云（称为云单元）之间的关系，此处借用了面向对象设计（object-oriented design，OOD）中的一些概念，通过多次调用云单元并定义它们之间的关系，就能够实现不同用例下的云服务。本章以用例模式的讨论结篇。

第3章提出了一个核心问题：为什么要使用云计算？它能为你带来哪些收益，又会对你和你的工作、社群、生活产生什么影响？本章涉及诸多概念，如私人云（personal cloud）、物联云（cloud of things）等。

第4章从财务角度出发，较第3章的阐述更为客观。本章有助于你理解云计算供应商的各类定价模型，在衡量不同云服务性价比时提供称手工具。

第5章是关于安全与监管。近年来各类安全泄露事件层出不穷，因而这不仅是个热点话题，对云计算来说也尤为重要。涉及话题包括安全容器、监控、数据完备性、防范数据泄露、数据隐私、数据管辖权以及相关法律与规范。本章后附有部分业内常用安全术语的解释。

第6至9章详细介绍了第2章中作为概念首次引入的用例模式，并按云计算的不同抽象层级进行划分：（a）基础设施与平台；（b）软件；（c）信息；（d）业务流程。这四章内容均采用同一结构模式：先给出某一抽象层用例模式的示例，然后进行道斯矩阵（SWOT）分析，最后是关键词总结。

第10章阐述如何向云转变。当你决定接受云服务时，从原有服务模式向云服务过渡的最佳途径是什么？本章通过云使用模型、互通性（interoperability）、关键成功因素和一个成熟模型对这一关键问题进行解答。

第11章题为“未来展望”，主要讨论与云计算紧密相关以及边缘的新兴技术，这些技术或将影响云计算的发展方向。本章中还介绍了一些新概念，包括云服务交易所（区别于云交易所）、物联云等。

第12章是我的一些个人见解，我认为多个社会领域都会受到新兴技术、尤其是云计算的影响。以赫胥黎（Huxley）《重返美丽新世界》（Brave New World Revisited）和伯内斯（Bernays）《宣传》（Propaganda）两本著作所勾画的趋势与实践为背景，阐述了我对技术影响下的社会、商业与个人图景的思考。

本书最后附有一份词汇表，其中包含云计算领域的一些主要术语与缩写。

第一章  导 言

考虑一下，在一个工作日你使用电脑时，工作高峰期的电脑资源占用量会是多少？大多数用户的平均用量为处理器的10%、内存的60%和网络带宽的20%（这还是峰值用量，按平均计算，工作时间的正常使用水平还要低得多）。即便如此，你还是得在购买电脑时为这些资源支付100%的费用，而且是预先支付。上网成本也是如此，因为大多数互联网服务供应商（Internet service providers, ISPs）都会设置锁定期，作为客户，你必须使用他们的服务至少一年。如果你所处的工作场所有成百甚至上千台电脑，每台的使用率都微乎其微，为什么不把全公司电脑的闲置计算资源集中起来善加利用呢？这样，公司的花费才能获得最大效用。将同样的思路用于数据中心，这里拥有大量服务器——包括网络服务器、应用服务器、数据库服务器等，使用率同样很低，也可以把它们的硬件资源集中起来用于共享，从而提高其使用效率。否则，你就得为那些偶尔才会用到的计算资源预先付费，如图1所示。空闲资源在集中之后，可以通过公司网络让其他同事一起使用；如果你的公司指定由第三方提供资源共享服务，则通过互联网来访问这些计算资源。

如果你所在的公司或部门只为自己用到的计算资源付费，情况又当如何？作为资本支出，公司就不用预先在购置电脑时进行投资，而只需与服务供应商以按用量计费的方式签约即可。也就是说，公司在满足计算需求时，从原先的资本支出型（capital expenditure, CAPEX）变成了运营支出型（operating expenditure, OPEX）。这正是云计算所发挥的作用。

云计算的定义

尽管信息技术（information technology, IT）已广泛应用于生活与工作中，但这一行业仍然处于成长初期。而云计算作为最前沿的IT创新之一，还未走过成型阶段。在这一阶段，新技术的应用边界总是备受瞩目。从技术专家到销售员，所有人都想要蹭热点搭快车，把但凡能沾上边的东西都贴上“云计算”的标签（往往还带有夸张和臆测）。这就造成了大量混淆，对云计算的定义也多如牛毛。其中最好的定义是由国家科学技术学会（National Institute of Science and Technology, NIST）做出的，这是一个隶属于美国商业部的技术机构，致力于技术、计量与标准的开发和应用。NIST对云计算的定义如下：

云计算是一种模型，使得可供配置的共享计算资源（例如网络、服务器、存储、应用程序、服务等）能够以随处、便捷、按需的网络形式进行访问，这些资源能被快速分配及释放，同时做到管理成本或服务提供者的干预最小化。这种云模型提升了可获得性，并由五个基本特征、三个服务模型和四个有效使用模型组成。

尽管NIST的定义也需要修订，尤其是涉及三个服务模型的部分，这点在本章还会简要提及，但这仍是目前最好的定义。大体上，我们将运用NIST的定义来逐项说明云计算的基本特征、使用模型和服务模型。

在深入讨论云计算的特征之前，让我们先说说虚拟化和云服务，因为它们从两个完全不同的角度构成了云计算的基础：虚拟化是从技术角度，云服务则是从概念角度。

虚拟化

虚拟化技术是云计算的根基，包含服务器虚拟化和应用程序虚拟化两种基本类型。应用程序虚拟化指将一台主机上的应用程序分享给大量用户使用，虽然上载到云端的应用程序需要高端虚拟机来运行，但由于访问用户数量众多，成本得以分摊。这样，应用程序就能以较为便宜的价格分发给终端用户，这些用户不必为了运行程序而配置高端硬件，一台廉价机器——比如一个低端工作站或一个“瘦客户端”——就足够了。如果虚拟应用使用的数据也存储在云端，用户甚至不必受设备或地点的约束，可以随时随地使用应用程序或者访问数据。在这种情况下，终端用户的典型使用方式是通过移动应用或互联网浏览器。

服务器虚拟化以常用的物理硬件（网络、存储或计算设备）来托管虚拟机。一台物理主机可以运行多台虚拟机，不同虚拟机共用一套硬件，但能安装独立的操作系统和不同应用程序。服务器虚拟化的成本优势显著，采用这种方式，你就可以将大量物理设备改为虚拟机，整合到少数物理主机上，提升计算效率，从而减少空间、维护、制冷、电力等各项成本，就降低设备采购成本而言更是显而易见。同时，物理设备减少、耗电量降低也有利于保护环境。

如果你以一种即时实体化（激活并开启）的方式将虚拟机集中在一起，能够实现资源池的任意调入或调出，就能根据需求的增减调整资源用量，即快速分配。这种即时调整资源池内虚拟机数量的能力被称为弹性（elasticity），可以通过服务器虚拟化来较为经济地实现。

那么，虚拟化与云计算的区别在哪里呢？让我们回顾一下NIST对云计算定义中的几大特征：按需自助、快速弹性、可计量的服务量。任意一条都不是虚拟化的必备要求。虚拟化可以作为实现这些特征的技术手段，但还需要其他辅助手段，比如报告、支付、需求管理等各类业务流程与工具。在有效部署云的过程中，你需要考虑如何将提供的服务进行标准化，如何通过简单的端口进行访问，如何跟踪用量与费用信息，如何测量其可用性，如何精心安排以满足需求，如何提供安全框架，如何提供即时报告，以及设置基于用量的记账或收费机制。换句话说，虚拟化本身无法构成一项服务，需要结合其他工具与流程，才能构成基础设施即服务（infrastructure-as-a-service，IaaS）。

云服务

让我们用会计师事务所来打个比方，看看服务——特别是云服务——由哪些要素构成。假设你需要指定一家会计师事务所来管理账务，不妨推断一下你选择它的主要原因：

1. 事务所的诚信及声誉（你希望账目精确，但绝不希望财务信息被公之于世）。

2. 在报表准备和降低税负方面（你将获得的收益）行动迅速。

3. 收取的费用（实现收益所需的成本）。

你大概并不会关心事务所在准备财务报表时雇了多少员工、用了多少软件、把软件装在几台电脑上。你关注的只是其服务和服务带来的效益，这些服务收益构成一种成文或不成文的契约关系，成为你和会计师事务所之间的纽带，这类契约关系被称为服务层级协议（service level agreement, SLA）。

在信息技术中，服务是指集成IT系统、组件与资源，共同为用户提供价值。其中一项重要元素是如何计量用户获取的价值并达成共识，用于评估服务的常用参数包括两项：成本和服务层级协议。服务层级协议是指服务使用方与提供方之间的一种协议，包括服务交付速度（何时）、服务质量（何种）和服务范围（何处、多少），这些参数代表了服务使用方所能获得的收益。如果服务使用方是在公司内部，比方说市场部，那么这种公司内部提供部门与使用部门之间的协议被称为操作层级协议（operational level agreement, OLA）。因此，云服务就是指通过一系列相关联的功能组件和资源，实施一项业务流程，从而为使用者提供商业价值。

继续前文的类比，假设这家会计师事务所想确认自己是否达到了服务层级协议的要求，就可以设置各类指标，用于在编制账目的同时监控自身表现。例如，审计需用时三天，或现金流量表应在一周内调平，等等。事务所可能会告诉你使用了哪些指标，但通常只作为内部使用，以确保自己能符合服务层级协议的所有要求。这些目标或指标被称为服务层级目标（service level objectives，SLOs）。从信息技术的角度来看，服务层级目标是服务层级协议中明确的、可计量的特征，诸如运行时间、处理量、可用资源容量、反应时间和交付时间。

服务模型：抽象层

现在不妨从会计师事务所的角度来看待信息技术。该事务所中的IT部门将会计师视为自己的用户，会计师与IT部门的互动方式存在如下选择：

1. 会计师事无巨细全盘掌控，指定所有硬件和软件信息，包括软件的种类和版本、运行软件的操作系统、硬件内存和存储空间等。

2. 会计师仅指定所需软件，把其他交给IT部门自行决定。

3. 会计师仅确认输入的数据类型和输出的数据格式，至于用什么软件和硬件来执行数据运算，都由IT部门决定。

第一个选项的抽象层处于基础设施层。在云计算中，这被称为基础设施即服务（IaaS），常见的例子包括在云端存储数据、文件、照片，或通过云传输文件。如果IT部门提供的是硬件与操作系统完备的平台，且会计师指定需要使用的软件，如第二项所示，这就属于更高级别的抽象层——平台即服务（platform as a service, PaaS）。

如果IT部门需要决定用哪些软件和运算平台来满足会计师的需求，而会计师只需关心返回数据的精确性和及时性，如第三项中描述的那样，那么这一抽象层就是软件即服务（software as a service，SaaS）。这三个抽象层（IaaS、PaaS和SaaS）就是NIST定义中所提到的服务模型。

假如会计师事务所决定把整个审计职能外包给另一家事务所，以便自己专注于为你提供税务建议，情况又会如何呢？我们就需要与另一家事务所签订服务层级协议，商定费用，由他们来按此进行账务审计。这就相当于外包整个业务功能或流程给另一家事务所。这家接受外包的事务所也可由云服务替代，这种提供商业功能的云服务称为业务流程即服务（business process as a service，BPaaS）。

如果想获得最新的税务法规，会计师事务所可以订阅相关信息服务，这就与信息即服务（information as a service，INaaS）类似。由于税务规章制度会随着法律调整定期修订，这项服务不仅需要用基础设施存储数据，还需要对数据进行处理，以提供有效信息。从这个意义上讲，INaaS确实有别于IaaS。

这样，NIST定义的模型又增加了两个服务抽象层：INaaS和BPaaS，如图2所示。

如图2左栏所示，IT企业架构分为四大领域，即技术架构、应用架构、信息或数据架构以及业务架构。技术架构包括IT基础设施、中间件（middleware）和操作系统；应用架构侧重于软件应用、应用和业务流程之间的交互与关系；数据架构界定数据资产及其管理；业务架构则将业务战略转换为IT战略和相关治理框架，并明确业务流程。企业架构中的每一领域都能映射到图2右侧的云服务模型一栏中，形成匹配关系。

云部署模式

NIST的定义中还包括四大部署模型：公共云、私有云、社区云和混合云。

公共云为互联网接入的所有用户提供服务，服务所用的计算资源可能位于世界任何一个角落。由于监管原因，对于某些公司来说这类云在数据完备性上有所欠缺，比如位于美国的公司就不能保存其他国家的用户数据。金融机构尤其受到严格监管，因此这类公司一般更喜欢使用私有云。

私有云通过一个专用网络单独向其提供云服务，这个提供云服务的主体可以是政府机构或商业企业，但通常只有大企业能够用得起私有云，中小型企业则可以选择社区云。

社区云界于私有云和公共云之间。具有共同利益的个人和企业可以集中资源，建立社区云。这种云形态多样：位于瑞士为州立银行提供服务的银行云、位于北欧的纸业云、位于美国的健康产业云等。同一社区云亦可服务于不同的利益群体，比如国际象棋手和钱币收藏家。

混合云基本上就是其他几类云的合体。当一项云服务的自身资源已经满负荷运行，需要向其他云读取计算资源时，混合云就派上用场了。这一概念称为云爆发（cloud bursting），因为服务需求从云内爆了出来，需要借助其他云的资源来满足服务级别协议。

云计算的五个特征

NIST的定义中列出了云计算的五个特征，即表1的第二栏中所列：随处访问、按需自助、资源集中、快速弹性和用量可测。

能通过互联网在任意地点接入十分重要，这样你就不必为了使用云服务而被限制在某个地方；但与之相伴的问题是，随着潜在用户数量的增长，安全性受损的风险也在增加。因此可能会限制以专用网络或特定范围内的用户进行访问，前者即私有云的做法，而后者则是社区云模型。

按需自取，或说按需可得，允许你在有需要时随时获得服务。这种可得性具有两个特征：

1. 即使未处于使用状态，服务仍然准备就绪，随时待命（因而云计算服务需要有足够的在线时间）；

2. 当处于使用状态时，服务也要维持可获取性（这表示，即使在使用高峰期，你的用户体验也不会下降）。

上述第二点意味着，无论你对服务的需求量有多大，都能得到满足。举个例子，你使用一项IaaS云服务来托管自己的网站，其使用级别随网站点击量而变。使用量会受到一系列因素的影响，比如日间时段、是否为周末、是否正在进行市场推广等等。因此，云计算基础设施的负荷量也在不断变动，需求增大时应提升容量，需求减少时则相应缩减，以便释放基础设施资源在别处使用。这种扩展及缩减的能力也被称为弹性。

水平扩展是指增加同一类型资源（比如计算平台）的数量以满足使用需求。垂直扩展是指通过资源升级来提高其能力，比如增加内存量。弹性的含义是在需求较高时使用水平扩展来扩大资源用量，而在需求较低时进行缩减。为了实现这一点，需要将计算资源集中到资源池中。这些资源一般需虚拟化，以便用软件来自动进行归集和分配。通常情况下，运用虚拟化技术可以在一台物理计算机上运行多个独立的操作系统，如图3所示，这些虚拟的系统被称为虚拟机。在基础设施层面，除虚拟机之外，还可以设置虚拟存储（一台物理存储设备上有多种存储空间）和虚拟网络。

将硬件虚拟化之后，就能以一种弹性的方式来集中并共享这些资源。同一思路也可外推到软件上，即使虚拟机池中只有一个软件在运行，也能共享多个虚拟应用程序。然而这一技术还处于成型阶段，最大的障碍在于许可协议、计费模型等商业事宜。当多种用户使用同一云端虚拟资源时，如软件、存储或虚拟机等，这些资源就拥有了多个租户。这种集中资源向每一个云服务用户提供共享、通用服务的形式被称为多租户。

公共云服务的现存主要问题在于已消费的资源与相应成本不够透明，而用户应该知晓自己使用了哪些资源、于何时使用、费用几何，这些正是云计算的独有特征（当然，如果计费模型是无限量月租型，这一因素也就无关紧要了）。对于云服务而言，能计量并向用户公开服务的使用量极为重要，其原因也在于此。

云计算中的主体

云服务的设立、交付、消费过程涉及四个参与主体，并如图4所示在供应链中进行互动。本节将对这四个主体进行阐述。

服务消费者

服务消费者是云服务的使用方，他们通常会持有一份拟使用服务的目录。如果要新纳入一项云服务，消费者会查阅其主要特征，如费用、质量、及时性等，并就此与云服务供应商达成协议。

服务供应商

云服务供应商是向云服务消费者提供云服务的主体，他们会及时——几乎是实时——为消费者安排配置并激活服务。服务供应商也持有一份目录，其中包括可提供的服务以及相应的成本和合约信息。供应商会区分服务的成本与价格，前者是指服务供应商需要承担的投入金额，而后者是指向服务消费者收取的费用。

服务创建者

服务供应商也可以同时作为服务创建者。服务创建者创建服务，并提供给服务供应商，其主要作用是整合优化作为服务基础的资源供给。

服务经纪人

服务经纪人是服务消费者与一系列服务供应商之间的中介，可以起到三类不同作用：

1. 避免消费者被锁定在单一供应商上，而可以在同一服务中使用不同供应商。

2. 整合不同供应商的服务，向消费者打包提供搭配好的不同种类服务。

3. 从成本、质量、时效等方面，对多个供应商的服务进行统筹优选，并向消费者提供。

和供应商一样，经纪人也需区分成本与价格。大体上，供应商的价格就是经纪人的成本，而经纪人的价格就是消费者的成本。同样，服务层级协议反映了云服务创建者到消费者的链条上逐步累积的收益。

第二章 云计算的类别

前一章论及云服务的两项关键特征：服务抽象层（IaaS、PaaS、SaaS、INaaS和BPaaS）和部署模型（公共云、私有云、混合云和社区云）。本章将对抽象层和部署模型进行更深入的讨论，对比它们的组成特点，并基于云关系建立一系列云计算范示。

还记得前一章中关于云计算的定义吗？云计算具有五个关键特征：

1. 广泛的互联网接入

2. 按需自助

3. 资源池与虚拟化

4. 快速弹性

5. 服务可计量

要够格被称为云服务，就需对上述每项特征均有所体现，这一点极其重要。如果无法满足这些条件，那些自称能提供云服务的供应商就只是“挂羊头卖狗肉”。而本章中的种种论述可能也并不适用于其他服务种类，这里涉及的所有部署模型、抽象层级均具有云计算的这五大特征。

首先，在分析云计算的过程中需要用到我提出的几个新概念，其中之一是借用自面向对象设计（OOD）原理，用于阐释对象间的关系；另一个是云单元的概念，这是一类只完成某项特定工作的专用云，例如数据存储、数据库服务或网页服务。你可以用一系列云单元搭建云应用，并组成一项可供使用的云服务。这一新概念意味着你能对云单元进行重复利用、自由组合，创建出不同的云服务。对这种方法加以延展，还可以得到云模式（cloud pattern），即基于云单元的组合及彼此关系的特定用例。

抽象层

服务模型可以视为逐层递进的抽象层。当你在抽象层中拾阶而上，到达的最高层级便是业务流程即服务（BPaaS），如图5所示。需要注意的是，较高的层级同时包含了下一层级，也就是说，软件即服务（SaaS）层既包含提供商业功能的软件，同时也提供平台即服务（PaaS）；而平台即服务是在基础设施即服务（IaaS）的基础上，额外提供了操作环境。表2按照提供的服务内容不同，列出了五种云计算抽象层的定义。

请留意表格中各抽象层之间的差异，它们本就容易引起混淆，而各类云服务供应商的市场部门还常常异想天开，对这些定义进行任意发挥。举个例子，假如你需要使用IaaS服务，服务供应商出于安全原因，不希望你直接访问基础设施，因而为你预装了操作系统，但即使涉及操作系统安装，这项服务仍然属于IaaS，而非PaaS。如果是PaaS，服务供应商还需要为你安装应用运行所需软件，这类软件可能是运行设定任务的软件库（libraries），可能是包含一套标准库的框架，如.Net，也可能是一个LAMP（Linux-Apache-MySQL-PHP或Perl）那样的应用堆栈，即在Linux服务器上运行的网络服务器（Apache）、数据库（MySQL）、编程语言及其库（PHP或Perl）。而如果你使用IaaS（或PaaS）服务来编写应用程序，就可以在云端运行并发布为一项SaaS——软件即服务，你的用户不用考虑如何安装应用程序、使用什么操作系统，也不用关注这一应用程序需要调动哪些必要软件。更为重要的是，他们不用担心软件升级的问题，你在提供SaaS服务时自然会安装最新版本。

部署模型

重温一下第1章中提及的四个云计算部署模型：公共云、私有云、社区云和混合云。每个部署模型又能对应任一抽象层。比如具有SaaS抽象层级的公共云就可以称为“SaaS公共云”，同样，“PaaS私有云”就是指具备私有部署模型、PaaS抽象层的云，以此类推。

公共云

恰如其名，公共云向希望使用云服务的公众群体开放，既可以是个人用户，也可以是机构。公共云服务的使用几乎都是通过互联网，而非私有网络或受限网络，因此也成为大多数人最为熟悉的部署模型。公共云横跨多类抽象层级，将基础设施、平台、软件、信息、业务流程作为服务内容的都不乏实例。接入其他部署模型下的云服务的网络可能是局域网、广域网或万维网（互联网），但公共云几乎总是通过互联网接入，并按月计费。公共云服务的例子包括谷歌打印（Google Print）、谷歌文档（Google Docs）、微软办公365（Microsoft Office 365）、亚马逊弹性云计算（Amazon EC2）和亚马逊云播放（Amazon Cloud Player）等，这些服务都使用月度运营支出价格模型，用户无须承担或只须少量承担前端资本开支。

私有云

私有云的使用范围为机构、部门乃至个人。一个公司可以部署自己的私有云，并通过广域网（wide area network, WAN）提供服务。你可以将广域网当作公司范围内的互联网，通过防火墙一类的安全设备，将外来访问者拒之门外。局域网（local area network, LAN）与广域网类似，但使用的地理范围更窄：通常只限于家庭或办公室之类的特定位置。个人可以通过局域网使用私有云服务，比如在家里通过无线局域网建立云，用于（1）将视频流服务器连接到机顶盒上，在家里随处实现视频的观看、录制和回放；（2）提供集中存储文件的备份服务；（3）实现跨设备的数据同步（笔记本电脑、手机、台式机等）。

因此，私有云是通过局域网或广域网，向特定用户组提供云服务的部署模型。在少数情况下，私有云也可能通过互联网提供服务，但其访问受到限制，只有特定用户才能对服务进行访问。在实践中，私有云通过互联网提供服务的形式常因数据完备性和安全原因而难以实现。搭建私有云通常需要一定的资本支出，同时也有部分运营开支。

社区云

社区云是私有云的扩展版本，为一个具有共同利益或共同关注点的社群提供支持，此处所说的共同关注点可能包括安全要求、数据私密、监管环境、商业模型、终端用户等。社区云可能按地理位置划定范围，例如欧盟社区云、北美云；也可能以贸易领域来划定范围，如东盟（ASEAN）社区云或金砖四国（BRIC）社区云。“贸易”这一概念非常有趣，它能被延伸理解为不同的行业或商业群体：纸业云、出版业云、银行监管云、健康产业云，既可以限于一个国家内（比如美国健康社区云），也可以是全球化范围（比如世界健康社区云），参与者可以是监管主体、医疗服务提供方、医师、消费者，或其任意组合。

IaaS社区云共享同一云基础设施，SaaS社区云共享同一云软件，而BPaaS社区云共享同一云业务流程。不同于私有云，社区云服务通常通过互联网提供，支付运营支出价格模型。

混合云

混合云是将两类或两类以上云部署模型（私有、社区或公共）进行封装（encapsulation）（见下文对封装的详述），并具有其独特性。混合云可以由单一部署模型组成，如图6中的“混合云1”所示，这一混合云由三个私有云组成，换成三个公共云也一样。组合中的部署模型也可以有所差异，即由不同的模型组成，以“混合云2”为例，其中就包含了一个私有云和一个公共云。同样，混合云也可以包含社区云，如图6中的“混合云3”，甚至是混合云中包含混合云，如“混合云4”，这就可以在内层的混合云中加入其他成分云的复本，以满足业务连续性要求，或平衡工作负荷。

混合云的成分云可以处于任意抽象层吗？比方说，IaaS私有云能否与PaaS公共云并存在同一混合云中呢？当然可以！让我们回到会计师事务所的例子中来，假定事务所想要使用常见的商业化公共云服务来进行客户关系管理（customer relationship management，CRM）、收发邮件及文字处理工作，同时又想在自己的私有云上运行一些商业应用，诸如存货监控软件等。此时，事务所就可以创设一个混合云，并在公共云和私有云之间共享部分数据，如供应商地址等。这么做后，公共云中的文字处理部分就可以向供应商发送信件，同时，私有云中的存货监控也可以判断应联系哪个供应商来补货。这类混合云有什么优势呢？私有云可以保证数据安全，提供更好的运行表现和透明的服务层级目标，而公共云则能提供标准化服务，让事务所免于从头开始自建文字处理云服务，因而既能保留灵活性，又可优化成本。

云的种类

云可以具有任意一种部署模型。你可以将自己的个人云设置成私有云，而Dropbox等虽采用公共云部署模型，也可用作存储文件的个人云。在这一部分中，我们会讨论个人云和物联云这两种迥异的云类型。

个人云

个人云的定义更多是指其使用范围，而不论其是否可以共享。这类云的使用范围是一个人或一个单独实体，既可以是私有云，也可以是公共云或混合云。公共个人云的案例包括iCloud、谷歌云盘（Google Drive）和Dropbox，而私有个人云则可能是用于保存你的数据备份的网络存储设备，苹果公司的空港时间胶囊（AirPort Time Capsule）在连接到一个以上设备时也能起到这个作用。

物联云

物联云的应用范围是无生命主体，也即“物”代替了“人”或“机构”，成为云的服务对象。举例来说，公共照明——如路灯或停车场照明——可以接入云端，只为已经付费并在服务范围内的人们提供按用量计费的照明。当有人进入服务范围时，照明设备自动打开，人离开时则自动熄灭；收取的费用取决于人们在服务范围内停留的时间，也就是基于照明用量收费。这就意味着路灯不必彻夜长明，白白浪费纳税人的钱，并且只有使用照明的居民才会付费，而不再是由全体社区成员通过税收或其他集资机制分摊费用。基于用量的计费机制可以通过芯片密码（chip-and-pin）技术实现，这种技术已用于大部分借记卡和信用卡上。照明设备通过GPRS与云相连，将使用量、灯泡更换等相关数据进行上传。其他物联网的应用还包括汽车、住宅、健康监控设备、家用器具和办公室等。

云关系

混合云中存在一个普遍问题，即其成分云需要共享或整合数据，才能完成云端的应用及服务在彼此之间的传递。事实上，这种数据共享的需求并不仅限于混合云，私有云或公共云也可能将其他云作为自身的组成部分，来提供指定的任务或服务。为实现这一点，需要界定云或云单元之间的关系，这些关系包括封装（encapsulation）、复合（composition）和联合（federation）。

封装

封装是指一个对象包含另一个对象。由于只需要简单复制，封装能使你的工作量最小化。举个例子，一片桉树林可以被描述为一个封装了桉树的林子。从工程师的角度来看，只需要对一棵树进行描述即可，树林不过就是多棵这种树的集合体。

封装具有两种类型：复合和聚合（aggregation）。桉树林是一个聚合的例子，而复合是指将不同的对象融为一体，不再像桉树林那样只是同一对象的重复。一辆汽车可能会被这样描述：它具有四个轮子、一个方向盘、一个引擎盖、一个发动机等。这辆车将零件封装在一起，以复合的方式组成一辆完整的车。汽车是零件的复合，而桉树林是桉树的聚合。从云计算的角度来看，一个云可以封装另一个或几个云，因而封装就是指云服务的复合或聚合。

聚合

聚合可以应用在任一云抽象层中。图7展示了SaaS云的聚合，即多个可以用运营支出型费用及服务层级协议来描述的SaaS组件共同构成了SaaS云。这样聚合的作用是什么呢？再次借用会计师事务所的比喻，假设事务所与自己的IT部门签署了服务层级协议，由其通过SaaS云服务来提供账目配平功能。再假设由于有效的市场营销或者与另一家事务所的合并，新客户数量激增，IT部门无法以原有的服务层级协议来满足日益增长的需求，就可以创建一个账目配平云的副本，来承接新增的需求。新的账目配平SaaS云因而包含了两个云（或说云单元），一个是另一个的副本，对配平服务的需求就可以在这两个单元之间进行分配。相较于重新建立一个单元而言，创建副本单元要简易得多，因为原有单元已经提供了设立模板。聚合用例中这种翻印式方法具有明显的优势，使用灵活，成本低廉。再考虑另一条途径，IT部门没有建立SaaS云的副本，而是外聘了一家公司来提供同类配平服务，经过谈判，和这家公司签订的服务层级协议可以实现与自有云服务完全相同的功能。这样，IT部门的SaaS云就封装了自己的配平单元和另一公司的云单元，来共同应对新增需求。更进一步，IT部门还可以将另一公司的云单元视同于自己所有，因而将自身云单元难以处理的额外需求转至另一公司的单元中进行处理，这就是“云爆发”，即一个云的需求向另一个云溢出，以保持应对需求的弹性。聚合的另一用法是将一个云单元安置在主中心以外的数据中心，这个副本单元就可以用于灾备重建或保持业务连续性，在两个数据中心的主单元和副本单元都是同一SaaS云服务的一部分，共同满足服务层级协议的业务连续性要求。在私有云领域，这种用法尤为有效。最后，IT部门可以聚合各个单元来创建社区云服务，其中一些单元如果已能满足现有需求，就可以被重复利用，如果这些单元具有通用性，甚至可以共享给其他社区云来使用。

总而言之，聚合有多种用法，案例包括（1）提供弹性，满足用户需求；（2）在不同云或不同服务供应商之间进行调配；（3）业务连续性；（4）云服务的再利用，或在不同云之间进行通用服务的共享——这些案例同样适用于其他类型的云。

复合

当云是由一类或多类云组装而成时，可以称为复合，图8所示的复合云封装了五个单元。复合的关键优势在于可重复利用性。比方说，一个存储单元已被用在某个复合云中，同一单元或其副本还可以在另一复合云中再次被使用。重复利用的前提是标准化，一个标准的存储单元需要建立一套规格、界面、功能及管理特征，其中管理特征是指：

1.云单元的升级与补丁；

2.单元硬件的升级；

3.单元操作系统与组成平台的核心应用的升级；

4.托管在该单元内的应用程序的升级；

5.有关未来升级安排的路线图的变动。

对于标准单元特征的任何变动都会对其副本产生同等改变，这么一来对变化情况的管理就要容易得多，但额外测试仍不可或缺，因为某个单元的变化可能在这一复合云中问题不大，但在另一复合云中就不一定可行。因此，为实施标准单元的更改，需要对所有封装了该标准单元副本的复合云进行测试。

标准化、可重复利用、便于管理是复合关系的关键优势。其他优点还包括云组装和配置过程的灵活便利，当你在设计新的云时，只需决定使用哪些模块（即单元）。只要一眨眼工夫，新的云就能搭建完成！对于封装而成的高抽象层级来说，云单元的搭建细节并不重要，你需要了解的只是这个云单元的用途，而非如何搭建、包含何物等细枝末节。作为组件的云单元可以处于任意抽象层、采用任意配送模式，对于复合云而言都毫无区别。复合云可以是IaaS、PaaS、SaaS、INaaS或BPaaS，不过SaaS及以上的高抽象层级更多出现在复合云服务中。

联合

联合是复合的一种特殊形式。其中包含的云服务来自彼此独立的云，而且往往属于不同的服务供应商，可谓是云服务的大杂烩。联合云的组件单元既可以是自己拥有的，也可能属于第三方，甚至所有的云单元都可以来自第三方云服务供应商。这意味着你无须经历自建云或云单元的麻烦，只需要针对服务层级协议和价格进行谈判即可，前提是服务供应商提供的云服务恰如所需。除了能快速创建及使用云之外，联合方式对服务供应商和经纪人也各有裨益。云服务经纪人可以整合多家云服务供应商，和他们分别商定合同、服务层级协议价格，并向你打包提供联合云服务。作为用户，你只需要与云服务经纪人打交道，而不必和其他供应商就条款和价格一一进行谈判。联合方式的另一个优势是提升服务水平，一方面增加现有服务的处理量以满足新增需求，另一方面也可以新增服务种类。这都得益于全球云服务市场时时敞开的大门，如果你的用户突然需要某种资源或服务，而你现有的云服务对此尚无覆盖，你只需从市场采购相应服务，并将其加入你的经纪人或供应商产品目录即可。还有，通过联合可以让一个云单元把工作导入到另一个云单元，从而平衡单元间的工作负荷，或保证失效安全（failure safety）（失效安全是指某一单元失效时，另一单元可以接管工作，以保障服务供应）。需要注意，联合方式的重要前提是云之间的互通与整合，互通性带来的“即插即用”特点将在第10章“向云转型”的部分中进行更为深入的讨论。

云单元

云单元是指可提供独立的基本功能或服务的云，它能作为一个部件，在其他云或云单元中重复使用。前文中讨论了云关系的主要原理，云单元可以视为被封装在云内的一些模块，比如用于提供数据库服务的数据库单元、用于运行互联网站点的网络单元、电子邮件服务器单元等。由于云单元可以共享，因而不必在每个用到该单元的云中重新创建，它们是一次投入，多次利用（当然，这其中涉及很多技术细节——云单元如何向其他单元开放服务，如何进行服务宣传，是否设置控制单元来维护服务目录，单元之间的信息传递需要用到哪些通用数据模型和格式——但由于我们的目的是了解主要概念，因此不会深入探讨细节）。按照前文中所述的云关系，在不同云中重复使用具有独立功能的专业化云单元，就能够节约成本，提升利润。这与戈森（Gossen）的经济学第一定律[1]背道而驰，用量越多，边际效用反而越大。云单元的重复利用也能提高云功能的创建速度，不必再从无到有，从而能在更短的时间内推向市场。

图9显示的是一类称为“母云”的云服务，由多个云单元组成，根据用途可选择是否包含控制单元，其主要作用是协调其他云单元所提供的服务。以网络服务为例，母云中可能封装了下列云单元：网络服务器单元、数据库单元、存储单元以及包含网络服务商业逻辑的SaaS单元。“云齿轮”则是一类主要应用于IaaS和PaaS的特殊云单元，专业化程度较高，独立提供诸如病毒防护、硬盘加密、公共文件共享、备份等应用服务。

云单元模式

网络服务云具有一种模式，即所有网络服务都包含数据库、几个存储器、商业逻辑及网络服务器，这些组件就描述了网络服务的核心。类似的例子还有电子邮件服务、存货管理服务、订单处理服务、音频流服务等，每一类云服务都是由提供特定功能的云单元组成。云模式通过单元形式实现，并能作为某一类云服务或其用例的模板。

模式并不是个新词，最初使用这一说法的领域是面向对象的软件（object oriented software），并由四人组（Gang of Four）[2]写入论文。他们将软件的模式定义为可重复使用且用于提供问题解决方案的对象，并指出模式具有四个核心要素：

1.模式名称 定义调用模式的通用词汇表。

2.问题说明 描述在何时、基于何种情境应用此模式。

3.解决方式 描述组成模式的各个元素（此处即指云单元名称）、它们之间的关系（下节中会对此展开阐述）以及各个接口。

4.应用结果 应用该模式的成本收益与影响（在我们的讨论中即指模式中的价格与效用模型）。

表3中以四人组的分析框架来描述案例中的网络服务模式。

表3的形式可以用于阐释任一具有特定用例的云模式。在第6至9章中，我们会看到创建云服务模式的过程中，可供使用的用例模式琳琅满目，而这些模式都是由一个个云单元拼接而来。

第三章 云计算：范示的转移？

读完前两章后，你已经明白了云计算是什么、能够做什么。本章中，我们将回过头来，提出几个难于回答的问题：为什么使用云计算？它能给你带来什么？云计算有何特别之处？它将如何影响你、你的工作以及整个社会？

微软视窗系统（Microsoft Windows）已在家庭与工作中随处可见，改变着生活的方方面面，而云计算也同样代表着范示的转移，在它的作用下，电脑、电脑中安装的软件、公司的IT与财务部门，企业乃至政府的一些部门都可能被取代。

在本章中，我们从三个不同的角度来讨论云计算的范示迁移：（1）社会与个人角度的影响；（2）对工作的影响；（3）对企业的影响。高德纳技术成熟度曲线（Gartner’s hype curve）[3]显示，对云计算的期望已达到顶峰，本章提供了对这些期望的种种预见，而在第10章“向云转型”的内容中，则为实现这些范示迁转提供了操作工具与框架。

社会范示的迁转

我们所称的社会生活，是指你在个人或社会层面上如何使用闲暇时间、如何生活。本节的主题便是云计算如何影响社会生活。为此，我们来看三类可能带来重大变革的云：社区云、个人云、物联云。

社区云

社区云服务于一类具有某种共同点的人群。这一共同点可以是地域（同镇、同州、同一国家或跨国界）、爱好（集邮、钱币收藏等）、语言或利益相关（贸易联盟、童子军、商会等）。是否具有共同点决定了你能否成为相应社区云中的一员。

国际社区云可能由北大西洋公约组织（NATO）、联合国组织（UNO）、欧盟（EU）及其他类似组织界定，如果一个国家属于某一国际组织，其公民就是相应云的成员。云成员可以就共同的利益或事务进行商讨，使用讨论区、即时通信、共享文件存储、视频会议等功能，所有这些都运行在安全环境中。这就是一个PaaS社区云的例子。

类似的，社区云也可以存在于国家层面，应用于医疗、培训、政治、农业等领域，由其收集到的数据可以在隐去个人信息后归总用于提供趋势分析。以医疗领域为例，使用收集到的关于某种疾病的发病率信息，可以实时、自动分析该疾病在特定区域、年龄段、社会或收入阶层的分布情况，这一信息可以免费开放给任何关注整体发病率的研究者，将多种疾病的发病率联系起来，并分析它们对某个相关社区云的成员的影响。另外，此类医疗云可以用于收集传染病传播速度和范围的相关信息，并预测该疾病在一个国家或区域内的传播情况，以便做好接种疫苗或医疗资源的分发准备。

随着互联网和五花八门的同好者网站的兴起，我们已经拥有基于互联网的社区，即所谓社交媒体。从社交媒体向社区云的转变更多是指使用云的弹性与适当的价格模型，因此从个人角度来看，社区云并不太能算作范式迁移。但如果一个社会云是由多个云组成的（云的社区云），就能为其成员提供独一无二的个体化服务，在这种情况下，社区云在更高层面上扮演了服务经纪人的角色，根据个体的背景与兴趣，为其成员提供定制化服务。

个人云

个人云只归属于你，并为你所用。你可能已经使用过这类云，如苹果iCloud、谷歌云盘或微软网盘（Microsoft OneDrive），你可以用其存储文件、电子书、照片、音乐等，并通过任意设备在任意地点进行访问。在未来，还会有大量各种用途的个人云可供选择。总体来说，个人云可以按用途分为以下三类：生活休闲、财务与购物。也许有些例子看上去还遥不可及，但充分展示了个人云的可为之处。

用于生活休闲的个人云

目前已经供过于求的iCloud等存储云就属于此类。在规模经济的作用下，未来的存储会变得更加便宜，可能会出现用于保存电影收藏或视频剪辑的视频流个人云，这就相当于拥有了个人的YouTube视频网站。

其他个人云还包括健康钱包（health wallet），它可以保存你的健康信息，如某段时间内见过的医生、体检结果、与健康检查相关的医药支出等。体重秤、计步器、血压仪等各种设备可以直接与你的个人云绑定，为你提供读数超标的即时警示（尽管这些健康设备绑定与互联网、与云、与物都有关系，但由于它们仅用于监测你的情况或仅与你有关，我们仍将其归类为个人云，而非物联云）。健康服务供应商可以在删除个人信息后归集所有人的健康数据，为你分析出最佳的健身与保健计划，也可以将这些分析出售给健康保险公司，用于预测和你情形类似的个体可能花费的医疗开支。

监控也是生活类个人云的实例之一。汽车可以记录你的驾驶档案并上传到个人云中，涉及的信息包括平均驾驶时速、途经地点、整体驾驶风格（激进或是温和）、发生事故的数量等。现在已经有些车辆能够捕捉此类信息，但只是将其存储在车内，而不是传到你的个人云中，汽车保险公司则能利用这些信息为你提供量身定制的车险方案。另一个例子是智能路灯，它能感应到你在附近，并根据你是否已经缴纳地税或道路税来确定是否为你照明，而未纳税的驾驶者就只能摸黑前进，直至他们采用近场通信（Near Field Communications, NFC）之类的技术进行实时缴费，路灯才会开启。当然，如果纳税者和未纳税者商量好一起上路，这种照明机制就会失效。

用于财务的个人云

如果个人云能获得你的银行账户信息、信用卡交易记录等，就能为你在线提供资产负债表和预算清单。在一个财年结束时，个人财务云可以从政府INaaS云上获取所得税信息，并为你编制所得税表。未来，如果政府机构允许汇寄此类电子税务申报单，云就可以在你的授权下向相关政府部门发送税务报表文件。这样一来，编制税务申报单的烦琐事务就能自动完成，也无须再聘请会计师。个人财务云的另一个用途是整合你在各类养老基金、个人退休金计划、经纪账户中的投资信息，并提供概览信息，从而让你对一段时期内的投资业绩一目了然。

用于购物的个人云

个人购物云可以基于你在所有商店的购物记录，存储你的购物偏好，分析你的购买模式，并通过预测分析及时提醒你应该添置某些商品。它能扫描各类实体店和网店的折扣优惠活动，为你提供采购选择，还能管理你的电子钱包，以便快速便利地支付商品价款。如今，有许多公司都致力于电子支付，部分支付途径还可以整合到你的个人购物云或电子钱包中。

物联云

物联云是用于协助一个或多个生命体来管理或使用一类物品（非生命体）的云服务（这些物品都通过物联网彼此联结）。比如说，你可以为自己的住宅设立云，从安保设备、烟雾传感器、近距离传感器、光感设备等感应装置处获得信息，为你和其他居住者自动控制窗帘、火警、照明、暖气等设备。另外，每一个房间的居住者都可以对何时拉起窗帘、何时开灯等进行个性化设置。在你的工作环境中也可以设立类似的设施云。此类云属于BPaaS，因为它能为你自动管理诸如拉窗帘、监控照明等流程。另一个例子是维护使用情况记录表的会议室云，你可以通过它预订空闲的会议室时段，它还能通知安保、餐饮等服务提供方，为与会者提供便利或增值服务。多个会议室云可以组成一个聚合云，当其中一个会议室在某段时期不能使用时，就会向你推送其他可选的适合会议室。你可以按一定标准选择会议室，比如房间大小、位置等。会议室聚合云又可以从属于一个复合型的设施云。上一章中题为“云关系”的小节在物联云中具有重要地位，物联云之间通过多种多样的关系——包括封装、联合、复合、聚合——来组成新的物联云。

工作范式的迁移

日常办公中，有两大趋势正在发生：

工作站被瘦客户端或零客户端取代。

使用任意设备，随处完成运算。

工作站（台式机和笔记本电脑）正在由不安装应用程序的机器取代，如果这些机器的操作系统是内置在硅晶芯片中，就被称为零客户端，而需要在硬盘中安装操作系统的则称为瘦客户端。要避免在工作站中安装应用程序，就得通过瘦客户端或零客户端上运行基于云端的应用。托管这些应用程序的云可以具有不同的部署模型：私有云、公共云、社区云或个人云都有可能。一般来说，对于Office办公软件或电子邮箱等工作效率类应用，可以使用公共云服务，而针对个人定制式的应用，则使用私有云服务为好。这些应用也并不是必须托管在云端，同样可以使用传统的物理计算或虚拟计算、托管在数据中心的服务器上。只要你能接入网络浏览器，就能访问并使用这些应用程序，而不必关注底层采用了何种技术。采用零客户端或瘦客户端运算环境的好处在于，公司IT部门不必再对大量各类工作站上安装的软件进行管理，而只需管理一个云软件，或者第三方云服务提供的软件接口。由于工作站中并不包含任何本地硬盘或数据存储设备，全部采用云数据存储，由此实现了工作信息集中存储，从而使数据更加安全。即使工作站丢失或被窃，也不会危及公司数据。而且零客户端或瘦客户端更换起来也没那么昂贵，因为大部分应用托管、存储、运算都通过云端进行处理。

随处运算始于那些需要为学生带入校园的电子设备提供服务的大学。要为学生的各类设备提供应用与信息接口，意味着大学的IT部门需要提供一条安全的路径，允许他们无法管理或控制的设备来访问学校资源。随着技术发展，这种“自带设备”（bring your own device, BYOD）的方式逐渐盛行，被企业广泛采用来为雇员提供IT服务。但随处运算的意义绝不仅限于自带设备，这意味着你能在任意地点、任意时间、使用任意设备获得并处理公司信息，而不必身处校园或办公室。这一运算方式使IT部门越来越接近于云服务经纪商，维护许可范围内的云计算应用服务目录，以便员工在工作需要时使用。基于云端的应用程序可以在任何地方、任何时间、任何设备上使用，需要在本地使用或存储的数据都保存在设备中的一个安全区域内，这个区域被称为“沙盒”（sandbox），沙盒在你受雇时创建，离职时即被删除，只有经获得许可的应用才能对其中的数据进行访问，也可以选择对数据进行加密处理。

机构与商业范式的迁移

大部分企业都设有IT部门，用于集中管理邮件服务器、网络服务器等应用程序，部分IT服务的业务关联性更强，直接涉及产品或服务的交付过程，因此会由业务部门或团队来实施。这就像一个轴辐模型，中央IT管理犹如主轴，而各类业务团队则像辐条一样在周围自主开展工作。如果中央IT部门对于业务部门或团队使用的应用程序并不知情，这些应用软件以及安装它们的电脑就属于影子IT的范畴。这类软件或电脑如果出现故障，能否获得后台支持就是个问题，强势的中央IT部门可能拒绝为影子IT提供支持，而弱势一些的则可能费钱费力来了解系统并提供支持。无论结果如何，影子IT的非标准化特性使其成为潜在的安全漏洞，也会带来额外成本，是公司的一项业务风险。

随着云计算支持的应用程序越来越多，业务部门对影子IT的依赖程度也越来越高，支付门槛也有所下降，如图10所示。而云计算抽象层级越高，影子IT管理及支持相关的技术要求就越低，从而有助于降低成本。在一家公司中，几乎所有的IT功能都可以转到云端，为了生存，中央IT部门也需要向云服务经纪人转型。此后再涉及IT功能时，业务部门就能以半自主模式开展工作，现在所称的影子IT也得以摆脱“影子”之名，成为主流模式。由于大部分IT及运算资源都会作为服务性采购，或者随用随付，定位为云服务经纪人的中央IT部门也会逐步成为采购部门的一个专业化分支。云计算使IT逐渐商品化，而相关技术的发展又将降低IT采购与使用所需的技术门槛，如图10所示。IT部门的功能将会演变为云服务合约及目录的维护者，目录中列明了云服务供应商各项服务的具体内容。

那么在选择将哪些云服务列入目录时，IT部门应当如何评估这项云服务的价值，如何比较各家供应商的计价机制呢？我们将在下一章的价格与效用模型中讨论这些问题。

第四章 价格与效用模型

任何事物都有成本与收益两面，云服务也是如此。本章考虑了使用云服务的成本因素，以及在评估各类定价机制（即价格模型，也称为定价模型）后的所支付的实际价格。为使物有所值，云服务应当能实现相当收益，这种收益可以用云计算效用模型进行评估。了解价格与效用模型有助于对各类云计算服务进行客观比较，本章结尾处对各种财务特征有所讨论，以便你从财务角度对云服务进行评估。

价格模型

价格模型是确定获得商品或服务所需对价的一种方式。云服务供应商先使用成本模型计算提供并运营云服务的各项成本，然后将成本模型转化为价格模型，并根据自身的商业模式、市场战略和预期营收来从中选择。要对客观比较云服务，就必须了解各类价格模型。

所有价格模型都脱胎于成本模型，后者是云服务供应商创建的一类财务模型，用于明确特定云服务在设立、运行、三年后的更新迭代等各阶段中需要多少开支。一项技术通常在三年后就会过时，而五年一般就是使用上限，需要云供应商进行技术更迭。成本模型会考虑通货膨胀、汇率变动（如适用）、折旧、电力成本（这一项可能开销巨大，毕竟有大量服务器需要用电及制冷）、场地成本、软件授权成本、人力成本和购置运行服务器的资金成本。所有成本加总，再计入利润和风险因子才组成价格。价格包含两个部分：非经常性费用（nonrecurring）和经常性费用（recurring）。非经常性费用的现值可以通过摊销拆分成一系列现金流，从而转化成经常性费用（这种算法会在本章末尾“现值”一节中说明）。在经常性费用的基础上再加入非经常性费用的摊销现金流，就得到了提供服务的月度价格，以价格模型的形式体现并用于云服务的销售与市场推广。

现有的价格模型多种多样，大致可以归为四类：效用导向模型、服务导向模型、表现导向模型和营销导向模型。目前来看效用与服务导向价格模型最为常用，但财务与商业创新还在不断追赶着技术创新的脚步，各类模型不断涌现，现在还不常用的模型也可能在将来盛行。在对下述价格模型充分了解并权衡选择之后，你还可以按自己的私有云、社区云或混合云所需，自行设置特定模型。

效用价格模型

效用模型是一类计量式的价格模型，通过监测你的服务用量来计算所需支付的金额。这一模型源于公用事业公司的定价方式，定期（常为月度）向云服务供应商付费。此处介绍三类效用价格模型：基于消费、基于交易和基于订阅。

基于消费的价格模型

基于消费的价格模型常用于IaaS和PaaS。你为自己占用的计算资源付费，例如存储量（单位为兆字节或千兆字节）、运算或处理能力（单位为中央处理器周期数或处理器内核数量）、内存（单位为兆字节或千兆字节）等。服务商按日、按周或按月对这些资源的平均占用水平进行计算，并基于这一平均用量对你收取费用。这一模型十分粗略，对于SaaS、INaaS或BPaaS的计量效果不佳，而这些资源关系到企业日常运营，相应支出得合情合理。比如一项INaaS服务为你提供最新的税务法规，你根本不会关心传送信息使用了多少中央处理器内核或者多少内存。而对于云服务供应商来说，服务成本中还含有其他成分，包括应用程序许可、数据收集、维护成本等，因此对于SaaS、INaaS、BPaaS来说，其他价格模型可能更为适合。

基于事务的价格模型

基于事务的定价中，事务取代了计算资源作为计价基础。这里所称的事务可以与业务相关，如BPaaS中的收据处理流程，在INaaS中是与数据相关，而在SaaS中则与应用程序相关。IaaS和PaaS中也可以使用基于事务的定价，比如将带宽作为运算资源使用量的指标，从而只需测算完成每笔事务所占用的带宽，就可以将基于消费的价格模型转变为基于事务的模型。

将一定时期内的云服务提供成本除以事务处理量，就能算出处理一单位事务需要的成本，这就是事务处理量的单位价格。这种价格模型在以下场景中较为适用：

事务量已知，并可以预测。

处理单次事务的业务流程可以清晰界定，并以整数单位进行计量。

事务处理量与成本要素挂钩。

从云计算服务商的角度看：业务流程由事务驱动，并能够标准化。

基于事务的定价对于INaaS和BPaaS抽象层最为适合，同时适用于所有云部署模型。

基于订阅的价格模型

和自助餐厅的付费模式类似，在基于订阅的价格模型中，你只需按期支付固定费用便可使用服务，一般为月费形式。举个例子，如果你订阅了一份杂志，无论你是读了其中的全部文章、部分文章还是压根儿没看，都需要定期付费。随着在线杂志和新闻端口的兴起，内容更新变得非常频繁，不像纸质杂志那样内容量固定。鉴于你的阅读能力无法跟上新内容的生产速度，对这类服务的订阅就类似于自助餐模式。有时还需要承诺在一定期间持续订阅。对应到云计算中，这种模式意味着不管你是否实际使用分配给你的计算资源，都要为其支付月费。而如果你决定不再使用该项服务，需要提前一段时间告知服务商，比如三个月。基于订阅的定价方式可应用于所有云部署模型和抽象层。

服务价格模型

服务模型以你获得的收益作为向云服务支付价格的标准，比如实现服务层级协议、转移风险、节约金钱等。一般来讲，固定价格模型适用于风险转移模式，而数量模型和分层模型则主要为云用户提供金钱和服务方面的收益。

固定价格模型

指按年、按季或按月为服务支付固定价格，其中包含两部分：经常性和非经常性价格。后者是在初始时一次性支付，而前者则按一定频率定期支付。如果你的使用范围界定清晰，并与短期目标匹配，一般会选择固定价格模型。这种模式可以转移与服务交付、人员和服务质量相关的风险，但还存在服务范围的风险，即需要对使用多少服务量、使用到什么程度做出决策，这种风险转移通过你与云服务供应商议定的服务层级协议来实现。固定定价方式适用于所有云部署模型和抽象层。

基于数量的价格模型

模型中的“数量”可以是用户数、存储空间容量、事务处理速度（定义为每分钟或每小时的处理数量）、带宽或处理能力等，可以选择任意一个作为云服务的定价参数。由于数量会受时间、经济周期、市场营销事件等影响而波动，价格也随之具有周期性变动，因此有必要对数量进行定义、测算及评估。比如你的雇员正通过瘦客户端使用一项按数量定价的云运算服务，定价基础可以是每日的平均用户数、高峰期用户数、分配用户数或实时用户数，也可能是上述参数的结合。如果使用其他类型的参数，也需要进行类似的考量。尽管基于数量的定价多用于IaaS和PaaS，但在其他抽象层中也同样适用。

分层价格模型

分层价格模型基于不同的服务层级协议、数量、消费额等要素，来制定分层定价表，这和航空公司的会员等级制度相仿，即以你在该航空公司的飞行消费额来决定会员级别。在云计算中也有类似的定价机制，当你的年消费额达到一定水平时，就可以享受更大的折扣。另一种情况是按照服务层级协议的内容来分层，协议越严苛，你需要付的价格越高。比如说，服务供应商可能会准备三个服务层级协议，分别对应不同价格，你在协议中的获益则逐步递增。分层机制也可以基于所服务的用户数量等量化参数，比如说你的公司要求云服务供应商为员工提供存储服务，以便他们能随时随地地在任意电脑上存取文件。供应商可能给出三个价格级别：用户数量低于100人的，价格为每人每月5美元；用户数量在100到1000人之间的，价格为每人每月4美元；用户超过1000人的，价格为每人每月3美元。基于数量确定层级并赋予不同定价的方式就体现了分层定价模型的思路，而确定层级的基础既可以是数量，也可以是服务层级协议或消费金额。分层定价可用于所有云部署模型和抽象层级。

表现价格模型

表现模型是一种基于基准值的模型，价格由关键指标或称基准值来确定。大多数表现模型用于对员工的绩效酬劳评定，或制定外包相关的价格策略，但也可以应用在云计算特别是私有云或混合云中。有时可以通过这类模型，将公司与其服务供应商的目标结合，形成实质上的合伙关系。

表现价格模型具有一些共同特质：

需要能够明确定义并且容易测定的产出指标。

该指标通常与某项与其影响直接相关的业务流程或成果挂钩。

我们将基于成果、业务挂钩、利益共享这三类价格模型归类为表现模型。

基于成果的价格模型

如果你的部门希望使用云计算来减少市场营销（这也是七大效用模型的要素之一）所花时间，就需要与云服务供应商议定某个与该结果挂钩的“奖励”费用。多数成果模型会使用与云计算价值相关的指标，这些指标会在后文关于效用模型的内容中提及。基于成果的模型与其他表现价格模型存在一定心理上的差异，前者是在目标达成时给予额外奖励，而后者是在一项服务层级协议或目标未能实现时对供应商进行惩罚。基于成果的模型经常与其他模型共同使用，比较常见的是固定价格模型，从而通过额外奖励来体现价值导向。

业务挂钩价格模型

基于成果的模型使用一定指标来衡量云计算的价值，而业务挂钩模型则衡量云计算对影响商业模式的关键绩效指标（KPIs）的贡献。如何将业务成果与云计算的贡献挂钩是其中的一大难点，图11展示了一种可能的映射方式，即以图12~18中描述的效用模型来体现云计算的应用目标，并与反映业务成果的KPI进行对应。

利益共享价格模型

利益共享模型来源于对员工的绩效激励机制，基本思路是当机构获得收益时，拿出一部分来与员工共享。典型的利益共享型机构会评估自身表现，并使用预设的公式来向所有员工分配利润。在这个过程中，机构需要将真实表现与历史平均表现（标准或基准表现）比较，以此确定收益水平。在云计算背景下，如果服务供应商的表现超过服务层级协议约定的水平，你就与其分享利润以资奖赏，而不是在达不到服务层级协议时进行惩罚，这属于不同心理层面的激励机制。不过，你也可以将利益共享模型和基于惩罚的表现模型相结合，设计成混合表现模型。

营销价格模型

有些价格模型的驱动因素是市场营销，而非服务表现。这类模型的核心驱动力在于吸引尽可能多的用户，然后通过货币化创造收益。本节中我们将讨论两类营销导向的价格模型。

免费加增值价格模型

免费加增值的模式有两类，一类是先免费试用，再购买高级服务，另一类是提供免费服务，通过广告收入弥补服务价格。这一模型尤其适用于SaaS，诸如领英（LinkedIn）、Dropbox之类的很多软件公司都在使用。他们提供功能有限的免费版产品，用户可以选择购买具有更多功能的高级服务。其理念就是在免费版中提供足够价值，以吸引并保有用户，同时在高级版中提供附加价值，保证最大限度将用户转化为服务供应商的收入。

剃刀与刀片价格模型

这种定价模型有赖于两种部件，一种是基本部件，另一种是可重复使用部件，两者需要组合使用才能完成一项服务。这就好比向你廉价出售甚至免费赠送剃刀，而通过销售刀片耗材获得补偿。打印机也是一例，它们本身价格低廉，但通过打印油墨得到了弥补。在云计算中，搭载云服务的设备或应用可能会免费分发，但云服务在提供数据存储、分析和呈现功能时收取的费用就覆盖了设备成本。比如你有一台血压监测仪，可以自动向云服务上传数据，由后者进行存储和分析，一旦超过特定血压水平就向你报警。监测仪可能是免费或折价销售给你，但你在使用云服务时需要额外付费，这样监测仪测得的信息才有意义。另一个例子是亚马逊的kindle终端，它可以作为虚拟商店的入口，用于购买各类商品；kindle设备按折扣销售，一直有亏损之王的称号，但它带来的店铺销售额增长已经弥补了自身价值。

混合价格模型

前文中讨论的效用、服务、表现价格模型并不互斥，它们也可互相组合成混合价格模型，比方说，你使用的系统可能采用分层订阅的方式，如果每年支付的费用达到一定水平，就可以适用对应层级的折扣率。另一种方式是将固定价格模型的风险转移特征与效用价格模型的可负担性相结合，为用户提供固定的月度价格，用户在支付月费后就可以无限量使用服务。这类混合价格模型在公共云服务中十分常见，如谷歌文件、微软办公365等。事实上，这种定价模型很适合大型或者长期服务，特别是在需要持续优化的情况下。混合价格模型可以有效应用于所有云抽象层级和部署模型。

效用模型

效用大致是指用户从服务中获得的收益扣除成本。你在服务层级协议中列明或获取的即为总收益，从该收益总和中减去云计算的成本，得到的就是效用。估值过程本质上就是计算收益减去成本的分析过程。

不同原理形成了不同类型的效用模型，如用户期望效用模型、位置效用模型、客户效用模型等。在云计算中，效用模型指用于界定云计算对用户价值的标准化模式，并对类似情境下的用户通用。根据云计算的收益类型不同，我们在图12~18中展示了七类效用模型：（1）运营支出；（2）缩短上市时间；（3）价格灵活性；（4）用户需求灵活性；（5）位置灵活性；（6）资产优化；（7）提升利润。

为提供计算服务，IT部门需要通过前端资本投入来创建并维护服务，而为始终满足服务层级协议要求，还需要增加额外运算能力，这些资本支出原本可以用于寻求其他业务机会，因而构成机会成本。另一方面，如果实际需求超过你所投资的运算容量，超出部分需求就无法被满足，或者说降低了服务层级协议的效力，最终都会造成商业机会的流失。图12所示的云计算运营支出模型则以其弹性来避免机会成本和商业损失。

图12中上斜的运算能力曲线包含两个互斥的假设：业务需求将持续增长，云计算能随时间发展出更高的自动化水平（即弹性与资源）。

所有产品或服务都有其生命周期，包括研发、测试、发布、推广和常规使用阶段，每个阶段对运算能力的需求不尽相同，从而构成需求的峰谷期。要满足这些需求，你就得通过资源投入与撤出来不断调整运算能力，但难免会有无法满足需求的时候——特别是在产品的发布和推广期。图13所示的云计算需求灵活性模型运用弹性技术，来确保满足产品整个生命周期中的各类运算需求。这意味着你在运算能力中的投资——即运算服务价格——会随着产品生命周期中的需求变化而调整。

由于新技术的更新换代快速而常态化，无论是传统计算还是云计算，运算资源的价格都在不断下降。这种下行趋势的另一因素是原有技术逐步被淘汰，新技术的使用范围扩大，从而形成了规模经济。云计算允许你在需求改变时换用不同的价格模型，从而在价格下行曲线上更进一步。比如说，在使用量较低时，消费价格模型对你最为有利，而表现价格模型则在高使用量时更为适用。无论是使用同一云服务供应商，还是换个新的，只要有权力更改价格模型，你就能在同等开支下获得更高收益。图14中描绘的是云计算价格灵活性效用模型，它能在需求、使用量和环境随时间变化时，使用不同价格模型来降低计算成本。比如在分层模型和混合模型中，云服务供应商在使用量增加时给予你更高折扣，从而可从中获益。

如图15所示，云计算的上市时间效用模型能使你更快实现在不同运算环境间的切换，从而缩短进入市场的时间。你不必像使用传统运算时那样，提前花时间设置运算基础设施和环境，现在的计算资源几乎是即时的，随时可用于部署业务应用或服务。

图16中为云计算的位置灵活性效用模型，由于计算的随处可得性，你可以从任何位置接入计算环境并开展工作。这种灵活性能提升你的工作效率，同时还能使你获得全球影响力。

图17中所示的云计算资产最优化效用模型与图13中的需求灵活性效用模型类似，只是角度略有差异。图13考虑的是产品生命周期中可能造成业务损失的未满足需求，而图17的侧重点则是为增加处理能力，避免业务损失而需要投入的额外资源，更确切地说，是企业要阻止的因缺乏运算能力而受到的声誉损失。除了资本投入之外，在服务临近结束时，你还会剩下一大堆计算设施，既占用空间，又消耗现金流。上述结论都假定了影响投资决策的资产寿命与产品寿命紧密相关，从而可以运用云计算来优化资产配置。

利润水平

当你制造商品或提供服务时，每当累计产量（也即积累的经验）增长一倍，增值成本（包括管理成本）就会下降25%，从而形成下斜的价格曲线，即利润随着经验的增加而上升，这一价格曲线被称为经验曲线。云计算利用了传统计算积累的经验，在此基础上不断进化，从应用角度看甚至有革命性的变化，从而将传统计算的经验曲线向右侧推移。这就改变了外包云计算服务的盈亏平衡点，进一步提升了利润水平。图18反映了上述过程，这是波士顿咨询公司（BCG）经验曲线的修订版，以利润取代了原曲线中的成本。事实上，云计算的价值之一就是基于经验曲线效应，能比传统计算方式更加有效地提升利润水平。

财务指标

如何将云计算提供的效用转变为有意义的财务指标呢？有多种财务标尺可用于衡量云服务的价值，四种常见指标如下：回收期法、净现值（NPV）、投资回报率（ROI）和上市时间（TTM）。当然还有其他方法，如经济附加值（EVA）、资产回报率（ROA）、净资产回报率（ROE）等，但这些指标一般需要在公司层面整合运算数据，因此依赖于公司税率、KPI等因素，在评估单独服务、产品或项目时就很难使用，所以此处不做深入探讨。

回收期法

回收期法衡量的是一个产品或一项服务收回投资所需时间。如果一项服务的回收期较短，就被认为优于回收期较长的同类项目，如下例中所示：

假设你以每个月1000美元的价格购买一项云服务，从而对付款单的处理速度能提升到原有系统的两倍。

在一年期间，花费为12,000美元。

如果原有系统每个月能处理价值10,000美元的发票，则新系统可以处理的付款单价值为20,000美元。

由于新系统的速度提升到原有的两倍，新旧系统的差距就是云服务的价值，即每个月10,000美元。

假设一个月有30天，每天产生的价值就是333美元付款单。

也就是说，新的云服务在36天（等于12,000/333）后就能收回成本。

回收期法一般更适用于资本项下开支，因为能将投资折旧到数年中，本例中所说达到12,000美元投资额所需的就不是一年，而要改为资产折旧期限。而对于运营项下支出来说，可能存在与云服务供应商约定的锁定期或合同期，可能达到上述计算中所说的一年。

回收期法的缺点之一是没有考虑资金的时间价值，如果在高利率水平时期，或者投资期限较长，就会对投资计算带来重大影响。在此情境下，通常使用净现值（NPV）计算。

投资回报率

回收期法考虑的是回收投资所需的时间，而投资回报率（ROI）则是计算回收额占投资额的比重。IT行业广泛使用ROI来评估资本投资，公式是：

ROI=（投资收益-投资成本）/（投资成本）

在每月开支1000美元的云服务案例中，ROI按下述方式计算：

投资的收益是每月价值10,000美元的额外付款单处理量。

投资成本是每月1000美元。

则ROI=（10,000美元-1000美元）/1000美元=900%

本例中计算的是未经调整的ROI，即将所有收益与成本都当作现值处理，其假设是所有收益与成本都是发生于初始时点，而事实往往并非如此。要得到更为真实的ROI数值，通常需要通过净现值调整，即扣除货币的时间价值。

净现值

如果有多笔定期产生的现金，就可以称之为现金流，而如果这些现金流都是等值的，则称作年金（annuities）。由于通货膨胀和利率的影响，下个月流入的1000美元现金的实际价值要比50个月后收到的等额现金更高。要评估一系列现金流的当前价值，我们可以采用净现值计算。一项投资的净现值就是所有未来收益的当前价值，即将投资产生的现金流，扣除初始成本后，按照时间分布进行折现。比方说，你在未来三年内每年都会收到1000美元，利率是10%，你就可以按图19中的利率将这些现金流折现，加总后算得现值为2486.85美元。如果你为获得这些现金流所投入的初始投资为2000美元，则在折现值中减去初始投资，就算得净现值为486.85美元，这表示2000美元投资的利润率为24.3%。

尽管净现值分析往往用于验证资本支出的合理性，你也可以用它来反向计算，把资本支出转化为经常性支出。也即，净现值法提供了将资本项下支出与运营项下支出进行双向转换的途径。使用净现值分析有两点优势，一是由于考虑了货币的时间价值，结果相对精确；二是解读结果较为容易：正的净现值意味着投资有利可图。净现值的另一优势是在折现率中内含了机会成本，如果预期回报率低于最低要求回报率，或低于理想的回报率，你就不会做出这项投资。而在那些已超过最低要求回报率的候选项目中，回报率最高者所提供的就是最优机会成本。

回到我们处理付款单的例子中来，云计算的每月成本为1000美元，假设年利率为5%，我们决定使用这项服务至少三年，月度成本开支可以用净现值分析表示为资本项下支出：

月利率=5%÷12=0.4167%

时长 = 36个月

每月支出= 1000美元

未来价值= 0

现值= 33,365.70美元

即使用一项每月费用为1000美元的云服务，三年成本的现值为33,365美元，将这一数值与IT部门提供的自建运算平台成本相较，成本较低者就值得投入金钱与时间。

上市时间（TTM）

另一种可供使用的财务标尺是估计产生收入所需时间。举个例子，假设在采用传统计算方式时，你研发的一项产品需要一年才能面世，而改用云计算后只需要三个月时间，则TTM就是提前九个月。如果新系统会带来每个月20,000美元收入，则TTM提前就意味着180,000美元额外收入。因此，你既可以用时间单位体现TTM，也可以用货币等价物来衡量。

第五章 安全与监管

安全是个全局性的问题，不仅是为使用云服务的你着想，对服务供给方、服务的应用载体以及允许访问服务的设备也都有益处。同时，从用户到数据中心再回到用户的过程中，还涉及数据完备性及隐私问题。在本章中我们会讨论上述问题，还有关于数据及其使用过程中的合法合规性问题，并将把讨论延展到数据主权与司法管辖权上，这也是云服务使用者格外关注之处。最后以一个简明的词汇表结束本章，其中列出了安全领域的常用术语，在这些知识的武装下，你与云计算供应商的沟通就会更为有效。

什么是IT安全

IT安全为计算机系统及其存储或操作的数据提供防护，保障它们的保密性、完整性和可得性（confidentiality、integrity、availability），这三者常被合称为“CIA”，并已经演化为下列六个特征，也被称为“帕克六要素”（ Parkerian hexad）。

保密性：明确哪些人可以获得哪些信息。比如说，公司关心如何保护自己的知识产权，而个人则更关注自己的财务或医疗记录是否有未经授权的访问。

拥有或控制：明确谁或哪一系统具有信息的所有权，或者对信息的使用具有控制权。

完整性：指数据正确或与其使用意图一致。对数据任何未经授权的改动，无论出于有意还是无意，都是对数据完整性的破坏。

可靠性：指数据来源或创建过程的真实准确。

可得性：指在需要使用时，能够及时访问信息。

有效性：指有实用价值，信息可用且实用，能由用户按其意图使用。

可得性

云计算的特征之一是随处可用，这就印证了云计算资源的可得性，因此我们特别对可得性进行进一步讨论

可得性包含几方面内容：

1．这项服务是否可以从其他地点获取？

2．当你想要使用时，它是否已经准备好？

3．是否会因维护安排而在特定时段无法使用？

4．如果运行服务的云平台发生故障，需要多长时间才能修复？

5．修复后，是否会有数据丢失，如有，丢失的是多长时间内的数据？

后两项的衡量指标分别为恢复时间目标（Recovery Time Objective, RTO）和恢复点目标（Recovery Point Objective，RPO），两者都是以小时、分钟等时长作为单位。第三项与停机时间相关，一般以百分比表示，计算公式如下：

可得性百分比=100×（一段时期内的停机时长）/（一段时间的总时长）

列表中的前两项无法量化，但应在你和云服务供应商签署的合约中明确。服务层级协议中应当明确可得性的量化指标，并作为与云服务供应商之间协议的一部分。

CIA或帕克六要素中每项都能用数值来表示其严格性，比如1代表较不严格，2代表中等严格，3代表非常严格，等级的划分可能是非线性的。以可得性为例，等级1中RTO和RPO均为24小时；等级2中RTO为24小时，RPO为1小时；等级3中RTO为1小时，RPO则为0。假如你需要RTO为24小时，RPO为2小时，则可以选用本例中的等级2，即符合要求的最低等级。同样，如果你对保密性和完整性的要求分别为等级1和等级3，则你的安全性要求在CIA体系下就可以表示为1-3-2。你也可以用帕克六要素来表达安全需求，比如2-3-2-1-3-1。

加强安全

一次IT安全事故可以由上述帕克六要素来表述，这些要素具有两个特性：不可分割、互不重叠——不可分割意味着它们无法切分为更小的组成部分，而互不重叠是由于它们指向信息安全中的特定方向。我们对IT安全的定义会引出一系列追问：由谁定义哪些行为属于按意图使用或非恶意使用？如何确定数据对安全性要求的高低？谁在使用数据，是哪些数据？处理数据需要用什么系统？数据在何处及如何储存，如何被系统调用？我们按最优做法来尝试回答这些问题。

云服务的用户可以是自然人、流程、应用程序或运算设备之类的系统，应援前来解决问题的技术支持人员也被归类为用户。如果跟踪数据流轨迹，可以看到数据从用户处产生，通过网络到达安装了软件的运算系统，该系统对数据进行处理，并将其保存在硬盘等存储设备，然后在备份设备中进行备份，一段时间后最终归档到档案系统中。标出处理数据的节点和基本信息，分别为用户、运算系统、软件、存储设备、备份设备、档案系统。从用户角度出发，这整个数据通路都应接受安全防护，而用户对隐私、数据完备性、安全性的要求则是其他要素对应的安全指标。

下面以归档流程为例，说明数据通路中的安全防护安排。档案系统需要以安全方式存储数据，防止来自未经授权用户的访问，而即使他们获得了访问路径，也无法解读加密信息。同样，备份过程也应以安全方式进行，数据从备份系统向档案系统转移的过程亦是如此。上述数据通路中的任一节点都必须共用相同的安全特征，这些安全特征以CIA或帕克六要素来表示，并与用户要求相符。由于数据从一个节点到另一个节点的过程需要受到保护，因此完成数据传输的通道也必须安全。

安全容器（Security Containers）

云计算环境中，所有为某一特定用户服务、安全特征相同的节点就具有同一安全边界。边界内的运算节点彼此信任，而安全边界形成的环境就称为安全容器，因此无须再为接触数据的各个节点分别定义安全边界，而通常采用分区段方式创建一个容器，其中包含所有共享安全属性的节点。鉴于信息通过网络传输，因此通常将这一区段置于网络层上。具体做法是在物理网络上建立多个虚拟网络，每个容器各自使用内部虚拟网络，从而令其他容器（处于外部）无法访问其内部数据。为进入某个特定容器，一般要经过三个安全程序：识别、认证和授权。

识别是指确认用户的身份，其中的用户是指希望连接到云或其安全容器的自然人、应用程序、系统或“物”。

在用户识别完成后就可以进入认证程序。认证用于判断用户是否为合法用户。常见的依据为你持有的证物或所知的信息，持有的证物可能是智能卡、指纹、语音等，而所知的信息可以是密码或个人标志号码（personal identification number, PIN）。

授权是确认可由已认证用户运行的任务，按照已认证用户在云计算环境中的角色，确定赋予其何等权限。授权一般在认证环节完成后进行。因此，识别程序询问“你是谁”，认证程序询问“你确实是你自称的人吗”，而授权程序则会询问“你在云计算环境中被允许做什么”。

云计算用户的一个共同关注点是云端数据可能会被存储在用户居留国以外的国家，这关系到被存储数据的司法或监管管辖区。如果数据被盗用，应该适用哪一国家的法律或数据保护机制？这一顾虑十分现实，因为云计算的弹性特征允许数据存储等计算资源随处移动。也就是说，云系统可能在一个国家运行，而用户来自于另一个国家。为解决这一难点，我建议在定义安全容器时，除了CIA或帕克六要素，再增设一项管辖区特征。即数据分区并不仅限于数据中心内部，而是发生在提供云服务的任意区域，其中隐含的假设是安全容器使用虚拟广域网，而不是虚拟局域网。这样就可以在CIA或帕克六要素中加入“管辖区”（jurisdiction）的首字母J，并按照法律或监管的要求界定其含义。

监控

检测安全漏洞的第一道防护机制是防火墙。每一个安全容器的边界内都会放置数道防火墙，云本身作为一个安全容器，还具有一道外部防火墙。在一类较为少见的情形中，安全容器内还嵌套有安全容器，数据流需要穿过重重防火墙才能进入。防火墙通过内置规则判断哪些数据可以通过，哪些则会被拦截。如果有人试图进入安全容器并被防火墙拦截，你就能收到通过邮件或监控日志发出的警告。不过一个安全系统包含的部件并不止这一种，除防火墙外还有用户认证与识别、入侵监测与防护，以及反病毒、反木马工具等基于用户的安全设施。在适当的配置下，此类系统会持续跟踪用户和对用户提供的服务与数据，并生成日志。由于日志内容会飞速增加，不可能依靠人工查阅，因此需要使用软件来分析服务器与防火墙日志，作为监测可疑活动的第一步工作。

第二道防线位于用户认证与识别阶段。如果某个用户或在某项服务中多次尝试登录失败，监控工具就会向云系统管理员发出警告，如果是自动运行的工具，还会阻止该账户或对该项服务的继续登录。此外，如果某一数据流试图使用未授权给该用户的服务，或试图提取该用户正常情况下不需要的数据，就会被判定为可疑，并通过入侵检测系统（intrusion detection system, IDS）进行分析与上报。

第三道防线位于客户处，因为客户端设备本身也需要防范恶意入侵，以免用户的登录数据被盗用去获取云服务。通常的方式是在用于接入云服务的客户端设备中安装反恶意软件，包括反病毒、反欺骗、个人防火墙和防信息记录追踪（cookies）。大多数情况下，云服务供应商都无法监控或配置此类终端设备，但如果使用的是瘦客户端或零客户端，就可以通过中央管理的操作系统来避免这一薄弱环节。

数据完整性

假如你把一封记载着重要信息的信件放在保险箱里，然后把保险箱埋在一个没人知道的地方，信息安全（或说IT安全）问题并未得到解决，而仅是被掩盖了。但如果你把信件放在保险箱里，然后寄给别人，从而只有收信人可以读到其中内容，这就是以安全方式传递了信息。那么如果保险箱被人截获，可能发生的情形包括以下三种：（1）截获者持有或控制了信件，让你或收信人都无法取得；（2）截获者阅读了信件，并利用其中的内容完成自己的目的（比如窃取你的身份信息，伪装成你或侵入你的电脑系统）；（3）截获者偷换了信件，把假信息寄给了收信人。数据完整性意在保证通信渠道及渠道中所传输数据的安全，避免上述三种情形的发生。

当数据在两人（设备）之间传递时，为最大化数据完整性，需要在安全防护中考虑三个要素。终端应当安全——即需要对数据的收寄双方进行认证，保证他们确为其人；传送信息的渠道应当安全，不会轻易被第三方窃取或更换数据（中间人攻击）；数据本身应当加密，不能被第三方轻易解读。这三个要素并不互斥，也常常互相组合来保证数据完整。

接下来考虑的问题包括，如何运用加密技术保证数据完备，如何用校检（checksum）来确认数据完整性，以及数据完整性在数据防损整体策略中的位置。

加密

在传输敏感信息时，为保证所使用的渠道或网络安全，还需要对渠道进行加密，当然也可以对渠道中发送的数据进行加密，但这并非常规做法。以证书方式加密的渠道可以让收寄双方通过可信任的路径进行交流，这种加密渠道被称为安全套接层（Secure Socket Layer, SSL）连接。当双方通过安全渠道交流时，要用到以下握手协议（handshake protocol）：

发送设备使用公共和私人密钥来加密渠道，

最佳做法是使用由受信任的证书作者（certificate authority, CA）签署的有效证书（包含公共密钥）来启动流程，

双方对使用的加密协议达成一致，

协商共享密钥（私人密钥），

接收设备使用公共和私人密钥来对渠道解密。

当握手协议配对完成，双方就用协商好的加密算法和密钥，以安全方式开始交流，从而免受窃听或中间人攻击之扰。

数据加密的概念也与之类似，只不过数据是由云服务进行加密，由你安装的应用进行解密，或者随数据流方向反向操作。数据加密行为主体是应用程序，而不是网络服务器或浏览器。

校验

为对接收到的信息进行鉴真检测，需要以一定算法来计算数据的校验，接收方通过验证数据及校验，来确定接收到的数据是否值得信任。比如你要发一封信给我，就可以另外发送一条信息，说明“全信包含251个词，其中有105个名词、81个形容词，其余为代词或动词；信中包含45个句子和5个段落。”这段信息对信件内容进行了描述，与校验的作用相仿。有许多算法可以对校验进行自动计算，接收方就可以利用其来确认信息的准确性。校验能有效防范中间人攻击，保证从硬盘中提取或从中转设备接收的数据没有被截取并篡改。其另一用途是确保收到的数据没有因无线网络等通信渠道的损耗或干扰而丢失。

数据防损

数据防损是指用于发现、识别、监控、管理、保护数据的系统，所涉及的数据可以是在使用状态、传输状态或闲置状态，也可以位于任意位置。图20定义了上述三种状态下的数据防损范围，并给出每一状态下数据所处的常见位置。这三种状态构成了数据的整个生命周期：创建、传输、使用、存储、提取及最终的销毁。闲置状态数据指的是以字符形式存储在物理设备中的不活跃或半活跃数据；传输状态数据指的是从一个终端向另一个终端流动的数据；而使用状态数据是指正在被持续使用的活跃数据。

作为云服务的用户，你需要避免数据在整个生命周期中的任何损耗，用到的工具包括加密技术（保护数据安全）、校验（验证数据完整性）、监控措施（知道谁曾访问过数据）及管理（确认过期数据在限期内销毁）。

数据隐私性

我们所称的隐私指能用于认定一个人身份的信息，即通常称为“个人识别数据”（PID）或“个人识别信息”（PII），NIST对PII的定义是，关于个人的任何以下信息：

（1）可用于区分或追踪个人身份的信息，如姓名、社会保障号、出生日期和地点、父亲的姓名、生物识别记录；

（2）任何其他与个人关联的信息，如医疗、教育、金融、雇佣信息等。

大多数国家都有数据保护相关法律，来确保数据不会落入未经授权的第三方之手，而这类法律大多包括数据保管指令（data retention directives），如“服务提供者应当在流量数据使用完毕后将其删除或者匿名化”，这是云服务供应商应当遵守的一个指令。然而，同一部法律中也含有无法施行的部分——特别是与信息记录程序相关的内容，现今的网站并未遵守也不打算遵守这样的指令，这就使数据保护法律面临失效，许多服务供应商都不会特别当真。

数据隐私与数据完备性紧密相关。为保证数据的私密性，需要确认在其保存与传输过程中都使用了数据完备性工具。用于加强安全的常用工具包括入侵检测工具、防入侵工具、防火墙、反病毒与反恶意软件工具等，但这些防线常常存在漏洞，一旦被突破，你未经加密的隐私数据就会被人读取。不过，你可以将存储于硬盘、软盘、云存储中的数据加密，即加密“闲置数据”，就算数据因安全漏洞而泄露，其内容也不会轻易被人获取。除了“闲置数据”的加密，你也可以对通过电子邮件、Dropbox之类文件共享工具发给他人的数据或发到自己云存储中的数据进行加密，这保护数据在传输过程中不被拦截者读取。

然而，加密技术和其他数据保护措施一样，只对非政府行为生效。有些政府能够在战略部位留下后门，以便随时获取你的数据，甚至已经在这么操作。驱动程序就属于战略部位，这些程序的作用包括（1）数据通路，如路由器、语音电话（VOIP）服务器和调制解调器等；（2）储存数据，如硬盘；（3）数据安全，如防火墙和入侵检测等；（4）数据加密。这些后门往往被植入设备固件中，用户或软件都不会察觉它们的存在，更不用说对其进行防范。随着物联网的兴起，后门更是变得无处不在，因为接入互联网的“物”中可能就包含留有后门的驱动程序。不过目前只有一小部分（我的猜测是两三个）政府有这种能力。要让你的“物联网”设备含有这类后门的概率较小，方法之一是坚持使用开源驱动程序，软件开发商和工程师如果对驱动程序源代码进行检查，就能发现后门的存在。

合法合规问题

云计算和法律一样，是用于保护好人不受坏人伤害的工具。然而现实生活纷繁复杂，事情不会尽如人意，原因之一是技术的变化比法律更迅速（云计算作为最前沿的技术创新，就是最好的例证），这就使法律文本中存在真空地带，给技术先行者利用法律漏洞的可乘之机。从某种意义上说，不扼杀创新可能是更大的“善”，但这种环境下难免滋生安全隐患，造成对用户的恶意利用，因此某种制衡必不可少。解决途径之一是加强对用户与法律界的教育，告诉他们在技术处理过程中，信息可能被采集、分析与使用。另一方面，应当为技术创新提供如何使用信息的广泛框架性规范，使其有法可依。这对行业团体的意义大于政府，为保护参与者与客户利益，行业团体——特别是金融行业——制定了大量规则。目前来看，遵守全国性、地区性或者国际性的各类规则对云计算来说并不算难，但随着时间发展，当不同国家和地区在各个行业领域都建立了自己的规则，可能就会产生麻烦。一项云服务需要遵守大量法律法规，有些甚至会互相矛盾。行业团体与政府之间需要进一步加强合作，以提高标准化程度。欧盟的金融工具市场指令（MiFID）就是一个例子，有助于监管投资服务、增加竞争及强化投资者保护。法规的最大挑战来自于司法管辖区，如果一项云服务是由位于A国的公司提供，其用户主要来自B国，数据存储于C国，而云服务自身是在D国运行，那么它应当遵循哪国的法律法规呢？在这种情况下，你需要在购买和使用云服务之前小心辨认其司法管辖区，首先了解谁能看到数据、由什么系统处理、哪些软件可以使用服务，然后确定这些人、基础设施、应用软件相应的司法管辖区。

数据主权

与司法管辖区紧密相关的是数据的所有权管辖。如果数据创建过程涉及很多人，或者数据具有多个使用方，那么谁才是数据的拥有者？如果数据经由中间系统或云服务处理，那么又当为谁所有，是数据的创建者、增强数据的中间机构，还是数据的终端使用者？而如果这些参与者都位于不同国家，遵守不同的数据保护与所有权法律，结果又当如何？这些只是数据主权面临的一部分困惑，而云计算随处访问的特点使这些问题表现得尤为尖锐。为此，你需要确保与云服务供应商之间达成数据所有权协议，同时还需考虑司法管辖区对协议破裂时救济机制的影响。

安全问题的全局性

安全不仅是技术问题，也不仅关乎云服务供应商，而是关系到所有人的全局性问题。安全问题包括对计算设备的物理接入、向他人泄露密码（无论是有意或无意）、加强安全政策等。你和云服务供应商都负有安全责任，服务供应商一般负责从基础设施到应用程序与云运行环境之间接口的安全问题，而你则需要负责与云环境交互时，以及使用云环境的应用程序中的安全问题。比如说，你想在亚马逊提供的云服务——亚马逊网络服务（Amazon Web Services，AWS）上安装一个软件，亚马逊就会提供一道名为安全组（Security Group）的虚拟防火墙，只允许流向你的软件的数据通过。安全组的最佳操作是将它们置于安全容器中，每个容器内都由虚拟主机来运行特定软件，这就确保了只有适用于该软件及其虚拟主机的流量才能通过。比如说，网络服务器虚拟机的设置是开放TCP/IP端口80，以允许网络数据流通，而安全组中的其他数据库服务器则阻止网络流量通过，这意味着流量只能经由端口80通过，这一措施能阻止外界使用网络流量攻击你的数据库。而你作为安装者的职责就是保证这一应用程序安全地安装在自己的私有云环境中（例中的应用程序包括网络与数据库服务器两部分）。

任何安全系统中，最薄弱的环节往往是人。我们作为技术的使用者，需要采取一系列预防措施，来保障计算系统持续处于安全状况：

保管好密码；

确保安装反恶意软件（病毒、钓鱼软件、信息记录追踪管理等）工具，并定期更新；

运行个人与路由器的防火墙，来检测与防范入侵；

不要打开可疑的电子邮件或网站。

这些措施能保证你用于访问云服务的设备处于安全状态且不被窃听，你还需要进一步确保传到云端的数据已被加密，即便被第三方截获，也不会被轻易读取。如果你不以安全方式使用技术，那么技术能提供的保护也将十分有限。

常用安全术语

本节将提供安全领域的常用术语，对这些术语及其含义有所了解，就能帮助你在使用云服务的过程中确保自己的系统与数据安全。

访问控制（Access control）保证对服务的访问仅限于已授权用户。

后门（Backdoor）事先植入的代码，使攻击者得以绕开既有安全机制，更容易地进入系统。

生物识别（Biometrics）利用用户的生物特征来登入系统或服务，比如指纹或虹膜。

业务连续性计划（Business continuity plan）采取一系列措施，确保在面临灾难、紧急情况、安全漏洞、攻击时，业务仍能持续开展。

校验（Checksum）用存储或传输中的数据计算得到的值，用于核实所提取或收到的数据的真实性。

保密性（Confidentiality）保证信息仅披露给有权查看者。

保管人（Custodian）正在使用或操作数据的用户或应用程序，暂时对数据负保管义务。

解密（Decryption）将加密信息转换为明文的过程。

认证摘要（Digest authentication）确保用户或客户端程序能提供证据，证明其具有使用系统或服务的密码。

无警戒区（DMZ）指组织内部网络与外部网络（一般为互联网）之间的中间网络区域，作为分层安全模型的一部分，运用网络区段来保证数据在受保护层与不受保护层之间传输。

加密（Encryption）将数据（称为“明文”）经密码转换变为加密格式（称为“密文”），隐去数据的原有含义，以防被他人知晓或使用。

备用密码（Escrow passwords）保存在安全处所（如保险箱或加密U盘中）的密码，在授权人员无法操作时，可由备用人员使用。

不当拒绝（False rejects）指认证系统无法辨认一个有效用户。

防火墙（Firewall）网络中的逻辑或物理断点，用于防范对数据或资源未经认证的访问。

碎片化（Fragmentation）将数据文件分为几“段”或碎片存储到介质上的过程，而不是存储为连续的字符序列。

侦查（Fuzzing）生成规范以外的输入值，对软件进行回归测试，以发现其安全弱点。

完整性（Integrity）确保数据未受到故意或意外修改，在使用时保持准确完整。

完整性星属性（Integrity star property）这一方法使用户无法读取比自有数据的完整性水平更低的数据。

入侵检测与防范（Intrusion detection and prevention）识别并阻断安全漏洞，包括入侵（来自组织以外的攻击）与滥用（来自组织内部的攻击），一般在无警戒区的内外部边界处实施。

网格技术（Lattice techniques）使用安全标志来确认对不同种类信息的访问。

恶意软件（Malware）病毒、蠕虫、木马及任何未经授权的软件的统称。

伪装攻击（Masquerade attack）非法用户或软件伪装成合法使用的一类攻击。

不可否认性（Nonrepudiation）用于证明有且仅有一个特定用户发送了信息，且该信息未被更改的系统。

渗透（Penetration）绕过系统保护，获得对敏感数据未经授权的访问。

嫁接（Pharming）将用户会话转接到伪装的网站或应用上的技术。

明文（Plaintext）尚未加密为密文的数据，或已经解密的数据。

专利信息（Proprietary information）归属于某个组织，并使其有能力开展业务的信息，包括客户名单、技术数据、成本、交易机密等。

风险（Risk）安全风险的计算公式为威胁等级与易损等级的乘积，用于量化安全漏洞发生的可能性。

威胁评估（Threat assessment）识别某一组织可能面对的威胁种类。

木马或植入（Trojans or implants）伪装成无害程序或应用的恶意软件。

用户（User）访问系统的个人、组织团体或自动程序，无论是否经过授权。

病毒（Virus）一段隐藏并可自我复制的电脑软件，通常含有恶意逻辑，通过感染其他程序或应用来进行传播。

蠕虫（Worm）可以独立运行并经由网络将自己完整复制到另一台电脑上的程序，能破坏性地消耗计算资源。

僵尸（Zombie）被恶意软件侵害的电脑。

第六章 用例模式（一）IaaS与PaaS

在开头的两章中，我们讨论了服务模型中的抽象层级。本章会在此基础上讨论IaaS和PaaS抽象层的一般用法、优缺点以及最适合的价格模型。具体而言，我们会论及：

采用IaaS和PaaS部署模型的各类商业案例;

对案例进行道斯矩阵分析;

购买基于IaaS和PaaS的云服务时需要提出的问题。

一个典型的用例是用于明确需求及互动事件序列，以服务、功能或应用软件的形式提供解决方案。而当多个用例具有共同之处，并能通过一个特定解决方案来实现时，就被称为用例模式。这些用例模式可以通过微服务实现，而以云形式标准化后，就称为云单元。也就是说，云单元是用例模式的实现方式。本章涵盖IaaS与PaaS的用例模式，而接下来的章节中会覆盖其他云部署模型。

“向云计算转型”一章中提供的清单与本章关系密切，其中概览式地提出了很多在考虑云计算时可能会提出的问题。请注意，本章中的商业案例较为简化，仅用于说明展示之目的。

IaaS和PaaS的用例

在信息技术中，基础设施包含用于运行软件的计算设备，包括智能手机、iPad之类的平板电脑、手提电脑或台式电脑等，以及所有为计算设备提供支持的组件。以电子邮件为例，要向计算设备发送电子邮件，就得在数据中心设置邮件服务器；邮件服务器是托管在服务器设备上的一类应用程序，它从互联网接收邮件，并通过局域网转递给你。服务器服务于平板电脑、手提电脑等客户端设备，这一架构称为客户端-服务器模型。服务器和客户端需要通过网络连接，因此网络也是IT基础设施的一部分，防火墙、转换器等网络设备亦然。你的邮件存储在数据中心的硬盘中，这些硬盘互相串联成组，以极快的速度同时服务于多个电子邮件账户。硬盘组一般被配置为存储区域网络（Storage Area Network, SAN）设备或网络存储（NAS）设备，不过无须对这些设备过多关注，只需统称为存储设备即可，这也构成IT基础设施的一部分。因此IT基础设施包括终端计算设备（手提电脑、智能手机等）、服务于终端设备的数据中心服务器、存储设备、网络、网络设备。进行发送邮件等日常操作的应用程序也是IT基础设施的一部分，这类应用处于操作系统之上、软件层之下，形成操作系统与其他应用程序之间的集成层，并作为应用程序之间的“胶合剂”，提供通信和数据管理服务，这些集成应用一般被归为中间件，从而也属于IT基础设施的组成部分。

在云计算中，IT基础设施按不同数据粒度被归为两类，所有物理设备被称为“基础设施”，如服务器、网络、存储、计算设备等，而当这些服务器与计算设备由操作系统及中间件相连时，则被称为“平台”。因此，基础设施即服务（IaaS）与平台即服务（PaaS）都是由IT基础设施堆叠成的部分。接下来我们会讨论这两个抽象层的主要用例。之前曾经提过，你可以在PaaS之上写入具有多租户的应用程序，从而构成SaaS，同样也可以在PaaS和SaaS之上加入信息或业务流程，分别构建出信息服务（INaaS）或业务流程服务（BPaaS）。在IaaS之上构建PaaS也是同理，在硬件基础上加入操作系统及中间件即可。

图21展示了基础设施即服务的主要用例，其中一部分会在本章中详细讲解。阅读这些用例时，你会发现它们具有共同主线：IaaS和PaaS对于计算密集型的任务较为理想，如存储、备份（其实就是在另一位置或媒介中的存储）、软件运行、网络主机服务等，这些服务的用户数量存在较大波动，同时需要通用性的后台服务。IaaS和PaaS的这一模式适用于多类用户，业已经成立的学校可以从社区云中受益，而创业企业亦可以采用灵活方式快速走向市场。

计算

假设一个大学院系想要在短时间内解决一个问题，其中包含大量需要运算的方程，比如要对人类基因组进行定位或测序。为完成这一任务，该院系可以建立一个社区云，吸收全球各类大学加入，并让每个成员都为其贡献一份计算资源。由于世界上总有某个地区正处于夜晚，那里闲置的电脑就可以用于处理这个问题，加上云计算的弹性特点，就能保证在任何时间都有稳定的计算资源供给。这类云不受限于单一的数据中心，而是随着计算资源的位置不断旋转，跨越国境，更换多个数据中心。其优点十分明显：通过分享降低计算资源成本，减少计算时间，提高IT基础设施使用效率。不利之处主要在于技术与商业方面：由于网络压力加大，可能需要对网络设备进行更为频率的升级，同时，需要有法律制度来明确社区云中知识产权与数据的所有权。

大学社区云是以IaaS和PaaS解决计算密集型问题的用例之一，另一个简单些的例子是对视频的联机渲染，这类应用不必使用跨地区的社区云，但仍然需要计算密集型的IaaS服务。在这一情境中，由于只在渲染进行的时候才需要大量计算资源，使用IaaS或PaaS云服务会较为理想，这样就只需支付渲染期间的云服务费用，而无须为偶尔才用的计算资源投入购置成本。同时，由于图像渲染的性质使然，你无法评估或预测需要使用的计算量，因此需要用到云平台的弹性。主要问题是，你需要确保连接到云服务供应商的互联网带宽充足，以支持图像渲染需求。

此类云计算的另一个简单用例是将应用程序托管在云端，从而可以通过手提电脑、智能手机等终端设备使用该应用。在这个用例中，你的终端设备应当是瘦客户端或零客户端，这类设备被盗后就毫无用处，更换起来也比台式电脑或手提电脑更为便宜简单。大型组织可以为员工提供此类“低能”设备，并通过这些设备连接到托管在云端的应用程序。这为云服务供应商开启了一种全新商业模式，他们可以免费分发零客户端，但要保证这些设备只能连接到他们的云或应用上，从而收取使用费。这就好比免费赠送剃刀，而通过刀片来收费。

网络托管

网站托管的部分特征如下：（1）你对数据流量情况知之甚少；（2）流量每天、每周、每月都在变化；（3）当有营销活动或产品发布时，流量会出现激增。同时，随着业务扩展，对基础设施的通用需求也同比上升。由于IaaS和PaaS云计算模型具有弹性特点与基于使用量的计费模型，能较为理想地满足此类需求。

存储

由IaaS或PaaS供应商提供的存储往往内置冗余备份，即使保存你数据的硬盘损坏，相应数据也能在冗余盘中找到，并不会丢失。这种存储设备由廉价磁盘冗余阵列（RAID）组成，数据被分割备份到各个驱动之中，磁盘受到持续监控，一旦发现失效，就会被另一个存有完整数据的磁盘代替。对于非技术人员或者小企业来说，在本地安装这样的系统并不太现实，因为需要具备技术能力、监控与专业配置人员。而基于IaaS的云储存能做到随时可用，按用量计价，随处接入，可使用任意设备，是理想的解决方案。你存储的数据可以是媒体文件（图片、音频、视频等）、与自己相关的信息（密码、财务信息、资产信息）、通信（电子邮件或信件）或一般文件【可移植文档格式（pdf）文件、电子表格等】——都是常用文件。主流的商业存储选择包括苹果云服务（iCloud）、Dropbox、谷歌硬盘、亚马逊s3等。

备份与恢复

在写作本书时，我遭遇了一次事故，由于在升级系统盘时更改了系统设置，不小心导致了数据盘无法使用。当时系统盘安装的是Windows 7，而数据盘已配置为RAID储存模式（一个磁盘是另一磁盘的镜像，其中一个损坏时，仍能从另一个中提取数据），我的手稿存在数据盘中，由于备份服务器中存有新近备份，我就重设并格式化了数据盘，然后再尝试从备份服务器将文件复制到数据盘中。这时我遇到了致命的问题：我用于恢复数据的软件只复制了一部分文件，而把所有文件都从备份服务器中删除了。我丢失了所有手稿！虽然我还能恢复部分内容（每一章都保存在单独文件中），但大部分工作都丢失了。如果我使用了云服务作为备份，就不至于落到这般田地。另外，由于我的备份服务器和电脑放在同一地点，还存在发生其他灾难性事件的风险，比如火灾，而基于云服务的备份则是异地备份。基于云服务的备份具有以下缺点：（1）存在安全泄露风险，你的数据可能被第三方获取；（2）云服务供应商的工作人员可能接触你的数据。克服这些缺点的方式之一是使用强加密机制，并将加密后的文件备份。

换个角度说，如果你使用云服务来存储数据，那就最好使用另一个云服务供应商来进行数据备份，原因包括以下两方面：（1）备份位于另一地点；（2）如果其中一家供应商发生停机或停业，你还可以取得自己的数据。在这两个云服务供应商之间需要使用某种补全手段，或者某个简单的备份与恢复程序，来保证数据的自由流通，比如使用FreeFileSync、RSycn、BitTorrent sync等同步软件实现两个存储位置之间的数据同步。现有的商业性备份供应商包括CrashPlan、Backblaze、Spideroak、Carbonite、Bitcasa和亚马逊冰川（Glacier），后者更类似于档案管理方案，但也可以用作快速进行增量备份，前提是你得每个月创建一次，访问也并不频繁。本书结尾的附录对备份机制进行了讨论。

图22中是平台即服务的主要用例，下面对部分用例进行讨论。

数据库服务

数据库是以一种便于快速定位和搜索的方式，将一系列持久性数据组织起来。数据的持久性表现为可覆盖一个应用程序的运行生命周期，或者跨越多个应用程序的生命周期。数据库的典型特征包括（1）紧密性；（2）数据提取与更新的速度；（3）更新性，以保证数据一直处于最新状态，并符合你的使用目的。可以将数据库简单视为一个电子文件系统，其中包括索引、档案文件以及便于访问的组织排列方式。由于数据库是集成在通信层的一部分，作用在多个应用程序之间，允许它们共享并重复使用同一数据，因此被称为中间件。

支持数据库的是保存数据的物理存储系统，因此除了前文讨论的IaaS存储服务之外，还可以在PaaS服务中托管数据库系统，这一“平台即服务”就能为你提供数据库系统云单元。在应用程序提出需求时，需要能简便快速地接入这类数据库服务，因此数据库服务最好和使用它的应用程序位于同一个云中，这样就能缩短传输时间，达到最优表现。这样配置的优点是可以将大部分IT功能置于云端，如应用程序、其数据库和物理存储，如果是网页应用程序，就可以使用网络浏览器来远程操作，而如果是“胖客户端”应用，则要使用虚拟化应用（解释详见第一章）来接入，这也是实现瘦客户端或零客户端计算模型的途径之一。

云数据库的另一优势是它的实用性，各类应用程序都可以将数据库视为开架商店。如果把数据库服务配置为云单元，在每次需要使用数据库时，就无须重新选择、安装、配置，而只要在云环境中访问数据库云单元，并将其链接到应用程序中。这种数据库即服务单元的使用方式能为你节省时间、精力与成本，但其最大障碍来自商业原因，多数公司都没有针对此类云计算模式的许可政策，解决途径之一是使用免费开源的数据库，如PostgreSQL或MySQL。

数据库云服务还能使托管在不同平台、使用不同技术的应用程序无缝接入同一数据库系统进行便捷查询，而当云服务接口向全球各地的信息开放，数据库的可得性就能进一步提升。这是由于数据库系统在IT层面已经十分成熟，具有多种技术通用型协议，如在连接中使用的Java语言数据库连接（Java Database Connectivity, JDBC）和开源数据库连接（Open Database Connectivity, ODBC）。此外，多数数据库都采用定义清晰的结构化查询语言（Structured Query Language, SQL）来进行数据的查询、更新、修订，使得任何地方的应用程序都可以顺畅地使用云数据库服务。

应用开发

利用PaaS服务在云端开发应用程序的主要意图有二：（1）你想要创建一项SaaS，以便迅速走向市场；（2）你想要集中精力在软件需求上，快速完成开发－搭建－测试－部署这一软件生命周期，而不必顾虑基础设施的问题（应用开发者毕竟不是数据中心公司，只想专注于自己开发的应用程序上）。无论是哪种情形，使用PaaS进行应用开发都有一系列优势：

能让你专注于软件的创造性工作，而不是硬件等周边事务。

具有基于使用的计价方式，不必为基础设施进行前期投入。

应用程序的用户数量弹性很大，无论是一个还是一百万个都无须更改应用架构。

存储、数据库等组件是标准化的现成服务，可以让应用程序随时调用。

你能获得多数应用开发者都较为熟悉的标准开发环境，其中还包括应用框架、代码模板、开发工具等。

尽管大多数云供应商都允许你迁移应用，并提供一些辅助工具，但优秀的应用程序开发环境还是会把你和某个特定的供应商绑定。更换云服务供应商的成本高不可及，比如要在别处建立自己的开发环境，就需要配备必要的人才、完成应用集成等各种工作。为缓释风险，你需要（1）评估PaaS服务提供的技术与应用开发框架；（2）确保你的应用程序与数据架构能满足更高的互通性与灵活性。

常用的云平台包括微软的Azure、谷歌的App Engine和亚马逊的Elastic Compute Cloud（EC2）。这三个平台其实并不能直接相比较，虽然你能在任一平台上写出同样应用，但它们提供的服务并不相同。Azure提供了.Net框架，这是一个包括可重复使用软件库的软件框架，能提供各类编程语言（比如Visual Basic、C、C++、C#）之间的互通性，也就是说以任意两种语言编写的代码都能互相调用。App Engine则提供了可以用Python、Java、PHP和Go语言来写代码的执行环境，你可以用App Engine执行环境来开发与测试代码，这些特点使其更适合编写网页应用或者移动设备应用。亚马逊的EC2与其说是应用开发平台，倒不如说更像个应用托管平台，更接近于IaaS服务。尽管需要自行建立应用框架、工具和开发堆栈（Stack），EC2还是能用于应用开发与测试，只是你得自己进行维护升级，而且由于你对硬件具有较高自由度与控制力，还得肩负起实现应用可扩展性的责任。因此，EC2的主要优势就是能在未来需要的时候，较为方便地将应用转移到别处。

应用测试

对于应用开发的讨论大部分也适用于应用测试。测试能实现两个目的：一是验证用户需求无误，二是确认应用程序满足了这些需求。使用云服务进行测试的主要优势包括：

可以由测试环境直接升级成为演示环境。

无需资本投入就能获得灵活的测试环境。

可以随测试需求的变化而增加或减少产能。

便于在多种环境（演示、开发、测试等）间进行切换。

如果将测试环境共享给用户，就能使用标准化测试工具、流程和测试脚本，这对于公测或用户接受度测试来说尤为有用。

由于节省了搭建测试环境的时间，可以更快捷地上市。

从模拟用户处获得的软件大小及容量信息有助于评估其拓展性及基础设施需求。

你可以用云测试环境来进行各类测试，常见的包括内部测试、外部测试、灾难恢复测试、功能测试、完备性测试、负荷测试、操作测试、并行处理测试、性能测试、压力测试、安全性测试、系统测试、单元测试、用户接受度测试等。

应用集成

为整合业务流程与功能，需要把这些功能用到的应用程序和数据进行集成，中间件提供的集成层正有此作用。中间件包括三种类型：（1）信息导向；（2）数据导向；（3）对象导向。信息导向的中间件允许应用程序通过消息队列来彼此传递信息，数据导向的中间件允许应用程序通过数据库来共享数据段，而对象导向的中间件允许应用程序共享代码等对象，常见的例子是让一个应用程序执行另一个应用程序中的代码。在“数据库服务”一节中，我们主要涉及了数据导向的中间件，本节中则会论及信息导向的中间件，这是集成应用以及云服务的工具之一。

信息导向的中间件依靠消息队列来实现应用程序间的信息交换。消息队列体现为内存中的缓冲区、数据库中的数据集或磁盘中的文件集，发送方应用将消息发到队列中，逐步积累，直至接收方应用进行提取。信息导向的中间件就其传递模式而言有6个优点：同步性、去耦服务质量控制、信息排序与过滤、信息归类和安全性。

同步性

信息传递既可以是同步的，也可以是非同步的，后者意味着应用程序不必在信息交换中互相等待。同步信息则被称为锁定信息，是确保一项工作必须在接收或处理特定信息后才能完成，此后方可开始下一项工作，因为发送方应用要等到上一条信息被阅读后才会发送下一条。

去耦（decoupling）

去耦使得应用程序可以在功能上和物理上独立运作，可以安装于不同的基础设施，使用不同的技术，采用不同的代码编写逻辑，从而具有恢复重建能力。

服务质量控制

服务质量（QoS）具有三个等级：（1）可靠的；（2）可保证的；（3）已处理的。可靠的信息传递依赖于握手协议机制，接收方应用告知发送方，该条信息（或连续信息块）已接收。可保证的信息传递仅发送一次信息，并保证递送到接收方应用，一般采用的是信息存留机制，即使在信息发出并处于传输状态，但尚未被接收时失去对发送方或接收方的联系，也能确保递送发生。已处理的信息传递要求信息作为事务处理或端到端业务功能的一部分，只有当该项事务已处理完毕，才视为信息递送成功。

信息排序与过滤

你可以按照信息的优先级、分组或特征识别来执行发送或提取。通过赋予优先级，就能确保最先提取高优先级的信息，而如果未设定优先级，一般按谁先到达谁先处理的方式依序提取（在IT用语中，这称为先入先出——FIFO）。对于需识别发送方应用或关联到特定任务的信息，可以采用另一种方式，即设置核对信息标志，这就能让你在接收到所有包含某一标志的信息之后，才会对相关信息进行处理。使用标志的另一目的是在分组内进行信息排序，即能基于识别结果，在一组信息中找到某条信息，甚至还可以设置组标志来识别信息组。

信息归类

按匿名性和连接方式，可以将信息分为不同类别。前者包括匿名与非匿名信息，非匿名信息中包括与发送方应用有关的内容。后者包括点对点信息和广播信息，点对点信息是指从单一发送方发给单个或多个接收方，而广播信息允许对某个特定话题感兴趣的接收方接收该话题下发送的信息。选择并持续使用适当的信息类别，你就能在用户和服务器架构中以本地或分发形式进行两者间的队列部署，从而获得建立可扩展的应用程序或业务功能的能力。

安全性

为保证只有你的目标应用程序能接收到信息，你可以在队列中设置访问控制，只让拥有正确证书的应用从队列中提取信息。同样，你也可以对发送方设置类似的访问控制，只让经授权的应用程序向特定队列发送信息。

在考虑应用集成时，设定信息或数据模型是一个重要环节，它能让应用程序在使用信息或数据导向的中间件时进行数据交换。统一的数据模型能让你既保持应用程序之间的去耦性，又不会将数据与应用程序中植入的业务逻辑绑定。有些行业具有标准数据模型，如金融业使用的fpML、SWIFT和FIX。

应用集成的商业化选择包括IBM Websphere MQ、Tibco Rendezvous、RabbitMQ、Beanstalkd和亚马逊SQS，除了最后一个之外，其他都不是云服务，不过你可以把它们安排在云服务中，来集成应用程序和业务流程。亚马逊SQS是一个分布式队列系统，能让网页应用在亚马逊云服务的范围中在应用组件间传递信息。你可以将SQS与亚马逊的CloudWatch结合使用，后者是一项云资源与应用的监控服务，可以用来收集、浏览并分析SQS队列的使用情况。

道斯矩阵分析

图23是从用户视角对IaaS和PaaS云计算模型进行的道斯矩阵分析。其中很多缺点都可以采取各种策略加以解决，尤其在数据安全与完备性方面。策略之一是对存储在云端或云应用访问的敏感数据进行加密，另一种方式是使用混合云模型，将IaaS和PaaS服务当成一个计算节点，而将数据存储在本地或其他IaaS和PaaS供应商处。这些选项并不互斥，可以综合运用，以满足日益提升的安全需求。但它们也存在问题，即当应用程序通过触发加密/解密服务来对数据进行加密或解密时，就会带来额外时延。

充分理解应用程序及其用户造成的工作负荷是普遍需要考虑的问题，而不仅限于云计算。为此，需要对应用程序进行测试，评估它们在提供最优用户体验时需要占用的内存大小与处理器内核数量。这项工作似乎永无止境，而IaaS或PaaS云模型的“应用测试”用例肯定能从中起到作用。云计算可以说成也弹性败也弹性，弹性机制能让云计算充分调动资源满足需求，但却模糊了计算资源与需求之间的关系。作为云服务供应商，还是应该提供日常监测与报告服务。

只有在向云外包了业务的关键部分时，才会存在与云服务供应商相关的威胁，应对方式是设立业务连续性计划，即使在无法接入云服务时也能继续业务操作。

第七章 用例模式（二）SaaS

接着上章对IaaS和PaaS云服务的讨论，我们继续以用例的方式寻找SaaS云计算的共同主题，其间会考虑SaaS的各类用例，并从使用者的视角对SaaS云计算模型进行道斯矩阵分析。最后以一个关键要素表结尾，其中包含了与SaaS云供应商商议合同时需要提出的问题。

SaaS的用例

软件指的是安装在计算机上，为你提供特定功能的应用程序。对于云计算来说，为支持集成与监控功能而在后台运行的都应称为中间件，而不是“软件”。你想让计算机提供的特定功能可能包括办公效率（文字处理、演讲、电子邮件、电子表格分析功能等）、管理家庭或公用资产、财务预算及计划、账单支付及付款单管理，如图24所示，这都是软件即服务的部分用例。

让我们具体分析几个用例，初尝软件即服务的优缺点所在。

客户关系管理

客户关系管理（CRM）能帮助管理公司与现有及潜在客户之间的互动关系。客户关系管理软件则能让你清晰定位客户并制定跟进策略，此外还能提供各类客户增长与流失指标的评估与报告。由于在云中写入CRM代码较为容易，具有不同商业模式的各类企业都对CRM软件存在需求，因此CRM往往以SaaS的形式提供。常见的CRM SaaS供应商包括微软商务管理解决方案（Microsoft Dynamics）和Salesforce CRM。

使用基于SaaS的CRM解决方案的主要优点在于，可以从任意地点访问客户记录，能以标准化、客观的方式跟踪并评定销售团队业绩，以及快速了解销售增长概况。缺点是对SaaS供应商的依赖，同时客户相关数据可能存在安全问题。后者的问题在于SaaS商户可能受黑客攻击，其雇员也可能获取你的数据。即使这种风险很小，对你来说也是必须接受的业务成本。而前者指的是你的SaaS供应商可能出现业务中断甚至停业，通过在另一云供应商定期备份CRM数据，可以在一定程度上缓释这一风险。

收费与开单

业务基础设施和IT基础设施类似，用于提供人力资源管理、资产管理、收费、开单、审计等功能，这些功能是业务运营的组成部分，但并不影响商业模式，因此可以采用SaaS或BPaaS外包服务来提升效率。此处以收费与开单作为用例。

当你的客户下单时，相应的订单确认、收费、开单、结算程序就被自动外包给第三方，由第三方依序完成这些任务，即替代了这项业务功能。如果这一功能托管在云端自动运行，就属于业务流程即服务的范畴，例如贝宝（PayPal）的买家服务。而如果你将收费与开单应用安装在PaaS平台上，以便员工使用，这就是一项私有SaaS服务。你甚至可以将自有SaaS开票应用与贝宝整合起来，创建出收费结算服务闭环。

使用SaaS的优点在于提升现金流效率，将这些机械琐碎的工作外包后，你和你的员工就可以将精力集中在主要业务上。

协作、即时通信和电子邮件

很多人使用Outlook收发电子邮件，用Lync和Sharepoint等工具进行协同工作。从非专业人士的视角来看，这些工具和行为可以归类为群组交流。其中大多数工具均由微软提供，在Windows桌面上使用，而苹果也提供了适用于苹果桌面的类似工具。当然，还有来自独立供应商的第三方通用型工具，但在用户数量上就难以企及。如果使用云计算，就能脱离以设备为基础的操作系统，将工作地拓展到更为广泛的范围，从而拉平竞争起点。该领域内的新兴竞争者，例如谷歌，已经开始通过云免费提供类似工具。还需注意的是，这些“业务基础设施”工具就像日常用品，需要企业定期采购并使用。

还有另一个因素也在破坏着传统交流方式：通常IT部门不会特别指定终端设备，当下的风潮反而鼓励你将自有设备带来工作，云计算、瘦客户端或零客户端、自带设备共同推动传统群组交流形式向云和更为分散的计算模式迁移，使用云端工具来代替桌面工具也蔚然成风。然而，对于脱离桌面扑入云的怀抱，还是需要保持谨慎态度，因为采用这些工具可能会对你的业务产生致命影响，权衡云模型利弊时需要遵守下列四大准则：

安全性：信任你的员工

不要为了强化安全而限制你的员工只能使用特定的技术工具，应当相信他们的诚实尽责。当然，你可以规定他们以加密方式存储数据，或者在自有设备中将数据存在沙箱环境下，这样，个人设备所感染的恶意软件就不会对你的业务造成影响。

依赖性或绑定：找好备份，以防万一

如果可能的话，别把你的文件存在效率工具供应商处，而是存在第三方IaaS平台上，同时在另一家供应商处备份文件，以确保不会完全依赖任何一家。最好的方式是将文件以开放式格式储存，如RTF或ODF，以便其他应用访问。

成本：考虑自有应用的全部成本

仅考虑应用程序证书的成本是不够的，还需要考虑到应用封装、发布、维护等各项成本，其中维护指的是确保应用程序的最新版本和补丁已全部安装。这么一算，云服务很可能是最实惠的解决方案。

专注：集中精力于商业模式

如果你并非处于IT行业，那就不需要设立庞大的IT部门，这会增加管理成本。如果使用SaaS，就可以在核心业务上集中精力创造价值，推动发展。

使用云SaaS服务的优势显而易见：保有成本较低，不必为IT基础设施或业务基础设施相关事务所累，可以集中在核心业务上。不过这还可以更进一步。你可以使用企业邮件服务（如谷歌邮件或雅虎邮件），而无须建立自己的邮件服务器和企业域名，你的公司邮件地址可以是<员工名字>.<公司名称>@[yahoo或gmail等].com。如果你确实需要一个企业域名，也可以将该域名指向企业邮件服务（人们将邮件发到带有你公司域名后缀的地址，如a公司.com，但事实上你还是从谷歌或雅虎取得这些邮件）。这正是BYOD和云计算的精髓所在。

办公效率

当办公从桌面转到云端时，上述考虑也适用于办公效率工具，因为它们承担着团队交流的职能。办公效率工具包括文字处理、演讲、电子表格软件，微软、谷歌等公司都在云端安装了这类应用，并以SaaS的方式供你使用。微软提供的是Office 365云应用，而谷歌则提供谷歌文本、表格、幻灯片，可以实现在线创建文档、实时与他人协作、在线储存。由于主要计算量都已移到云端，操作在线文档所使用的客户端设备在计算能力上就可以稍微弱化，主要采用瘦客户端和零客户端，例如Crome Books（手提式瘦客户端）和Chrome Boxes（桌面瘦客户端）。诸如HP 410t之类的零客户端还能通过虚拟应用，在同一设备上实现对托管在私有云上的胖客户端应用及托管在第三方公共云上的办公效率应用的访问。

图像渲染

我们曾在前一章中提及图像渲染，并将其作为IaaS的用例。如果你在IaaS平台上安装了图像渲染软件，并对外提供云服务，那么这对于通过云使用软件的用户来说就是SaaS。这是一个创建SaaS服务的实例，即在IaaS上安装软件，并在多用户环境中向他人提供使用。通过不断增加附加值，你就能从IaaS抽象层逐步提升到PaaS、SaaS、INaaS、BPaaS——如同一架价值之梯。

道斯矩阵分析

图25是从用户视角对SaaS云计算抽象层进行的道斯矩阵分析。

第八章 用例模式（三）INaaS

在IT应用于知识管理领域中时，数据、信息和知识三个概念具有重要区别。数据与你的特定处境或需求无关，信息是具有一定背景的数据，而知识则是包含专业性或基于经验的可用的信息。举例来说，你可能拥有全世界的航班数据，但只有与你假期行程相关的数据才能称为“信息”，而知识则是航班信息中能让你经受最少波折（行李丢失、中转、延误等）到达目的地的那一班。

有一点易于混淆之处需要格外留意。如果你通过一项服务获取数据（或进行数据存储），这可不是INaaS，而是PaaS，因为你使用的其实是基础设施。数据的存储或传递具有很多形式，如DropBox、谷歌硬盘、苹果iCloud都是数据存储服务，而航班、列车、公共汽车时间表主要属于数据，除非有附加服务（如通过卫星定位获取你的位置，并实时为你提供适合的公共汽车或火车时刻），才能成其为INaaS云服务。有一个方法可以区分PaaS和INaaS，提供原始数据的就是PaaS；而当数据以软件或应用程序的形式组织后，数据就成为信息，而其传递服务就是INaaS；如果通过业务流程对信息进行专业化处理，这一服务就是传递知识的BPaaS。也就是说，数据经软件增强后就成为信息，而信息由流程增强后就成为知识。

当数据（或其存储）以云服务形式向你提供时，这是PaaS；当提供的是信息时，则是信息即服务（INaaS）；而当传递的内容是知识时，就成了业务流程即服务（BPaaS）。

本章讨论的是INaaS的用例，同样，我们为其进行了道斯矩阵分析，以使你了解其优缺点，并为你提供评估某项INaaS服务所需的充分的背景知识。

INaaS的用例

INaaS的特征如下：

集成了IaaS、PaaS和SaaS几类云服务模型。

具有良好的互动界面，可以与其他应用或软件整合或交流。

可以灵活设置，用于满足新的业务需求。

可以用于任一部署模型，如私有云、公共云、混合云或社区云。

和其他云服务一样，可通过弹性进行拓展，从而支持不同数量的用户。

尽可能自动化，整合数据并按软件内置逻辑进行强化，以提供有意义的信息。

使用基于使用量的价格模型。

INaaS的优点包括：（1）数据具有意义；（2）通过实时提供最新数据来帮助提升生产效率；（3）跨业务部门、跨地域标准化；（4）基于即时性与通用性来提升灵活度；（5）计价模型更能节约成本。

图26展示了信息即服务的主要用例，下文中我们重点讨论与法规、税务、价格、健康、课程相关的INaaS云服务。

法规信息

现存法规框架多种多样，有些是关于公司的注册所在国，有些与特定行业相关，而诸如反洗钱等法规是世界通行的。INaaS云服务能为机构提供此类法规信息，由于能按国别收集运营所在地的相关法规信息，对跨国公司尤为适用。

税务信息

多数国家的税收制度与法规每年都会修订，有时甚至更为频繁。INaaS的用例之一就是随时随地为你提供量身定制的税务信息。个人与企业每年都要花几周时间用于填报税务，这段时间内的服务需求会达到峰值，只有云计算才能让税务信息供应商负担得起这样大起大落的需求，从而使提供INaaS服务成为可能。

价格信息

“产品价格”只是与产品相关的“数据”，而“你希望购买的产品价格”才更接近于“信息”。当你正沿街而行，天空突然阴沉下来，如果有一款应用程序能告诉你销售雨伞或雨衣的最近商店及其价格，该有多好呢？由于这是适用于你所处情境的有意义的数据，因此属于信息即服务的范畴。

疾病、健康相关信息

随着一系列可穿戴设备的出现，健康监测日益成为现实。而如果能在健康监测数据超过一定阈值时向你（或你指定的医生、家人等）报警，就显然更进了一步。将数据与预测能力相结合，并基于预测到的趋势告知你特定情形发生的概率，这就是有意义的信息。此外，如果能在提供健康趋势的同时，获取医疗网站（如WebMD）的相关信息，又当如何？这能让你对自己的健康更有前瞻性，并能提高公民的整体生活质量。

课程信息

学校各类课程的授课、考试、实验、作业都有时间表，如果能便捷获取你学习的特定课程的相关信息，就如同有一个私人助理。这种信息服务也属于INaaS的用例，且无论所在学校、所学课程，对每个学生都适用。

道斯矩阵分析

图27是从用户视角对INaaS云计算抽象层进行的道斯矩阵分析。

第九章 用例模式（四）BPaaS

BPaaS采用工作流、云计算技术与价格模型，以自动化或半自动化的形式实现垂直或水平业务流程。这是云计算中的最高抽象层级，因此在提供服务时需要调用其他抽象层级（IaaS、PaaS、SaaS和INaaS）。垂直流程是商业模式相关流程中的一部分，而水平流程则用于支持垂直流程的辅助性服务。

图28展示了五个不同行业内的垂直及水平流程示例，无论哪类流程，底层都是特定的工作流。我们以咖啡厅为例来说明这一概念。假如你在咖啡厅里要了一杯拿铁，付完钱，找了个位置坐下等咖啡做好并端到你的桌上，这就是一个工作流。不过这一工作流还能进一步拆分，比如在制作咖啡时，服务员要挑选咖啡豆，将它们放到咖啡机中，清理管口，将水煮到合适温度，加入牛奶，最后将咖啡注入杯中。除了咖啡机的制作过程外，这个工作流中大部分都是人工流程（当然，也可以通过使用机器人或其他技术来实现自动化）。无论是否自动化，这家咖啡厅都要采用一系列业务流程来按你的要求提供咖啡，其中一些流程可以外包给第三方，比如制作咖啡的员工将端咖啡的工作“外包”给服务生，由其把咖啡送到桌边，还将订购咖啡豆及库存控制的工作“外包”给了其他人。在很多案例中，整个业务流程或其中的某个组成部分都可以像这样外包给云。本章中我们主要讨论垂直流程，因为它们在企业中比较常见。

BPaaS的用例

BPaaS有如下特征：

整合其他云服务模型：IaaS、PaaS、SaaS和INaaS。

具有良好的互动界面，可以与其他应用或软件整合或交流。

可以灵活设置，用于满足新的业务需求。

可以用于任一部署模型，如私有云、公共云、混合云或社区云。

和其他云服务一样，可通过弹性进行拓展，从而支持不同数量的用户。

尽可能自动化，但组成服务的工作流可以是自动或人工的。

使用基于使用量的价格模型。

BPaaS的优点包括（1）一致性与可重复性，以确保达到关键绩效指标（KPI）；（2）通过自动化工作流提高生产率；（3）跨业务单元标准化；（4）通过最优化提升灵活性；（5）通过定价模型实现成本或现金流效率。

图29展示了业务流程即服务的主要用例，下文中将讨论其中的一部分：（1）以税务及税收筹划为例说明如何在SaaS和INaaS之上构筑BPaaS；（2）以薪酬管理功能为例，说明水平业务流程；（3）以培训为例，评估其对教育产业变化的作用；（4）以测试服务为例，说明在适应不同的业务流程过程中，不仅需要技术创新，也需要商业创新；（5）以健康监控为例，展现个人云的无限可能。

BPaaS虽然仍处于襁褓期，但在创新方面却是云计算的中流砥柱，尤其是在个人云、物联云及两者结合的混合云领域。在第11章关于云计算未来展望的部分中，我们还将就此进行更深入的讨论。

税务与税收筹划

还记得前一章中关于税务信息的INaaS用例吧，为填报税务申报表并进行税收筹划，你需要随时查阅最新的税务信息，因此任何税务处理业务流程都需要通过信息服务获取信息。另外，还需要将这一信息提取流程自动化，才能一直基于最新的信息开展工作。基于BPaaS的税收筹划系统需要用到多个应用，来完成组成流程的各部分工作，如个人数据录入、基于情境的规划、税收计算、报告等。这些应用既能独立安装，也能以SaaS的形式托管在云端，后者可能来自独立运作的第三方云服务。业务流程是一个复合体，由不同的应用与信息有序结合成工作流，以满足某个目的或达成某项商业功能。当然，工作流中也会有与人（或手工程序）的互动，特别是在对各类情境的适用性进行评估从而预测未来税务支出之时。你也可以将这类BPaaS看成云上之云，也即采用第2章中所讨论的封装方式构成BPaaS云服务。

在税务与税收筹划用例中，我们可以提取出如下通用模式：（1）以封装方式创建复合型的BPaaS；（2）INaaS和SaaS是组成BPaaS服务基本要件。这两点并不互斥。

薪酬管理功能

薪酬管理功能包括向员工支付工资、编制并发送工资单、从工资中代扣税收并上缴政府。无论业务性质为何，绝大多数雇用员工的企业都需要这一业务流程，因此其本质上属于水平流程，与前面讨论的税务与税收筹划流程类似。

薪酬管理流程除了完成自身范围内的各项工作之外，还需要与其他流程进行互动。举例来说，如果一名员工请了无薪假，就需要确保人力资源将该信息录入薪酬流程，从而对薪酬支付做出适当调整。同样，如果这名员工获得了加班工资，也需要与部门管理进行沟通，来如实获取此类信息。如果一名员工离职，人力资源需要启动离职流程，并告知薪酬管理流程该员工的最后工作日。种种例子表明，大多业务流程都不是单兵作战——它们需要与其他流程协同互动。因而在此类业务流程中采用BPaaS服务时，需要建立起与其他流程互动的界面，在其中明确需要共享的数据以及触发数据共享的事件，这就需要两种交互形式：控制与信息。

在薪酬管理等水平业务流程中使用BPaaS的优点包括：（1）规模经济带来的成本效率，特别是对中小型企业而言；（2）基于使用量的价格模型，按处理数据数量收费；（3）标准化服务，有助于设置KPI指标。尽管如此，现有的云业务流程服务仍然屈指可数，只存在作为其部件的SaaS或对应的手工流程。

培训

BPaaS与业务流程管理（BPM）有着千丝万缕的联系，它所封装的业务流程正是由BPM来定义的。BPM是用于设计、执行、分析、优化、控制业务流程的一套方法、工具及技术，随着时间发展，它不断演进并纳入了一系列新技术，如图30所示。业务流程改进的主要动力来自于制造业向以流程为中心转变，这一因素促使了适时生产制度（Just-In-Time）和六西格玛战略（Six Sigma）的产生，成为业务流程优化中的重要工具。培训并不以流程为中心，从而不受这一因素影响，也未采用任何BPM技术。BPM的演化遵循“产品为中心”到“流程为中心”的轨迹，下一个阶段将是以“用户为中心”，换句话说，就是以高效量贩的方式、最低的成本、最优的途径急用户之所急，提供用户所需。当按照用户中心模式使用BPaaS来提供培训服务时，就能将BPM主体所能带来的优化与高效封装在内，这也是促成培训业变革的有力推手。

传统的培训形式并非量贩式，如果想要接受正式培训教育，就需要进入真实的学校，和其他同学坐在一起向教授学习。也就是说，培训只能提供给那些参加现场授课的人，也受到培训机构接纳能力的限制。虽然存在函授课程等形式，但教育与培训资源仍然不足。不过最近Coursera、EdX等各类培训网站纷纷涌现，为用户提供在线培训课程，Youtube等视频分享网站也满足了部分非正式培训资源的发布需求，这些课程都是量贩式提供，使人接受起来饶有兴趣。尽管目前还不属于BPaaS，但也已经相当接近了，下一阶段可以轻松升级为BPaaS培训模式，操作方式是在注册入学至结业认证的整个流程中都嵌入最新的识别与认证技术，基于此来完成培训和测试。

考试与测验服务

培训与考试测验相伴相生，两者本质上就互相关联。现有技术已可以确认参加测验的是否为本人，是否具有授权，测试题则从一个大题库中随机抽取，以保证测试的公平性。事实上，已有大量采用上述原理的测试中心涌现出来。但为什么不在家完成测试呢？为什么不把测验作为学习体验的一部分而非放在课程结束后？随着网络摄像头、语音自动识别的使用，基于BPaaS的测验服务在技术上已经成熟，并可以整合在培训服务中。事实上，整个教育产业都需要适应并改变业务流程，这种情形属于技术创新走在商业创新之前，而后者理应迎头赶上，以获取技术创新带来的收益。

整体而言，可以感受到这种趋势已初现雏形。较之垂直业务流程而言，水平业务流程更容易由BPaaS提供，原因很简单：垂直流程是业务的一部分，深植于商业模式之中，同时相关方的利益纠葛也让变革阻碍重重。

健康监控

医疗产业正在致力于赋予病人或个人自己照管健康的能力。当然，这有赖于通过教育改变包括病人在内的各方观念，但科技在促成这一转变的过程中也扮演着重要角色。考虑如下情境：每个人都拥有自己的个人云，或说私有云，用其来存储自己的健康信息，评估健康状况，并在身体恶化时自动发出警告，其中的重要信息可以选择通过电子邮件或即时通信发送给他们的医生。这一用例也有助于临床医生监控在家卧床或行动不便的病人。私有云还可以与其他可穿戴设备交互，监控心率、体重、血糖水平、体温等多项指标，自动完成监控、数据收集、分析、报警等工作，就好像拥有一个全天候的私人护士。

此外，如果个人允许数据被匿名上传归集，就能绘制出各类疾病的整体图谱，以及年龄、性别、地域等因素对人们身体状况的影响，这就能为决策者或医生提供人口结构及其与疾病关系的客观信息。更进一步，决策者还可以使用预测分析来评估不同疾病在区域内的扩散情况，从而更好地分配医疗专家。这正是流程管理的要义，让医疗服务更为有效。

健康监控BPaaS用例中，主要因素在于云内外多种流程与技术的复合运用，互相作用形成自动化工作流。如果以“物联云”的概念进行类比，这就是人联云（cloud of people）。

道斯矩阵分析

图31是从用户视角对BPaaS云计算抽象层进行的道斯矩阵分析。

第十章 向云计算转型

如果你已经决定使用云计算，接下来要如何操作呢？要如何使用云服务？如何与其他服务商提供的云服务交互操作？本章中我们会讨论云服务使用中的这些关键问题。此外，你还需要按照服务层级协议对云服务供应商进行评估，从中选择合适的服务商与合适的云服务。如果你在网上查找服务层级协议及其指标，或者阅读关于云计算的海量书籍，就会常常遇到关于服务层级协议指标的讨论，如网络容量（带宽、延迟、网络吞吐量等）、存储容量、服务器处理能力（中央处理器数量、主频、内存等）、对象启动时间（启动一个虚拟机对象所需时间）、平行存储弹性（存储容量应对工作负荷增加时的变化能力）、平行服务器弹性（服务器容量应对工作负荷增加时的变化能力，表示为云资源池中的虚拟服务器数量），这类指标不胜枚举。如果你需要创建并操作自己的云，这些服务层级协议会十分有用。但如果你仅仅是云服务的购买和使用者，为什么还要顾虑这么多呢？毕竟云服务正是利用抽象层来让你不必再为技术感到头疼，而不是给你增加麻烦。因此，我们不打算重弹大多数云计算书籍的老调，而只摘出与云服务用户相关的服务层级协议及其指标，通过一张清单来对云服务进行评估。讨论完这些要求之后，我们将检视一个典型云使用模型中的关键成功因素，最后还将从用户角度构建云成熟度模型，来评估自身作为云服务用户的成熟程度。这样，你就能评估自己使用云服务的最佳方式，并在使用期间不断跟踪自身进步。

大学计算模型

大学计算模型又称自带设备模型，指的是你能使用任意设备获得IT或云服务。第3章中已经讲过，由于学生和职员不同，他们会把自己的设备带到学校，因而大学的IT部门不得不为各种各样的设备提供服务，这一模型就得名于此。而在大多数企业中，由于IT部门会对可使用的设备范围进行限制，整体而言设备较为同质化。

当云计算与自带设备相结合时，IT服务的提供与使用模式就发生了转移。正如图32所示，向自带设备转变的过程会影响许多因素，并进而反映在一系列企业运行规则上，包括从财务制度到公司整体政策。

图32说明，对于某个特定因素而言，你需要相应采用差异化的自带设备方式。以数据丢失为例，公司配发的设备会由中央IT部门进行定期备份，而在使用自带设备时，需要在云存储中进行数据备份。云存储能确保你从任何地点用任意设备访问数据，这就给用户带来了更多便捷与自由。下面我们会论述应用于计算环境的不同云使用模型。

云使用模型

在向云计算转型的过程中，需要衡量IT布局的现状与未来，基于此创建行动方案。整体而言，可以按服务提供方式对IT布局进行分类。依据IT与业务结合方式的不同，将IT服务特别是与云计算相关的服务使用模型分为五类。图33中展示的是第一代云计算使用模型，这种一阶使用模型是基于单一IT服务供应商，一般以中央IT部门的形式掌管服务层级协议及合约，并向机构内的业务单元提供服务。单一服务商也可以指定第三方作为分包商来提供部分服务，所提供的服务既可以是云计算，也可以是传统IT。

一阶使用模型是目前最常用的使用模型，其主要缺点是与中央IT部门连接过于紧密，如果业务需求发生变化，云服务就无法及时做出回应。图34所示的模型相对更优，可以支持使用多个服务商。

如果一家供应商的服务无法满足变化后的业务需求，就可以进行更换，中央IT部门持续作为业务单元与云服务供应商之间的中介，同时还承担服务整合这一关键职能。整合职能体现为两种形式：（1）整合不同供应商的服务；（2）进行业务单元与服务供应商的整合。尽管多数机构都希望在IT服务中使用这一模型，无论是否以云计算的形式，但因为中央IT部门难以完成整合工作带来的挑战，而常常无法实现。通过指派专门的服务整合商（并非指系统整合）或许可以解决这一问题，如图35所示。

服务整合的作用是确保用一揽子IT产品与服务满足业务需求，质量恒定，经济高效。中央IT部门直接与服务整合商接触，而不是云服务供应商。服务整合商可以与云服务供应商逐一商定合约、管理报告与付费事宜，从而向中央IT部门统一提供报告与付费账单。通过这一使用模型，业务单元可以十分便捷地从三方获得云服务：（1）服务整合商；（2）服务整合商指定的第三方服务商；（3）中央IT部指定的其他服务供应商。所有这些受托方都向业务部门提供服务，而中央IT部门仍保留对于云服务的整体监督职能，以使其符合业务利益。但影子IT的问题仍然存在，甚至因为云计算的便利与灵活性而更为突出。主要问题之一是安全隐患，由于业务部门接入IT的方式变得非标准化，从而更可能出现安全漏洞。另一方面，由于目前为止所涉及的使用模型难以及时满足业务需求，业务部门才会诉之于影子IT。为解决这些问题，需要引入一类新的使用模型，其主要特点是与中央IT部门和云服务供应商之间的无约束连接。如图36所示。

图36中的使用模型与之前所讨论的有所区别，其目标着重在云服务的实现。前述模型是基于对传统IT服务或私有云服务的使用，而图36中所示的基于服务交付的使用模型中，中央IT部门只负责维护一份云服务及其供应商目录，业务部门可以从中挑选，并与云服务供应商直接接洽，商讨服务层级协议与付费方式，中央IT部门则兼并了服务整合商的角色。当企业开始采用这种模型，云计算就真正取代了传统IT部门，而中央IT部门也不再是集中式运转，而向分布式功能演变，如图37所示。

如果将IT功能分布式嵌入于业务部门中，就能使业务更为灵活，也能充分利用云计算的优势。企业中的IT功能由首席技术官进行统筹规划，他需要负责制定企业与云服务供应商之间的合作规范，同时还要进行监督稽核，保证业务部门与服务商遵守现有技术规范。中央IT部门的其他传统功能，如付费、IT合约管理等，则仅需分别并入财务与采购部门即可。这是云计算下所能达到的IT部门最小化版本，也正是因此，云计算得以实现职场乃至整个商业的范式迁移：即将IT的控制权从少数中央IT部门人员转移到业务部门的无数IT用户手中。

互通性

正如你在前文中所了解的，各个使用模型有一个共同原则：让多项服务共存。出于业务连续性或其他商业原因，你还会要求一项云服务可由另一供应商的类似服务所替代。这都要求服务之间存在互通性。

互通性指的是可以使用不同云服务供应商给出的相同或近似服务的能力。互通性的应用范围并不局限于技术方面，也同样适用于付费、报告、管理、业务流程和数据等领域的整合，无论使用何种云交付模型——私有云、公共云、混合云或社区云。你可以采用下列清单来确认自己的云服务具有互通性。

管理稽核

如果你对一项云服务使用了稽核流程与政策，那么就需保证所采购的服务与现有云服务交互的其他服务都遵守统一稽核标准。同样，机构内也要由同一管理委员会来监督所有云服务，尤其是需要进行交互的云服务。

合规性

如果你需要遵守行业或国家性法规，就需要确认所使用的云服务是否涉及该范围，如果涉及，则所有互通的云服务都需要遵守同一法规。从云服务的角度来看，一般法规与行业专门法规存在递进关系，与其自身的专业化程度相匹配。正如图38所示，电子邮件、办公效率等一般功能性服务的应用范围具有全球性，受到通用的跨国法律法规约束。而当所涉及的云服务更为专业化时，通常要进一步适用于本地法律及行业性法规。不过这只是粗略的观察，不一定适用于某个特定云服务。

安全与数据完备性

考虑到数据完备性，互通的云服务需要使用同一加密标准与机制，否则数据就无法无缝衔接。而对于安全事项来说，需要确保在互通的云服务上施以同样的安全程序，避免出现安全短板。同时，还得要求所有云服务的用户都接受同等安全培训，以便在机构内以标准化形式统一执行安全政策。

数据一体化

要实现数据在云服务之间的无缝传输，存在两个重要因素：通用格式和通用数据模型。格式指的是数据呈现的方式，比如电子表格形式存储的数据就和文本文件格式不同。就算格式相同，数据内容也还需要保持统一。比如你有两个文本文件（格式相同），但一个包含的信息与存货相关，而另一个则含有薪酬相关的信息，这两者就具有不同的数据模型。因此，互通的云服务使用的数据应当具有同样的格式及模型。

流程一体化

为实现互通性，不仅要有相同的数据格式及模型，还需要保证云服务内部作用于该数据的流程是在完成同一任务，这就是流程一体化。它包含两种应用情境：一种是当一个云服务流程从另一个云服务中接收数据并触发一段工作流时，你期望这个工作流能延续前一阶段的流程；另一种则是要求两个流程完全相同，因而能够以即插即用的方式互换使用。无论是哪种情境，都需要确保各个流程使用同一业务流程语言（BPL）和协议，以满足云服务的互通要求。为简化数据与流程一体化工作，通常会采用企业服务总线（enterprise service bus, ESB），把多项技术一体化要求暗藏在较低的抽象层中。

业务连续性

业务连续性包含两方面内容，其一与灾备恢复相关，通过备用云服务来保证服务最大限度不被中断，最好是由另一服务商提供备用服务；其二则是在现有服务商无法满足高峰期需求时启用备用云服务。不论哪种情况，都可以用云爆发来保障控制流在两个云之间的无缝切换，当然前提是存在这种技术能力，来运用云爆发或者类似的自动化切换机制。这更类似于一项技术要求，运用适当的协议与标准来保证云服务之间的控制传递无缝衔接。另外，业务连续性的达成也有赖于数据与流程一体化的实现。

监控与报警

在未来，随着监控与修复流程的自动化，云服务可能会具有自我修复功能。但在那之前，你还是得确保云服务监控流程以通用标准与格式来发出警报，以便团队成员能够获取警报并及时做出反应。你还可以主动进行定期测试，比如用压力测试来确认对客户的服务能力是否足够，用入侵测试来评估是否存在安全缺口。

付费与报告

所有服务的付费流程、格式和报告（报表和收据等文件的统称）都应该大致相同，以便你能快速有效地评估每项服务的总成本。你还得确认执行付费流程的人对这些流程和报告的理解一致，不仅要做到流程的互通，相关人员也是一样。

业务流程

向云计算转型是一个重新设计业务流程、提高效率的好时机，流程连接着业务的各个方面，对其进行提升就能改进整体业务水平。而由于BPaaS云能做到业务流程的自动化，云计算也能相应成为业务重焕活力的引擎。就算你还没走到BPaaS这一步，仅使用INaaS和SaaS云服务也能提升效率——继而影响商业变革。

图39中所示的业务流程重塑（BPR）模型（由哈默与钱皮创建）提供了重新设计业务流程的步骤。业务流程重塑模型的中心思想在于，唯有流程同步得到优化，提升组织效率的举措才可能获得成功（这也同样适用于物联网相关流程，即机器与机器间的交互效率需要趋同）。在使用BPR模型时，常见的问题（图39的步骤3）便是某项流程或其中某道工作流是否必要，事实上只有那些必要流程被保留、优化并实施。在步骤5，你会将部分流程完全设计为BPaaS云服务，另一部分使用某类云服务模型，其余的则不纳入云计算范畴。衡量是否应加入云计算组件的标准取决于你的要求及成功要素，如下文中所述。

要求与成功要素

在向云计算转型或考虑采用一项新的云服务时，你需要建立一套要求指标，才能有的放矢地在云服务中进行权衡比较。另一方面，这些要求有助于进一步明确服务层级协议，从而有效评估一项云服务是否适合。记住，云计算并不能满足所有IT或运算需求，有些时候需要用到传统计算方式，比如对运算速度或恢复能力有很高要求时。下列清单有助于你明确对云计算的要求，同时也能明确所采购的云计算的成功要素。我将清单中的要素分为三类：功能性、非功能性和业务相关性的要求。一般来说，这些就已足够评估云计算所有的部署模型和服务模型了。

1.功能性要求

成熟度

互通性

特征集

使用模型

2.非功能性要求

安全性

可得性

恢复能力

网络容量

3.业务相关性

价格与效用模型

风险

业务连续性

支持模型

报告与付费

你可以建立一个评分矩阵，对各项要求进行评分，比如0分代表完全没达到该项要求，而3分代表已完全达标。也可以在要求项上加入权重，来反映你对其重要程度的判断。比如说，如果你认为成熟度完全不重要，就可以将其权重设为0，而特征集的权重则可能为3，说明它非常重要。将权重与评分相乘，就能得到该项要求的加权评分，继而可用于对云服务或其供应商进行比较。

云成熟度模型

图40显示了云计算的成熟度模型。其中包括五级成熟度：可实施、较明确、可管控、已适应和最优化（成熟度的最高等级）。图中题为“关注点”和“成功要素”的前两行分别描述了该成熟度等级的主要特征和优势，而最后五行则分别从以下方面说明了云服务的成熟度特征：（1）采购、使用和管理云服务所涉及的人员；（2）与云计算交互的流程；（3）该服务的财务与使用情况监控及报告；（4）确保云服务满足需求所必需的安全、法规、功能与财务方面的监管；（5）保障有财力获取云服务的财务管理。这五项特征的成熟度等级并不一定一致，比如你在人员方面的成熟度可能为1级，而流程成熟度则为3级。而云服务的整体成熟度则由多数特征所处的成熟度水平决定。

你可以将成熟度模型用于两个目的：第一是用于建立战略，优化对云服务的使用与签约——这将有助于向更高的成熟度等级提升；第二是用于了解云计算的最佳运用方式。最后一列描述的是最优化的成熟度等级，显然这也是我们的终极目标。

第十一章 未来展望

云计算技术可以实现自动化与抽象化，在影响工作、社会与生活的范式转移方面具有独特地位。本章将讨论一些与云计算相关的新兴技术和趋势，它们催化着未来技术格局的改变。在讨论这些趋势时，我也对云计算的未来做了一些预测。当然，预测不一定都能成真，但如能了解哪些事情可能发生、云计算会为我们打开哪些新大门，在逐步塑造未来的过程中总归有益无害。

物联网与服务网

你可以在自己家里找到很多含有微处理器和微控制器的应用：烤箱、洗衣机、电视、冰箱甚至某些垃圾箱，而由于微控制器的价格极其低廉，这个清单还会不断延长。哪怕连灯泡之类的消耗品也开始内嵌此类装置，也没什么好奇怪的。当你把这些应用接入互联网，设备间便彼此连接，这一网络称为“物联网”，英文缩写为IoT（Internet of Things）。为什么要把这些设备接入互联网呢？以垃圾箱为例，当垃圾装满之后，其中的感应器就会通知当地环卫部门，让他们能依照实际需求来清空垃圾箱，而不是定期派送垃圾车。更进一步，如果垃圾箱能预测自己装满的时间（通过每日感应到的新增垃圾重量进行推测），并提前几天向环卫部门发出邮件或信号，环卫部门就能提前规划垃圾收集最优路径，从而节约地方部门的燃料与时间。你所缴纳的地方税可能因此下降，令你也从中获益。类似的做法已在办公室打印机上实现。打印机检测纸张、墨水、色粉余量——这些均为消耗品，在快要耗尽时向中央控制台发出邮件，然后替换墨水和色粉的信息就会发往后勤部门。因为打印机“属于”打印机公司，只是租给你所在的公司进行使用，因此你的公司完全不用为这些服务付费，只要按打印张数向打印机公司支付月费即可。因此，物联网打印机具有基于云的用量价格模型。监控大量打印机、基于打印页数每月寄出账单、自动订购墨水等补给品都可以视为业务流程或服务，而如果一项服务是通过云自动实现，并完全用于服务物联网设备，就被称 “服务网”，英文缩写为IoS（Internet of Service）。服务网的另一个例子是将一定区域内的大量路灯接入互联网，并自动检测灯泡的更换需求，以取代人工定期巡查。这些路灯还有额外用途：收集气温、湿度、气压等气象信息，计算路过的行人数量以评估特定路段的便利程度等。如果在路灯物联网的基础上通过监控来更换灯泡，这就是服务网。不难发现，物联网可以和服务网互相关联，统一规划。

物与服务云（CoTS）

你或许会问，物联网、服务网和云计算有什么关系呢。事实上，为支持物联网设备而进行监控、实施服务的流程往往就在云端，或说服务网即托管于此。可以说，物联网设备及其相关的服务网类型服务都具有自己的云，种类可以是私有云、公共云、社区云或混合云，视应用目的与需求而定。我创造了“物与服务云”一词来指代这类特定用途的云，英文缩写为CoTS（Cloud of Things and Services）。虽然现在物与服务云还很罕见，但未来必将随着物联网设备及其服务网的普及而遍地开花。物与服务网的关键前提是自动化，这也支撑着物联网与服务网的两大要义：便利性与随时随地按需服务。其中“随地”一点尤为重要。在路灯的例子中，你得知道需要更换的灯泡所在的灯杆（及其确切位置）。对于非驻点设备来说，则需要使用全球定位系统来获得物联网设备的经度、纬度、海拔等信息并精确定位。云计算无处不在的特点能与物联网设备达成高度协同，无论它们在哪里，都能够进行监控并提供服务。

能够提供物与服务网的主要领域包括：

1.智能家居：如内置式烟雾探测器、火警系统等家庭或办公室互联设备。

2.可穿戴设备：谷歌眼镜、苹果iWatch等就是很好的例子，它们不但能提供通信，内置的感应器还能检测你的健康状况或环境情况。

3.智慧城市：服务网和物联网设备相结合的用例包括交通管理、供水、废弃物管理、城市安全、环境监测、人流量管理、路灯等。

4.智能电网：通过物联网设备和智能量表获取电力消耗相关信息，提升电网效率、可靠性和经济性。

5.零售：零售领域的应用包括接近式广告、智能钱包、近场通信（NFC）相关的购买行为。

上述几项只是物联网服务中的冰山一角，其他领域还包括银行业、制造业、医疗业、农业和交通运输业等。

个人云

既然有为物服务的云，为什么不能有为人服务的云？个人云是指你个人拥有并服务于个人需求的云。例子不胜枚举：（1）存储文件（你的个人报表、驾驶执照等）；（2）保存你的电子钱包（财务钱包或健康包等）；（3）保存在线购物的购物篮信息；（4）储存音乐与视频（比如亚马逊云盘和苹果iCloud）。以健康包为例，随着物联网和可穿戴设备的兴起，测量血压、心率、体重等健康指标并保存在健康包里的做法开始普及，微软、谷歌、苹果都在开发或试运行此类数据包。如果你通过物联网和可穿戴设备自动监控健康指标，就会和个人云、物与服务云之间产生交集。健康包就是一类个人云，同时由于其与接入物联网的设备相连，并保存你的健康数据，这也是一类物与服务云。物与服务云的服务项目会在健康指标超过一定水平时向你或你的医生、家人发出警示，你还可以使用预测分析等高阶服务。如果你收到一项警告，指出综合多个指标判断，你的健康水平正面临恶化，那你会采取什么行动呢？这能使你积极主动地解决造成报警的相关问题，从而提升健康水平。

经验带来效率

在20世纪60年代中期，波士顿咨询集团（BCG）开发了经验曲线概念：一个企业在生产特定产品或服务中积累的经验越多，其生产成本越低。随着时间发展，云服务供应商不断获取经验，云服务的成本应当随之下降。研究者发现，每当累计经验增加一倍，成本一般会降低20%到30%。这意味着不考虑通货膨胀的情况下，成本会持续下降，下降率则由发展速度决定，业务增长越快，成本下降也越快。这一概念在很多行业、产品及服务领域中普遍使用，但需要特别提示的是，各类产品或服务的经验曲线斜率有所差异，即成本下降率不同。

图41展示了经验曲线的影响，“成本”被表示为在使用云服务的过程中对更高技能的需求和花费的精力，图41中的点1上具有向下的斜率，即当经验随时间积累或应用了创新技术，使得以同样的精力或在同等时间内使用云服务所需要的技术能力更低。

类似的，图中的点3指的是在同样技术能力下曲线平移带来的影响：使用云服务所需消耗的时间或精力减少了。对于使用云服务的机构来说，这就会随时间推移带来更大的成本减少。

云服务交易所

我还有一个创新的想法，使用云服务交易所进行云服务的采购。正如在股票交易所中出售股票一样，云服务交易所对服务进行实时定价与交易，就像商品一样进行买卖。对于IaaS、PaaS这类较低抽象层级的云服务来说，其交易要比BPaaS等高层级服务简单。这类交易所的主要特征是云服务的互通性，从而允许两项服务可以通过交易所无缝、即时地互相替代。服务生产者与消费者共同使用交易所平台来达成交易，每项服务都按照第2章中定义的云模式进行分类。由于价格取决于供需量，因此能够为云服务使用者提供公平的价格。实施价格与服务的实时发现机制，撮合服务与潜在购买方，从而实时完成交易。云计算是IT技术与服务逐步商品化的自然演化，这正是IT世界的未来。

第十二章 后记：思考

本章中将讨论科技、IT特别是云计算会带来的经济、道德、社会问题。很多问题其实是无解的，目的只是让你了解科技在塑造社会乃至整个世界新形态中扮演的角色。下面我会从社会学角度，分别概述科技对各个不同领域的影响。

民主的工具

伯内斯曾说，典型的民主制度为了生存与运行，需要通过各种宣传技术来谋求一致。他指出，要通过挖掘大众的隐性动机，这些技术方能奏效；而若巧妙运用煽动性的辩论（或说诡辩），将有效选择限制在两个选项中，则能获得最为狂热而有力的结果（成功的民主制度总是刚好包括两大政党，并不是事出无因）。在发掘大众隐性动机——或称情感按钮——时，数据分析发挥着十分重要的作用，此类应用于极其庞杂数据的分析技术俗称为“大数据”。如果存在为数不多但规模庞大的公共云可供挖掘，从各类渠道收集所需数据的工作就成了小事一桩。而一旦云计算发展壮大，继而整合成为少数巨头，则各类政治或非政治团体就能更轻易地收集、处理、分析、报告大数据，用于操纵民意，民众的声音也将进一步受到打压。

大分化

2007年次贷危机开始时，美国最有钱的前1%富人拥有全国的34.6%的金融资产。而仅仅四年后的2011年，这1%的人口拥有的财富占比已经达到42.7%。财富从其他群体飞速汇集到这些富人手中，这种贫富分化引发了不同领域的大量争论。而有趣的是，越是这样的时刻，科技越能够抚慰人心。尽管贫富差距一再拉大，生活水平（主要以收入衡量）停滞不前，但我们的生活品质却在提高，我们的寿命更长（感谢医学的进步），我们拥有了智能手机，拥有电力、汽车、电视等。由于技术与医学的飞跃，数十年前还闻所未闻的事物在今天已经司空见惯。创新与技术进步因而成为了无视贫富差距不断扩大的某种借口：反正这种差距总会存在，你就可以理直气壮地辩称这有助于激励人们追求更高的生活目标。然而，社会评论员并不应该以技术与创新作为论据，因为它们只会使争论模糊难辨，也无法解答下列重要问题：（1）是什么造成了差距的扩大；（2）这种差距在多大程度上影响了社会？应当追求以社会与经济创新解决上述问题，而不是拿技术进步当作借口。技术可以作为解决问题的工具，但它并不总能带来答案。

不过，技术越进步——云计算就是很好的例子，就越容易在体育运动与性以外，成为民众“感觉良好”的又一支安慰剂。这些工具使民众保持驯良，并促成很可能进一步扩大的贫富差距。

还有一种说法是技术本身也在制造分化，由于自动化程度的提高，更多平凡岗位被机器取代，意味着缺乏技术能力或使用科技的专业才能者要么失业，要么面临职位下降。与此相反，高级技术人才将会供不应求，从而造成两类群体之间的薪酬差距越来越大，布莱恩约弗森（Brynjolfsson） 和麦卡菲（McAfee）在他们的著作《第二次机器革命》（The Second Machine Age）中对此也有所讨论。

个人信息

世界上大多数国家都很容易获取你的信息，比如你的电子邮件、购物习惯、银行信息与财务细节、位置、旅行计划（如果预定了航班）及各类活动。大部分信息仅仅是被收集起来，可能也不会被恶意使用，但问题仍然存在：就算并非出于恶意，政府有权获取公民信息吗？尽管多数平等国家都有隐私法，这些国家的政府还是可以轻易获取关于你的所有信息。毕竟，如果做一件事十分方便，又无成本，何乐而不为呢。因此，随着云计算应用所带来的IT系统商品化，我们可以谨慎地推断，多数政府都会在不久的将来拥有完全掌控公民私人生活的能力，哪怕是小国家也一样。爱德华·斯诺登事件便证实了这一点。其中隐含的假设是——且不论其对错，大多数政府认同：政府有权监听或收集公民数据，反对者一定存在问题。在一个国家处于动荡时期（国家安全、恐怖主义等）时，这种思潮就会在惊惧的民众中被唤起。奥威尔小说《1984》中虚构的“老大哥”在今天已成为现实，而科技——特别是云计算——则是造就其的关键要素。在未来，随着云计算助推数据分析技术的不断成熟，这种情形还将愈演愈烈。

工作效率

个人电脑在极短时间内改变了商业模式与工作方式。我的第一份工作是在20世纪80年代中期，那时我需要把报告及其他文件写在纸上，并提交给打字组。几小时乃至几天后，我才能拿到打印好的报告并进行检查。如果检查时发现拼写错误，或者有需要修改的地方，我就得重新提交给打字组。等我最终感到满意，就会在报告上签字，然后进行复印分发，整个流程冗长而复杂。今天，打字组已经彻底消失，分发流程也已被电子邮件所取代。这些都要归功于个人电脑。

在20世纪90年代，个人电脑在商务与工作中的不断普及，取代了大量业务流程，在职场掀起一场革命。演讲、报告，用电子表格进行分析——这些都彻底改变了商务格局。生产率得以迅速提升。90年代中期甚至开启了一轮股票牛市，而后逐步发展为2000年的互联网泡沫。云计算不仅与个人电脑一样加快了商业节奏，还进一步提升了自动化水平。如果一家公司想要自动化某项流程、引入新的软件或是使用一项商务服务，就不必在运算基础设施上进行投资，而只需签署一个按月付费协议，就能马上获得大容量量贩式的运算设施。在这类技术的启发帮助下，很多商业功能够实现自动化，从而带来工作效率的提升，那么另一轮牛市的到来也就为时不远了。由于这期间有很多岗位被替代，可能引发对社会的冲击，但只要经济学中的要素替代弹性理论仍然有效，就会有与流程相关的新工种被创造出来取代原有职位。

业务延展性

科技让世界越来越小。在过去，一家新企业可能需要花上数年才能达到一定规模，而现在达到同等规模则可能只要几个月时间。当然，不仅仅是科技相关产业如此，艺术家、作家、零售业主、制造商、各种各样的企业与个人都在充分利用科技来拓展范围与规模。比如《哈利·波特》的作者J.K.罗琳，她拥有更为广阔的全球市场，因而比过去任何作家赚的钱都要多，包括莎士比亚在内。音乐产业亦是如此，在网飞公司、亚马逊金牌会员、苹果iTunes或谷歌应用的传播下，世界任一角落都能听到音乐，一位音乐人也可以在几毫秒时间内获得全球性的传播。自动化的业务流程和信息也拥有相同的全球影响力，这也是为什么云计算能够成为企业家以最小财务成本快速启动新业务的最佳路径。

致 谢

写作本书费时弥久。由于本职工作量的增加，我很少能在晚上或周末抽出时间用于写作，因而整整一年过去，我才得以完成文稿的90%左右。然而不幸的是，我在进行电脑系统硬盘升级时犯了个低级错误，一下子丢失了所有文稿。尽管我使用的网络存储（network attached storage，NAS）服务具有海量空间，但正所谓百密一疏，无论如何，大部分稿件都不得不重写。但熟能生巧，我认为这第二稿比初稿要好很多。历经种种麻烦，出版商依然坚定地与我并肩作战，尤其是马克·洛温塔尔（Marc Lowenthal）和玛丽·李（Marie Lee）。没有他们的信任与耐心，本书绝无可能面世。还要感谢凯瑟琳·赫胥黎（Kathleen Hensley）和南茜·伍尔夫·科塔里（Nancy Wolfe Kotary），她们为本书的润色提供了重要帮助。

词汇表

聚合（Aggregation）

定义单一构成的关系，如森林是树木的聚合。其中包含的假设是所有树木的特征或属性都是相似的，如果这些树木品种不同，具有差异化的特征，聚合关系就不再适用，取而代之的是复合关系。

BPaaS

业务流程即服务，见“服务模型”。

资本支出（CapEx）

计入资本项下的支出。创建一个产品或服务的前端支出，由你或第三方承担，也称为“实施成本”或“非经常性成本”。

变化管理（Change management）

变化管理关注服务或服务组件的增加、修正和移除以减少意外、中断与重复工作。

云爆发（Cloud bursting）

一项云服务或应用实时激增，而使用另一个云中的资源，以满足激增的需求或业务连续性的要求。

云单元（Cloud cell）

本书中提出的新概念，用于定义一项独立的云服务，可以实现单项业务或技术功能，是在云端实施的微服务。将一系列云单元共同使用，就能提供合成式的特定云服务。云单元之间可能存在复合、封装、联合等关系。

云服务（Cloud service）

通过一系列互相关联的功能组件与资源实施某项业务流程，向服务的终端用户提供商业价值。

社区云（Community cloud）

定向为一个有限群体提供共享云计算服务，群体成员具有共同需求或共同用例，此处的需求多种多样，如商业需求（合规要求）、个人需求（爱好或养老金）或社会需求（州或国家）。

复合（Composition）

定义包含组件的关系，如一辆车是由一系列独立组件复合而成，如方向盘、轮胎、发动机罩、车门等。每个组件都有其独特特征。

更新性（Currency）

指计算资源的技术更新程度，一般用软件版本号或第几代硬件来表示。

交付模型（Delivery model）

终端间流程、方法、质控程序及全球化技能的有效结合，使IT部门得以满足其业务需求。

弹性（Elasticity）

利用水平可扩展性，在需求较高时对云服务量进行扩展，需求较低时则进行收缩。

封装（Encapsulation）

指云服务的复合或聚合。这一概念源自面向对象的编程设计，即一个对象可以封装另一个。

联合（Federation）

以类似联盟的方式将独立的云或云单元组建为复合云服务，其中的云服务可由不同供应商提供，但也可以与你自有或第三方拥有的云单元进行混编。

混合云（Hybrid cloud）

在政策驱动下协调组成的私有云与公共云的混合体，以管理并使用这些云服务。

IaaS

基础设施即服务，见“服务模型”。

INaaS

信息即服务，见“服务模型”。

互通性（Interoperability）

使用不同供应商提供的相同或相近的云服务的能力，需要具备支付、管理、报告、数据、应用或流程功能。

信息技术基础构架库（ITIL）

从操作角度对IT服务的全生命周期提供指导框架，包括定义、开发、管理、交付与优化。由于它提供的是IT服务管理的最佳操作建议，因而其描述性意义大于规范性意义。

成熟度模型（Maturity model）

用于评估云计算服务使用与管理的成熟程度，并指出可优化领域的模型。供机构在明确的对照下，对其方法及流程进行评估。

多租户（Multi-tenancy）

集合虚拟或物理资源，如软件、存储空间、虚拟机等，为云服务的各个用户提供共享式的服务。

操作层级协议（OLA）

供应商与机构内部用户（或在供应商与终端用户）之间的内部协议，机构内部用户需要向终端用户提供服务。

运营开支（OpEx）

运营项下的开支，是在使用云服务时需要持续支付的操作性成本，也称为“运行成本”或“经常性成本”。

PaaS

平台即服务，见“服务模型”。

私有云（Private cloud）

云计算的一种形式，只由单一主体进行使用，该主体可以是机构、个人或物品。私有云能保证通过云服务共享的计算资源只按需求提供给特定的主体。

公共云（Public cloud）

云计算的一种形式，可以由一定数量的主体共享使用。主体可以是机构、个人或物品。公共云使得云计算资源被集中在一起后，按需求供这些主体使用。

路线图（Roadmap）

升级或更新云组件的未来计划。

SaaS

软件即服务，见“服务模型”。

服务（Service）

集结IT系统、组件、资源，共同为终端用户或消费者提供价值。参见“云服务”。

服务模型（Service model）

云计算主要包括五类服务模型：基础设施即服务、平台即服务、软件即服务、信息即服务和业务流程即服务。服务模型指你能使用或创建的云服务类型。

服务层级协议（SLA）

服务使用方与提供方之间的合约，多为书面签订，约定服务的交付时间（何时）、服务质量（何种）、服务范围（何处、数量）。

服务层级目标（SLO）

服务供应商用于衡量实施情况的指标，用于确保其满足服务协议或操作层级协议的要求。

瘦客户端（Thin client）

可以是设备、应用程序或服务。瘦客户端设备上不安装应用程序，仅用于远程接入托管在云端的应用或服务；瘦客户端应用程序或服务被托管在服务器（传统托管）或云端，可以通过瘦客户端设备或肥客户端设备进行访问。

零客户端（Zero client）

与瘦客户端类似，差异在于其操作系统和浏览器都内置在硬件中。

[1]也被称为“边际效用递减法则”，指在其他条件不变的情况下，如果一种投入要素连续地等量增加，增加到一定值后，所提供的增量就会下降，即可变要素的边际产量会递减。

[2]指《设计模式》一书的4位作者：埃里希·伽马（Erich Gamma）、理查德·赫蒙（Richard Helm）、拉尔夫·约翰逊（Ralph Johnson）和约翰·威斯德斯（John Vissdes）。

[3]IT咨询公司高德纳每年发布的一个报告，利用时间轴与媒体曝光度，使企业评估是否采用某一新科技。

如果你不知道读什么书，

就关注这个微信号。

微信号：shudanlaile

【书单来了】已提供120个不同类型的书单

1、 25岁前一定要读的25本书

2、 20世纪最优秀的100部中文小说

3、 10部豆瓣高评分的温情治愈系小说

4、 有生之年，你一定要看的25部外国纯文学名著

5、 有生之年，你一定要看的20部中国现当代名著

6、 美国亚马逊编辑推荐的一生必读书单100本

7、 30个领域30本不容错过的入门书

8、 这20本书，是各领域的巅峰之作

9、 这7本书，教你如何高效读书

10、 80万书虫力荐的“给五星都不够”的30本书

……

关注“书单来了”微信公众号，即可查看对应书单

如果你不知道读什么书，就关注这个微信号。