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

本文介绍三个云类别中的第一个：基础架构即服务（infrastructure as a service，IaaS）。IaaS 的一些关键概念包括：

• 云爆发（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 的主要方面

与其将互联网想象成一个单一的全球云，将其想象为由许多云组成的一个系统（比如一个暴风雨云）可能更准确。通过这种比喻，就可以从逻辑上断定：闪电是云际通信的天气系统等价物。假设那些云以一种系统方式相互交互，创建一个单一结果：互联网，从这个意义上讲，上述比喻可能更准确。

但互联网不太可能只由一个云组成 — 至少在不远的将来不太可能 — 原因是云计算标准缺乏，且企业也没有进行长期投资以消除供应商锁定的明显尝试。不管怎样，如果它不是有利于资本主义精神的创新，云计算也无法发展到今天的程度。也许有一天，互联网真的能成为一个单一、互联的云，在那个云中：虚拟机可以轻松转移到 “那个云”，而不必担心文件格式；互联的 VM 集群可以跨服务提供商得到管理 — 只需通过一个界面即可实现。但在此之前，我们还是认为互联网由很多云组成。（具有讽刺意味的是，我正在使用 Apple MobileMe 云来存储这篇文章，这样我才能跨几个设备处理它。）

了解弹性基础架构

弹性是 IaaS 的首要关键方面。为了阐述弹性的概念，我需要您展开想象。假设云由一些粘在一起的棉花糖簇组成，这样人们就可以坐在它们上面。每个棉花糖都能承载一定数量的人，具体取决于组成云的棉花糖簇的数量和那些簇中包含的棉花糖的数量。随着越来越多的人登上棉花糖云，您可以通过粘贴更多的棉花糖来扩展棉花糖簇，增加表面面积。您可能已经明白，人代表需要计算资源的应用程序，比如承载网站并运行软件的资源。棉花糖簇代表 VM 集群，每个棉花糖代表一个 VM。

尽管这听起来有点像 Seuss 博士的书中可能出现的内容，但它提供了一种方法来理解许多黑魔法（dark art）考虑的一个概念：弹性集群化（elastic clustering）。集群化几个物理服务器来形成一个虚拟云称为云集群化（cloud clustering），如果它真是一种黑魔法，则精通程度通过一位艺术家的系统设计的可伸缩性来衡量。

我们来看一个例子。假设您是一位为美国政府工作的统计研究员。政府有点人手不足，您刚刚接受一个任务，需要编辑最近的美国人口统计的所有数据。您负责制定必要的统计数据，以便议会能够制定关于经济恢复资金分配和从现在起三天内的税收金额的重要决策。毋庸讳言，这是一项非常重要的工作，您的时间有点紧张。而且，您必须处理的数据量简直是个天文数字，您刚刚发现，编辑那些统计数据需要的计算资源需要 IT 部门三周时间才能准备好！

这种问题正是您可以使用 IaaS 轻松缓解的。事实上，使用 IaaS，您可以在一小时之内完成全美人口普查数据分析。您首先创建一个服务器的单个实例，这个服务器包含在数据上运行查询需要的数据库软件。这个实例称为一个映像。

当您部署映像并将数据导入数据库之后，就可以根据需要复制那个映像任意多次，并开始运行您的数据处理任务。当任务运行时，您可以手动或自动添加和移除资源。例如，如果计算任务的运行速度不够快，只需将更多机器实例副本添加到集群。

理解弹性概念之后，现在我们来看看 IaaS 的第二个主要方面：虚拟化。

机器虚拟化

Sergey Brin 和 Larry Page — Google 的创始人 — 早在 1995 年就有了正确的想法，当时他们每天晚上都在斯坦福大学的计算机科学大楼后面的废料箱里翻检，找出被人忽略的计算机零件。他们将那些随意的、基于 x86 的计算机零件带回宿舍，将它们添加到托管具有传奇色彩的 “爬网蛛” 的 Frankenstein 机器上，爬网蛛 — 两次 — 记录下了斯坦福市的整个网络 。

今天，Google 预计在 12 个主要数据中心拥有超过 100 万台 x86 服务器，在各大洲拥有约 20 个小型数据中心。那是一个非常大的云。两个系统设计关键因素曾在 1995 年允许他们伸缩他们的 “宿舍怪兽”，而它们仍然适用今天的 Google 网络中的一百多万台服务器。直到今天，Google 仍然继续使用廉价的 x86 零件，而不是许多公司数据中心中昂贵得多的企业服务器组件。其次，故障转移、冗余性、监控、集群化和其他基础架构管理任务通过在操作系统层之下运行的一个虚拟系统来处理，而不是使用负载平衡器之类的独立硬件来处理类似任务。

IaaS 很容易定位，因为它通常是独立于平台的。IaaS 有一个硬件和软件资源组合组成。IaaS 软件是低级代码，独立于操作系统运行 — 称为虚拟机监控程序 — 并负责管理硬件资源的库存并根据需要分配上述资源（见 图 1）。这个过程称为资源共用（resource pooling）。 虚拟机监控程序实现的资源共用使得虚拟化成为可能，虚拟化使 多租户计算（multi-tenant computing） 成为可能 — 多租户计算概念指由几个组织共享的一个基础架构，这些组织在安全需求和遵从性问题方面有类似的兴趣。

图 1. VMs、虚拟机监控程序和计算机之间的关系

通过 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 的两个主要成分是计算平台和解决方案堆。

为了说明这两个 “成分”，我们进一步研究一下它们的定义。按照最简单的形式，计算平台 是指一个可以一致地启动软件的地方（只要代码满足平台的标准）。平台的常见示例包括 Windows?、Apple Mac OS X 和 Linux? 操作系统；用于移动计算的 Google Android、Windows Mobile? 和 Apple iOS；以及作为软件框架的 Adobe? AIR? 和 Microsoft? .NET Framework。要记住的重点是，计算平台不是指软件本身，而是指构建并运行软件的平台。图 1 提供一张示意图以帮助理解这种关系。

图 1. 云计算分类与 PaaS 元素之间关系的图形化解释

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

选择提供商

解决方案堆也反映不同 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. 三类云计算的概念交叉矩阵

SaaS 推动 ROI 的四个因素

SaaS 给软件厂商提供了新的机会。尤其是，SaaS 软件厂商可以通过四个因素提高 ROI：

• 提高部署的速度
• 增加用户接受率
• 减少支持的需要
• 降低实现和升级的成本
• 部署的速度

在过去，部署传统的桌面应用程序需要很大的工作量。实际上，我曾经多次听到桌面应用程序开发人员把更新他们的应用程序称为 “部署噩梦”。正如 Tariq Ahmed 在 Flex 4 in Action (Manning Press) 的第 1 章中指出的，“要想让数千甚至数万客户机同时运行软件的某一版本，后勤方面的复杂性是非常高的。”

Ahmed 说，复杂性这么高，以致于大多数桌面软件开发公司甚至认为这根本不合理或不可行。过去受到这个问题困扰的开发商应该考虑部署软件的 SaaS 版本。但是，妨碍传统软件开发公司进入 SaaS 市场的最大障碍是让桌面应用程序能够作为 SaaS 应用程序运行。在许多情况下，这需要在某种程度上重新编写软件，一些公司觉得这么做成本太高。

这正是向云计算转移的过程比较缓慢且平缓的主要原因之一。在大多数情况下，符合逻辑的解决方案是分阶段地把软件转移到云中，首先以 SaaS 的形式提供原应用程序的高度简化的版本。考虑到开发商对版本控制的控制水平，这么做是很合理的。在这里，分析一下 SaaS 的特点会很有帮助。

您可以看出在云计算与过去的 “LAN 计算” 之间有许多相似之处。典型的 LAN 架构由站内的许多工作站组成，它们常常被称为哑终端，它们通过连接强大的大型机（常常由 IBM 提供）运行应用程序，见 图 1。

图 1. 显示在基本 LAN 中客户机终端与大型机系统的关系的简单示意图

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

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

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

增加接受率

如果您走出企业，看看 SaaS 对于一般消费者的意义，就会发现以前一些软件的许可证费用太高，而现在 SaaS 让一般消费者能够以合理的价格使用它们。一个好例子是 Adobe 以 SaaS 的形式提供 Adobe? Photoshop?。尽管这项工作是 Adobe 正在做的试验，但是已经取得了一些效果。例如，我注意到在需要执行简单的照片编辑任务时，在我的朋友和家庭成员中越来越多的人开始使用 Photoshop.com 进行基本的照片编辑，而不是启动全功能的版本。出现这种趋势的原因是，不需要完整版本中的功能的人现在可以省钱。与此同时，过去不使用 Photoshop 的人也开始使用 Photoshop.com 了，这给 Adobe 带来了争取新的长期客户的机会，扩大了潜在客户的范围。

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

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

减少支持的需要

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

另外，传统桌面软件应用程序的开发商常常必须支持多种平台。例如，开发商可能必须支持 Windows? 7 和 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 编程模型，从而适应企业的要求。云计算不仅仅是通过虚拟化提供可伸缩的基础设施和平台可移植性。它还把软件提升到全新的水平，可以认为它代表着新一代计算机编程模型。这一论断可能比较大胆，但是考虑到本文中讨论的 SaaS 提供的机会，这并非没有根据。

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

结束语

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