云计算服务模型

第 1 部分: 基础架构即服务

• 云爆发（cloudbursting）

• 多租户计算（multi-tenant computing ）

• 资源共用（resources pooling）

• 虚拟机监控程序（hypervisor）

最重要的是了解 IaaS 与众不同的两个方面：弹性和虚拟化。

IaaS 的价值

对于企业而言，IaaS 的巨大价值通过云爆发（cloudbursting） 概念实现 — 云爆发是指当需要的计算资源最多时将任务卸载到云环境的过程。云爆发促成的资本节约潜力巨大，因为企业无需额外投资利用率很低的服务器，那些服务器一年中只有两三次使用 70% 的容量，其余时间仅有 7-10% 的负荷。

但是，对于要在这方面利用 IaaS 优势的企业而言，IT 部门必须能够构建和实现能够将一些流程重新分配到一个 IaaS 云的软件。要构建和实现能够管理这种再分配流程的软件，需要考虑 4 个重要事项：

• 事实证明，如果某个供应商可能会停业，那么针对该供应商的专有 IaaS 进行开发将是一个代价不菲的错误。

• 编写良好的资源分配软件通常比较复杂，需要顶尖的开发人员资源，这种资源的成本不会低廉。预先为您能找到的最好资源准备更多预算将为您自己和您的组织节约大量时间、减少挫折并消除预料之外的费用。

• 您需要将什么发送到云并在云中处理个人身份、财务信息和医疗保健之类的数据发送到云将使您面临违反美国 Sarbanes-Oxley (SOX) Act、Payment Card Industry (PCI) 或 Health Insurance Portability and Accountability Act (HIPAA) 法规的风险。

• 务必理解转移企业日常运营关键流程的危险。一个好主意是事先绘制一张包含三列的表，第一列是涉及合规性关键数据的流程，第二列是涉及业务关键任务的流程，第三列是涉及非关键任务的流程。然后，计划在第一阶段只让软件卸载第三列中的项目。

另外，组织需要注意云计算市场的供应商锁定（lock-in）状态。拥有可以从数据中心移动到云环境和在供应商的云之间移动的虚拟机（VM）对于企业而言可能是一种资产，但这需要供应商支持一种标准文件格式，而供应商通常不愿意那样做。

而实际情况是，目前没有一种公开规范或位于一个标准组织之下的规范。换句话说，目前没有一种真正标准化的格式，这种情况的结果至多是使事情变得复杂，原因是没有人保证您的构建基于的格式将来会受到支持。但是，有一点值得注意，假如这种新格式的规范是公开的，或者您拥有访问它的权限，那么将一种虚拟设备移植到另一种格式通常是可行的。令人感到欣慰的是，最近在对 Open Virtualization Format (OVF) 的支持方面取得了重大进展，OVF 很有可能成为标准。另一个有希望的候选项是 Virtual Machine Disk (VMDK) 格式。VMDK 最初是 VMware 的一种专有格式，但现在它公开了，并受到了几个第三方组织的支持。

基础架构即资产

为展示云计算的演变过程，我们来回顾一下汽车工业在过去 50 年内的发展历程。在上世纪 60 年代到 70 年代，汽车制造商的相对优势完全取决于马力和扭矩。但是，到了 80 年代，事实证明这种模式不利于市场和环境，这迫使模式从基础架构即资产转移到基础架构即服务。

类似地，大量成功的公司在过去 50 年之内花费大量宝贵时间和资源来构建基础架构，其目标是通过创建一个更大、更快、更强的 络来获取战胜其竞争对手的竞争优势。IT 行业中的 “基础架构即资产” 范式拥有上世纪六七十年代的 “暴力跑车（muscle cars ）” 所拥有的相同或类似的低效率和不利特征。对于企业计算，这些低效率包括：

• 大量未使用的计算能力和容量，它们耗费的成本与大型、昂贵的数据中心中的硬件消耗的大量空间相关联。

• 昂贵的人力资源需求，包括要求基础架构资产（服务器、路由器、交换机等）所在的数据中心的 络管理员进行 24 小时监控。

• 旨在应对高水平能源浪费的 Green Computing 计划的一个巨大障碍。

为帮助您理解云计算的这三个类别，我创建了一个跨概念矩阵供您参考（参见 表 1）。范式（paradigm） 是大多数用户遵循的模式。如前所述，IaaS 标志着从 “基础架构即资产” 到 “基础架构即服务” 的转变。云计算的其他两个类别（见 表 1）也标志着范式转变。对于 Platform as a Service (PaaS)，转变来自 “平台即资产” 范式，该范式的特征是大量采购许可。同样的转变也适用 Software as a Service (SaaS)，这种转变是从 “软件以许可形式作为组织资产” 到 “软件以服务形式提供”。本系列第 2 和第 3 部分将分别讨论 PaaS 和 SaaS。

表 1. 三个云计算类别的跨概念矩阵

通过 IaaS，您拥有提供处理、存储、 络和其他计算资源的能力，您可以在那里部署和运行任意软件，比如操作系统和应用程序。大多数云计算用例遵循您已经习惯的基础分层结构：一个软件解决方案堆栈或平台被部署在一个 络基础架构上，一些应用程序在那个平台之上运行。但是，虚拟化使得云范式独一无二。

第 2 部分: 平台即服务

平台即服务 (PaaS) 常常是最容易让人迷惑的云计算类别，因为很难识别它，常常把它误认为是基础设施即服务 (IaaS) 或软件即服务 (SaaS)。在这个分三部分的文章系列的第二部分中，了解 PaaS 的特点以及如何在企业中应用它。

PaaS 的独特特点是，它让开发人员可以在驻留的基础设施上构建并部署 web 应用程序。换句话说，PaaS 让您能够使用云基础设施似乎无穷的计算资源。

当然，计算资源的数量看起来无穷只是幻想，限制取决于基础设施的规模。但是，正如在本系列的第一篇中了解到的，Google 基础设施大约包含超过一百万台基于 x86 的计算机。另外，因为用于 PaaS 的基础设施是弹性的（第 1 部分中讨论过这个概念），在需要时云可以扩展以提供更多的计算资源，所以无穷的资源并不完全是想像。

PaaS 对于开发人员的意义

开发人员常常误以为云计算只适用于 络管理员。但是，这个错误的观念忽视了云计算可能给开发和质量保证团队带来的许多好处。

在软件开发过程中，一些东西常常会出问题。以我的经验，设置服务器环境以驻留开发团队要构建的 Web 应用程序可能会带来许多争吵。即使在最大的企业中，通常一位 络管理员要负责为几个开发团队服务。在不使用 PaaS 的情况下，设置开发或测试环境通常需要完成以下任务：

• 获取并部署服务器。

• 安装操作系统、运行时环境、源代码控制存储库和必需的所有其他中间件。

• 配置操作系统、运行时环境、存储库和其他中间件。

• 转移或复制现有的代码。

• 测试并运行代码以确保一切正常。

在很多情况下，管理员已经非常忙了，所以让他们抽出时间部署新环境会很困难。对于客户机和服务器端的 web 应用程序开发人员来说，另一个主要问题是在本地复制运行时环境以便执行测试。

现在，想像一下您是使用 PaaS 的开发团队的成员。在这种情况下，您会有一个虚拟机 (VM)，其中包含完整的服务器环境，可以把它放在 USB 闪存驱动器中带在身边。

我希望您把注意力转到第 1 部分中给出的概念交叉矩阵上，使用它作为参考分析 PaaS。表 1 再次给出这个矩阵。

表 1. 三类云计算的概念交叉矩阵

既然理解了计算平台的概念，现在就来看看什么是解决方案堆。解决方案堆由应用程序组成，这些应用程序有助于开发过程和应用程序部署。这些应用程序是指操作系统、运行时环境、源代码控制存储库和必需的所有其他中间件。

选择提供商

解决方案堆也反映不同 PaaS 公司的差异，在决定采用 PaaS 之前，需要深入考察各个提供商提供的解决方案堆。

在与某家 PaaS 提供商签约之前，您应该问几个基本问题：

• 它支持哪些框架和语言想情况下，PaaS 应该支持基于此平台选用的语言的任何框架。

• 可以创建多少个应用程序多数 PaaS 提供商会根据您签订的计划或服务包限制可以构建的应用程序数量。要确保提供商提供的计划或服务包能够满足您的需要。

• 允许哪些内容类型持 PaaS 的基础设施通常涉及多租用者计算 的概念，也就是说许多 “租用者” 分享单一服务器上的 “空间”，这些空间由系统管理程序 管理的 VM 实例分隔。PaaS 提供商可能会对要驻留的应用程序和内容的类型加以限制。

• 支持哪些数据库类型果您的数据要随应用程序转移，这个问题就是非常重要的。必须确保提供商提供的数据库与您想要用来导入数据的格式兼容。

• 它是否支持 SSL (HTTPS)个问题对于确保安全性非常重要。如果您打算通过应用程序处理事务，但是发现不支持 SSL，您就遇到×××烦了。

PaaS 剖析

既然已经了解了 PaaS 的基本知识，现在研究一下在比较 PaaS 提供商时应该考虑的特性：

• 应用程序开发框架。健壮的应用程序开发框架应该基于广泛使用的技术。理想情况下，您应该避免厂商锁定。使用 Java技术等开放源码框架通常比较好。

• 容易使用。PaaS 应该附带容易使用的 WYSIWYG 工具，应该有预先构建的部件、现成的 UI 组件、拖放工具和对某些标准 IDE 的支持。这应该会促进快速的迭代式应用程序开发。

• 业务流程建模 (BPM) 工具。需要使用强大的 BPM 框架对业务流程进行建模，围绕业务流程构建应用程序。

• 可用性。应该能够在任何时候从任何地方访问并使用所选的平台。

• 可伸缩性。平台应该足够智能化，能够利用底层基础设施的弹性计算能力处理应用程序将承受的负载。

• 安全性。为了有效地防御安全威胁，平台应该解决跨站点脚本、SQL 注入、拒绝服务和通信流加密等问题，并让安全措施完全融入应用程序开发中。另外，平台必须支持单点登录功能，让您能够把它与现有的内部应用程序或其他云应用程序集成起来。

• 包容性。平台应该能够包容、嵌入和集成在相同平台或其他平台上构建的其他应用程序。

• 可移植性。平台应该不限制底层基础设施类型，允许公司把应用程序从一个 IaaS 转移到另一个。

• 移植工具。为了轻松、快速地把数据从陈旧的内部应用程序迁移到基于新平台的应用程序中，平台的工具包中必须有批量导入转换工具。

• API。为了执行各种任务，比如用户身份验证、存储和获取文件（例如 Web 应用程序文件和资产）甚至直接调用数据库，平台应该有文档齐全的 API。这让企业能够灵活地创建和定制软件应用程序以与平台交互，从而满足公司的特殊需要。

避免厂商锁定

厂商锁定 (Vendor lock-in) 意味着消费者依赖于某一厂商，除非花费巨大的转换成本，否则无法使用另一厂商的产品。当采用像云计算这样的正在流行起来的新技术时，会增加出现厂商锁定局面的机会。早期的使用者必须很清楚他们将处于什么境地，然后才能够签署长期的 IaaS 和 PaaS 协议。

避免厂商锁定的方法之一是通过 API 和平台技术的标准化。Simple Cloud（见 参考资料）等组织已经开始与参与这个开放源码项目的各种规模的厂商协作，力求让云中的 PHP 保持一致。为了创建 Simple Cloud，Zend Technologies、Microsoft、IBM 和 Rackspace 正在共同努力，其目标是跨不同的平台提供一个抽象层。

Simple Cloud API 的目标是为文件存储、文档存储和简单队列服务创建通用的接口。这让开发人员能够编写出可跨主要云平台移植的应用程序。参与云计算标准化的厂商应该得到赞扬，应该鼓励他们继续努力。在选择为您的公司提供 PaaS 服务的厂商时，我强烈建议优先考虑支持标准化的提供商。标准化会让 IT 部门的工作更轻松，更重要的是，这会节省公司的资金。

为了避免 PaaS 市场上出现厂商锁定，需要支持相同底层 API 的服务提供商。答案很简单：坚持采用专有技术的服务提供商必须同意支持 Simple Cloud 等标准化项目。

第 3 部分: 软件即服务

软件即服务 (SaaS) 为商用软件提供基于 络的访问。您有可能已经使用过 SaaS，即使您当时并不知道。SaaS 的示例包括 Netflix、Photoshop.com、Acrobat.com、Intuit QuickBooks Online、Gmail 和 Google Docs。可能不太明显的 SaaS 实现包括移动应用程序市场中的相当一部分。

SaaS 为企业提供一种降低软件使用成本的方法 — 按需使用软件而不是为每台计算机购买许可证。尤其是考虑到大多数计算机在差不多 70% 的时间是空闲的，SaaS 可能非常有效。企业不必为单一用户购买多个许可证，而是让许可证的使用时间尽可能接近 100%，从而尽可能节省成本。

为了方便，表 1 再次给出本系列第 1 部分中提供的三类服务的概念交叉矩阵。

表 1. 三类云计算的概念交叉矩阵

这种计算类型过去非常适合企业，因为 IT 部门能够完全控制版本，可以非常方便地多次部署更新。同样，过去妨碍桌面软件应用程序开发商进行版本控制的后勤障碍在云中也不存在，因为软件在开发公司能够直接访问的基础设施上运行。

考虑到 SaaS 必须能够服务的客户机数量，SaaS 基础设施的规模要比 LAN 大得多。但是，底层的概念是相同的。图 1 所示的大型机能够驻留足够多的软件实例，从而为本地 络中连接它的所有客户机提供服务；而 图 2 所示的云由许多不同的计算机资源组成，它们共同提供计算能力，从而运行为世界各地的客户机提供服务所需的许多软件实例。

图 2. 显示在 SaaS 中客户机设备与云的关系的简单示意图

增加接受率

SaaS 提供的多种业务模型尤其有吸引力。例如，Intuit 以 SaaS 的形式提供 QuickBooks Online，按月收取服务费。作为经常旅行的企业主，我发现这种服务非常有用，尤其是因为我的业务伙伴住在 400 英里外的另一个州里。同时，Adobe 在 Photoshop.com 和 Acrobat.com 中应用了 SaaS，以 freemium 服务的形式提供软件 — freemium 服务是指一种基于许可证软件产品的 SaaS 缩略版的业务模型。

freemium SaaS 基于的收入模型是，预计免费用户中的一部分最终会觉得软件很有用，他们会升级到启用了更多特性的 SaaS 付费版本，或者购买包含所有特性和功能的桌面版本的许可证。这种方法往往比通过 “受限制的演示” 模式试用软件更好，因为演示模式要求用户在桌面计算机上安装他们可能不会购买的应用程序。另外，如果免费用户中升级的比例低于预期，还可以通过广告进一步补充这个模型。随着云计算的发展，传统的桌面软件厂商经常使用这种方法适应市场的变化。

减少支持的需要

大型客户服务中心的成本很高，不得不支持多种平台会导致支持问题增加，而 SaaS 可以大大缓解这些难题。首先，部署的简便性让开发人员能够在发现 bug 之后很快进行修复，这意味着大多数 bug 可以在大量用户遇到它们之前被修复，这会减少客户支持部门接到的电话数量，提高客户满意度，降低客户流失的可能性。

另外，传统桌面软件应用程序的开发商常常必须支持多种平台。例如，开发商可能必须支持 Windows7 和 Apple Mac OS X 10.6 操作系统，添加对第二种操作系统的支持差不多会让开发成本加倍；而且，如果支持这些操作系统的许多不同版本，问题会更多。支持操作系统的多个版本还会产生限制。

例如，如果您要构建一个在 Windows 7 上运行的程序，但是它必须与 Windows XP 兼容，就必须非常小心，要确保特性和功能在这两个版本上都能够运行；否则，就必须把项目分为两个分支，为每个版本开发单独的代码，这会不可避免地降低生产力和效率，延长完成项目的预期时间。让业务执行官心跳加速的最快方法之一是，告诉他后两年的预期开发进度要减慢一半儿。另外，支持不同的操作系统和这些操作系统的不同版本会增加预算；这个问题和其他因素导致目前软件开发项目的失败率非常高。

降低实现和升级的成本

SaaS 推动 ROI 的第四个因素与第一个因素有点儿相似。但是，部署的速度 是指快速、简便地部署应用程序更新所带来的好处。与之相反，降低实现和升级的成本 是指开发公司由于能够控制版本和运行软件的基础设施所获得的经济利益。

因为开发商可以控制运行软件的平台（平台通常对于用户完全透明），所以他们不必负担在多个平台上测试和部署 bug 补丁和新特性的额外开销，这会节省大量资金。这让 SaaS 应用程序的升级成本更低。节省的大量时间和资金让开发商有机会更好地响应客户的请求并增强易用性，从而提高客户满意度，降低客户流失的可能性，这会带来间接的经济利益。

SaaS 和用户体验设计

SaaS 应用程序代表着一种新一代应用程序设计方式。尽管在我目前看到的文档中没有明确地指出，但是看起来 SaaS 程序也带来了一种新的 UI 设计方式，这种方式与大多数其他行业中的产品设计流程更一致。这种方式包含一个称为用户体验设计 (UXD) 的流程，在这个流程中由产品团队而不是开发团队设计 GUI。

UXD 的主要目的是，确定哪些特性会让应用程序对于目标客户最有价值，并在设计中融入这些知识。尽管对于是否应该在所有类型的软件的开发中都执行这个流程有争议，但是在 SaaS 应用程序开发中这种做法非常普遍。出现这种现象的原因可能是，SaaS 可以实现的业务模型与传统软件不同，需要执行 UXD；而且通过开发 SaaS 可以节省大量时间和资金，让开发商有能力执行 UXD。

SaaS 对于开发人员的意义

正如您看到的，完全成熟的云计算对于企业和消费者来说都是巨大的转变，必须克服很多难题。因此，这个转变过程会花费一段时间，要经过几个阶段的渐进迁移。在这次计算模式演变期间，软件开发商必须能够适应变化的环境，从而继续满足企业和消费者的需要。

例如，一般消费者能够负担软件费用意味着潜在客户更多。能够控制平台、基础设施和软件版本会直接节省成本。显然，SaaS 很快会带来某种程度的 “民主”，也就是说中小型的开发企业也能够与大型开发商在同一领域中竞争。

结束语

在阅读之后，我希望您对云计算对于您的职业前途和企业意味着什么有了更清晰的认识。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树服务 格(istio)ServiceMesh介绍8756 人正在系统学习中 相关资源：专用的软件解决集墨棉使用寿命已尽-专业指导工具类资源-CSDN文库