内容简介：
云计算和SOA是不同的概念，但是它们却互相联系。SOA是架构模式，而云计算是架构的实例，或者说是一种架构的选择。SOA更具整体性和战略性，它解决的是包括业务驱动力在内的整个企业架构的问题，而云计算则更加侧重战术，它是一种解决问题的方式。它们联系紧密，若要解决企业级的问题，很难取其一而舍其二。
本书堪称云计算与SOA融合之经典著作。书中介绍了企业架构中存在的问题，云计算的价值、优缺点和适用场景；解释了向云计算转型的技术细节、支撑技术和最佳实践方法；帮助你客观评估自己企业中云计算和SOA的可行目标，对其实用价值进行了量化估算并构建了商业案例；概览了如何评估已有的IT基础设施，如何找到通向“云”的最高效、最安全的路径；展示了如何为云平台选择最合适的候选数据、服务和流程；如何对云平台进行更高效的治理等。
评论：
“David S. Linthicum在本书中做了极其难能可贵的工作：他成功地阐述了SOA与云计算为什么能够相得益彰，清晰地讲述了企业如何通过具体方法来充分利用二者间的协作，取得圆满的结局。”
——Jeremy Geelan， SYS-CON媒体与展会公司高级副总裁
作者简介：
David S. Linthicum Blue Mountain实验室的CTO和创始人，国际知名的云计算和SOA专家。曾任多个成功的软件公司的CTO和CEO，也在财富100强企业中担任过高层管理职位。他著有十多本技术图书。多年来一直在InfoWorld、Intelligent Enterprise和eBizq.net等博客网站上发表文章，剖析SOA与云计算等方面的问题。Government Computer News、Cloud Computing Journal、SOA Journal和 Align Journal等刊物上均开设有他的专栏，同时他还是Virtualization Journal的编辑。更频频现身于云计算、SOA、Web 2.0和企业架构等方面的前沿技术大会上发表专题演讲。他在企业应用集成、B2B应用集成和SOA等方面的许多理念，得到了广泛应用。最近十年，他致力于研究云计算相关的技术与战略，以及如何使云计算为当今企业所用。
第1章 大势所趋
第2章 理解云计算
第3章 面向企业的云
第4章 云计算的商业案例
第5章 云计算与数据
第6章 云计算与服务
第7章 云计算与流程
第8章 可控的云计算
第9章 SOA与云计算
第10章 在云平台中定义候选数据、服务和流程
第11章 迈向云计算
第12章 拥抱未来
前 言
随着SOA及云计算逐渐对现代企业产生举足轻重的影响，转向云计算成为IT部门很快将要面对的颠覆性变化。在这个新兴的共享环境中，IT经理在保护企业利益的前提下，不仅要学会如何获得信息，还应学会如何送出信息。创新型企业将利用这类新资源（譬如云计算），将自己改造成市场上不可撼动的一支力量。不利用新资源的企业将会落伍，甚至可能面临倒闭的危险。阅读本书是理解SOA与云计算融合过程中将出现的问题的第一步，也是企业在免遭破坏性力量***的前提下，迎接这次IT复兴的第一步。
该运动及其方向非常清晰。譬如来看看云计算的迅速崛起。据IDC（金融数据公司）报道，基于当前的趋势，“IDC预计，在未来的5年里，在IT云服务上的投资将增长3倍，到2012年，该数字将攀升至420亿美元，占5个核心市场细分营业额的9%。更重要的是，在预测期内，云计算上的投入仍将加速，占2012年IT开销增长的25%，占2013年的30%” 。因此，IDC坚信，以云计算作为交付机制以及在SOA的环境中融合云计算技术将是一场根本性的转变。
此外，Gartner最新一项报告表明，云计算带来的全球营业收入将在2013年达到1500亿美元。该项预测不仅包括从本地向云计算提供商转型所产生的营业额，还包括转型背后的规划及架构所带来的营业额。
是什么促成了这场转型？主要有5个方面的驱动力。
(1) 软件购买者认为，目前花在传统企业软件上的开销与其创造的价值不成比例。
(2) 在这个预算意识强烈的时代，软件解决方案在采购和维护（解决方案的后续支持与维护的成本可达最初成本投资的4倍）上的成本面临极大压力，亟待降低。
(3) 企业急需降低风险，他们需要的是更真实的软件开支与收益之间的关系。
(4) 降低风险的期望要求对企业的软件解决方案的运行成本有更大的预见性。
(5) 解决方案的价值不再由可用的功能来决定（事实上，多数企业只使用了其购买的软件的一小部分功能），而是由用户使用解决方案过程中的感受与体验来决定。
与此同时，企业纷纷转向SOA，希望借助其架构能力，甚至通过专门的混搭方式，提供充分利用云交付的服务并与新兴网络接轨的平台。企业向SOA（包括云计算）的转型被很好地记录了下来，而且随着云中面向服务资源的推动，其发展速度更快。
据Evans Data公司最新的Web服务开发调查，今年有效实施SOA的比例翻番。Web服务在企业内也得到广泛实施，30%的被调查者称，明年使用的Web服务将增加20多个，相对于现在有58%的增长。
——Evans Data公司
此外，另一个明显的运动是，企业通过混搭的方式利用这些广泛散布的服务，在业务需要时，以低廉的成本按需访问业务信息及流程。
混搭意味着软件公司、网站和任何在线个人将面对重大的变化。网络不再仅仅是一组页面的聚合了，它正在变成一种全局性运行系统……能够在线控制的东西越来越多。在此过程中，人们在Web服务上加上了一层包装，兑现了长期以来没有兑现的承诺——按需使用软件和服务。
——商业周刊
需要记住的重要一点是，云计算提供商们将在网上创建巨大的资源。你必须充分利用这些资源，否则你的企业将遭受毁灭性打击，就像在20世纪90年代初，有些公司最初忽视了网络的出现，结果只能被拖在后面拼命追赶。云计算是类似的大趋势，现在是你做好准备迎接新的云计算范型的时候了。它虽然比传统网络复杂得多，但是却能带来10倍的投资回报。本书介绍了SOA与云计算怎么融合，该融合是什么，你可以通过什么步骤将企业IT与此变革性技术契合。
关于本书
对于那些希望利用SOA与云计算融合所带来的优势的人们，本书堪称圣经。它详细阐述了此趋势的技术细节、支撑技术及方法论，给出了一个自我评估的进阶指南，为读者提供了将企业再造成互连的、高效的生钱机器的方法。本书是一本转变思维的书，已经为迎接未来若干年IT交付的新方式做好了准备。它不仅解释了某些技术，还介绍了在企业中使用这些技术的方法与战略。
作为本书的作者，在每一个有助于云计算与SOA融合的研究方向上，我都是公认的权威。写本书的目的是，恰如其分地阐述融合的概念，设定一门学科，跟踪这些技术及其演进过程。基于过去的一些开创性概念，如EAI、B2B、Web服务和SOA，我在阐述本书内容的过程中，有的由外到内，有的由内到外，不遗余力地介绍各个方面。
不论你是IT主管、开发人员还是架构师，都能在本书中找到非常有用的信息。书中很多例子让内容更易于理解，而且，本书的配套网站也提供长期支持。本书要求读者对Web服务、云计算以及相关开发工具和技术等基本知识有基本的了解。然而，即便你不是技术人员，依然会找到本书的价值。它有助于你理解这次革新及其对你的企业的影响。
本书结构
我希望每个章节尽可能简短且到位。过去我曾经按字数来描述我的书，但是本书应该以“每章包含的好想法的数目”来描述。所以，偶尔会有点天马行空，但是阅读本书的体验却可以像坐飞机旅行一样，快速地从一个海滨转到另一海滨。在写作过程中，只要可能，我就会尽量多地使用示例和案例分析。另外，只要外部资源能够说明问题，我一定会使用外部资源。若没有丰富的想法，是不可能写成这样一本书的。
大多数内容都是以传统的章节方式呈现的，但是在章节中间还有些“补充内容”（即书中带底纹的内容），它们用来进一步解释正文中提到的某些概念。在这里，我将补充内容作为快速Brain Dump 以阐明主题。
本书正是为那些总被要求利用有限资源完成很多IT工作的人们而写的。我希望能改善你们的工作状况，希望你的企业能够成功。这是本书与我过去编写的图书的不同之处。过去的图书更多地关注定义事物是什么。本书的确包含一些是什么，但是更多的是怎么做。如果你不知道怎么做，就无法完成是什么。
享受阅读的过程吧！
——David
样章试读
第1章 大 势 所 趋
有些画家把太阳画成一个黄斑，但有些画家凭借他们的技艺和智慧把黄斑画成太阳。
——巴勃罗·毕加索（1881—1973）
这是一个星期四的早晨，你是一家大型上市公司的总裁，几分钟前你刚刚通知了公司的所有主管领导到会议室，准备向他们宣布一个振奋人心的消息：董事会已经批准收购一家重要的竞争对手，你召集大家的目的是号召每个人对此收购做好下一步行动计划。
你跟销售主管谈到双方的销售团队将在3 个月内完成整合，他们对新的前景雀跃不已。转而你与人力资源主管交谈，他已经做好准备在两个月内完成人力资源相关的转变。你与后勤主管谈到此事，他胸有成竹地表示能在3 个月之内完成所有人员必需的座位调整。你的内心充满了自豪。
然而，当你与CIO 谈到改变核心业务流程，适应公司合并时，你得到的回应却不怎么热烈。“我不敢保证在18 个月之内完成我们的IT 架构的调整，使之适应合并带来的变化。”CIO 回答道，“我们不具备整合这些系统的能力，我们需要新系统，一个更大的数据中心……”说到这里，你明白了。
作为CEO 的你不知所措。为什么其他部门可以在不到个月的时间内适应新业务，而IT 却需要近两年的时间呢？
从本质上说，IT 已经成了业务需要转变时最拖后腿的地方。所以，企业的应变能力被IT所制约。在这种情况下，企业的合并在经济上不合算，执行团队除了挠头，无计可施。他们本以为IT就是用新方法实现业务的自动化，而丝毫不知IT人员对于变化的反应为何如此之慢。
然而，事情并不是非这样不可。很多企业的生存将取决于我们在思考和创建未来的IT基础设施的方式上发生根本转变，即你是否愿意承认你现在所处的位置，是否愿意做出改变。有很多工作需要做，而本书就是很好的起点。
1.1 事情因何而失控
了解IT 问题的最好方法，是了解近30 年来IT 的历史以及你公司的IT 历史。历史会告诉你事情为何会发展成现在这个样子。审视你的企业的IT 历史如同参加一个12 步疗程①：你要承认出了问题并且愿意回顾问题发生的过程。
保持谦逊的态度也非常重要。IT 人员往往不喜欢谈论他们过去所犯的错误。事实上，很多人对过去所做的所有IT 相关的决定都会至死捍卫不渝。但重要的是，审视历史不等于追究责任，而是要正视你正在处理的问题并找到解决问题的方法。如果你不能正视现有的问题，那么看完本书也不会为你带来什么益处。
如果每次审视过去所犯的错误，总会有个问题在脑海中浮现的话，那么它就是“受媒体所累”。从本质上说，那些负责建设和管理IT 系统的人过去很少关注哪些对业务最有价值。相反，他们关注的却是哪些是当时最流行的，或哪些是流行的计算机杂志所推崇的，把这些当做解决问题“所需的”技术。
另一个问题是“受惰性所累”，或者说因为害怕新的或未知的事物而到最后一事无成。该问题与“受媒体所累”正好相反：我们不是因为流行而凑热闹，而是死守着现有的IT 架构。通常，缺乏行动源于对变化及其相关联的风险的恐惧。
我们曾进行结构化计算的变革，后来又迎来面向对象计算的变革，接着是分布式对象，后来是组件开发，然后是企业资源规划，再往后是客户关系管理，最后又变成了SOA——没错，你已明了。当然，我还少说了一些“必须拥有”的技术，包括数据仓库、商业智能和业务流程管理等。
这些技术并非坏事，而且大部分都不是。然而，它们会对IT 从业者造成影响，分散他们对核心业务的注意力，使他们转而更多地专注产品化的技术而非业务需求。分散注意力非常容易，因为分析和记录业务需求远没有体验新技术那么有意思，而且它也不会为简历增色。
这种对解决方案的关注超出对问题本身关注的方式导致了企业架构上的断层。从本质上说，架构变得越来越复杂而且笨重，因为当时流行的那些产品被拖入数据中心，形成了另一层复杂性。它不仅增加成本，而且使企业架构更加脆弱、紧耦合而且难于变更。
今天我们所拥有的IT 基础设施和企业架构因为成本太高而难以维护并且几乎不可能变更。随着业务需求的变化，包括经济的起伏，IT 跟随业务需求的步伐越来越艰难。正如我们在本章开头提到的那个例子，CEO 觉察到IT 已成为企业的后腿，导致了滞后和成本超支，而且IT 不能再像以前那样为企业带来价值。曾几何时，IT 是解决之道而非问题所在？
在使用COBOL 在大型机上进行编程的年代，IT 部门更有生产力，原因是它需要开发者吝惜且小心地使用计算资源。今天，我们有太多的技术，太多的选择。我们给了IT 足够的绳索去勒死自己，或者至少使IT 架构走到对业务的价值比以前小很多的局面。
1.2 SOA 来拯救
虽然解决企业中被严重破坏的IT 架构的方法有很多，但大多数“解决方案”仅在现有技术之外套上一层新技术，寄希望于新技术能在某种程度上解决问题。也许你已意识到，它只能使问题变得更加复杂。很少有企业愿意冒险去解决核心问题。
SOA（Service Oriented Architecture，面向服务的架构）的确能解决问题，它通过将大部分现有系统封装成服务，并且把这些服务抽象到一个统一域，并在该域中使用这些服务形成新的解决方案。概念相当简单——其实没有新东西——SOA 是修复破损架构的最佳选择。作为广泛使用的标准，如Web 服务，SOA 被推举为将架构的敏捷带到企业的最好途径——当然，前提是你能正确地使用SOA。这里并不存在什么灵丹妙药。
SOA 是解决当今企业面临的架构问题的有效方法之一。然而，那些实施SOA 的人常把SOA 看做是买来的东西，而不是要做的工作。所以，很多SOA 项目再次变成购买某种“内含SOA 解决方案套件”的技术，最后买的是套件而不是SOA，所以只能带来更多问题。
SOA，正如其A（Architecture）所指，它是一种架构，所以它是为业务需求服务的有序组织的系统。从表面上说，有了SOA，企业的IT 会成功。然而，大多数情况下不会，而且很多企业失败了，因为SOA 实施者没有把SOA 看做是一种架构，而且实施者往往不是架构师。
SOA 是一个有效的架构模式，而且本书通篇都会提到它，但是你需要把SOA 看做一次过程，而不是一个项目，更不是一个产品。同时，你还需要把SOA 分解成一些小规模递增的成果，它们能推动企业向SOA 的核心价值观前进，SOA 在与新兴的概念（如云计算）联合时会显示出更大的威力。而云计算则是本书的另一重点。
我们可以称此为“小SOA”与“大SOA”。大SOA 包含了较大的SOA 战略目标：同步使得所有的IT 资源更加敏捷并且更易于改变。比如，把所有相关的企业系统分解成一个个功能组件，以服务的形式重构这些组件，再增加一个流程配置层用于形成解决方案。考虑到这样的企业通常拥有数百甚至数千个系统，这样的项目需要几年的时间才能完成。
小SOA 仅仅是大SOA 的一个实例。小SOA 依然是SOA，但它有明确的目标、时间表以及一个必须实现的核心投资回报。此处的经验是通过小SOA 实现大SOA。例如，你可以通过SOA 的方法建立一个合作伙伴门户，它只需6 个月即可完成，而3 个月就能见到回报——这样的项目优势清晰、规模小、可行且能在一年内完成。
小SOA 看上去简单易行，大SOA 却因复杂、昂贵而被人们抛弃。事实上，二者都是需要的，但要知道如何去运用它们。从此刻起就应该坚持这个想法。在本书中，我们将不断回顾SOA 方面的话题。
1.3 SOA 究竟是什么？关我何事
首先，我们给出SOA 的定义，这样我们就基于相同的基础开始后续的探索。
SOA 是一个战略性的技术框架，它促使企业内部以及外部所有相关的系统公开和访问定义良好的服务以及绑定于那些服务的信息，它们又进一步抽象成流程层和组合应用，从而形成新解决方案。从本质上说，SOA 为架构增添了灵活性，使得我们可以灵活地通过配置层完成系统的更改，而不再是重开发系统。SOA 的主要优势包括以下几点。
(1) 服务与行为的重用，即不需要大量重开发或集成的工作就能在一个系统中使用另一个系统行为的能力。换言之，SOA 促进了同一应用功能（行为）一次又一次的重复使用而不需要移植代码，就像使用本地存在的行为一样使用远程的应用行为。
(2) 敏捷，即在现有服务及信息流之上，按照需要快速修改业务流程使之支持易变的业务的能力。
(3) 监控，即实时监控信息点与服务点并判断企业应用与交易的健康状况。此外，SOA提供了根据企业的利益实时修改与调节业务流程的能力。
(4) 范围延伸，即可以将某些业务流程公开给其他外部实体，从而实现跨企业合作或共享流程的目的。SOA 可被用作利用云计算（在后续章节中会描述）的关键技术实现手段。
SOA 的理念一点儿也不新。尝试共享流程、信息和服务已经有很长历史了，从十多年前的多层客户机服务器（C/S）结构——为实现重用，由位于公共服务器上的一组共享服务提供企业的基础设施——到今天的用于整合的分布式对象的运动。重用是一个颇具价值的目标。对于SOA 来说，重用就是对服务及其相关信息的重复使用（如图1-1 所示）。一组企业应用间的通用服务促使了重用并极大地降低了服务的冗余度。
SOA 的独特之处在于它不仅仅是一组技术，也是一个战略，而且较之于结果，它更重视过程。
1.4 SOA 遇见云计算
那么，SOA 与云计算之间是什么样的关系呢？我们为什么要写这本书呢？云计算关心的是位于防火墙外的可被企业IT 跨因特网使用的任何IT 资源，包括存储、数据库、应用程序开发、应用服务等。云计算背后的核心理念是，以服务的形式使用这些资源，在需要时进行购买，比购买用于搭建数据中心的硬件和软件要便宜得多。云计算还有其他优势。
云计算允许你直接根据需求扩张和收缩成本。此外，它将扩展IT 资源相关的某些风险转移到云计算提供商一方。我们在第4 章中介绍云计算的商业利益。另外，云计算从资源管理中提取出要交付到云平台中的IT 资源。
云计算与SOA 之间的关系是，云计算提供了你可以按需使用的IT 资源，包括可以托管数据、服务和流程的资源。因此，你可以将SOA 扩展到企业防火墙之外并延伸到云计算提供商，从中寻找前文所描述的SOA 的那些优势。我们将此过程描述成“融合云计算的SOA”，而本书的目的就是要展示它是如何完成的。
SOA 对于云计算的重要性体现在以下几个方面。
它是一个用于合理地创建信息系统的很好的架构方法，使用SOA 的机制使得这些系统在企业内部或外部能很好地运转以及合作。
为了利用云计算的优势，你需要可以延伸到企业外部并接触云计算资源的接口和架构。虽然很多人会简单地在核心的企业信息系统与云计算资源之间创建快捷而随性的链接，但是事实上在企业内部，你还是需要一个架构（如SOA）去使用云计算。这就是本书的主题。
你要用一些架构原则和指导原则去记录和组织架构。在过去几年中，大多数人都忽视了这个需求而过多地关注在特别炒作的东西之上。我们必须回来，用最好的方法解决问题，而如果遵循了正确的步骤，SOA 就是解决问题的一个好方法。
对我们来说，我们已知云计算可以通过因特网提供IT 资源。这些资源通常以订购的方式获得，并且可以根据需求进行扩增或收缩。资源包括存储服务、数据库服务、信息服务、测试服务、安全服务以及平台服务——当今的数据中心中能找到的功能几乎都可以通过服务的方式从因特网上获得。
你是否对这种景象感觉似曾相似，没错。云计算所基于的模型就是多年前人们使用的分时模型，那时候人们买不起个人计算机。这个理念是在很多公司以及个人之间分享计算能力，以降低使用者的成本。在当时这是一个相当简单的理念。分时的价值与云计算的核心价值几乎一致，只不过今天的资源比过去更好，更经济。另外，今天你可以将资源进行混合或搭配从而形成新的解决方案，而这在传统的分时模型中是做不到的。
对于云计算，你无需畏惧。事实上，若资源不需要维护，也是件值得高兴的事情。再者，分时模型已经存在多年，而我们只是为它取个新名字：云计算。当然，我们还增加了新功能，下面即将展开。
学习如何利用云计算——在人们熟知的架构方法（如SOA）的环境中——是让企业利用更高效、更有效的IT 基础设施的一个途径。然而，云计算并不是只要用在系统中就能得到最佳结果的灵丹妙药。你必须正确地规划对云计算资源的使用。实际上，这正是本书要讨论的话题。
1.5 定义云计算
虽然云计算的定义非常广泛，然而，就本书而言，我们却需要一个标准的定义。美国国家标准与技术研究所（NIST）的信息技术实验室给出了迄今为止最为全面的云计算的定义。
云计算使用按用量付费的模型，它实现了通过网络访问的、可配置的计算资源池（如网络、服务器、存储、应用和服务等）的可达性、便捷性和随需应变性，使得仅需最少量的管理工作或与服务提供商的沟通就能快速获得和释放资源。此云模型促进了可用性并且具有5大主要特征。
随需应变的自助服务。消费者可以根据需求单方面地获得计算能力，如服务器时间和网络存储，而不需要与每个服务提供商进行人际交互。
无处不在的网络访问。功能存在于网络中并且通过标准的机制进行访问，这促进了功能在异构的瘦客户端或者胖客户端平台中（如手机、笔记本和PDA）的使用。
位置无关的资源池。提供商的计算资源放在资源池中，使用多租户模型向所有消费者提供服务，根据消费者的需求对不同的物理资源和虚拟资源进行动态分配或重分配。客户端通常并不了解分配到的资源的具体位置，也无力控制资源的分配。这些资源包括存储、处理能力、内存、网络带宽和虚拟机。
快速而灵活。能够快速且弹性地提供功能以实现扩展，并且可以快速释放资源来实现收缩。对于消费者而言，可用于租用的资源似乎是无限的，并且可以在任何时间进行任意数量的购买。
按使用付费。功能的收费使用按用量计算的有偿服务或使用基于广告的收费模型来提升资源使用率。比如，度量存储、带宽和计算资源以及按月根据活动的用户数量收费。企业的内部云可能会增加部门间的成本，他们可能使用物理货币，也可能不用。
注意，云计算能通过面向服务的方式并主要通过无状态、松耦合、模块化和语义互操作性①，充分利用云范式的优势。然而，并非所有的云计算方法都是一样的，同样也有几种部署模型，虽然不同，但它们仍然被看做是云计算。
私有云。云基础设施由某个企业独自拥有与租借，而且仅为该企业运行。
社区云。云基础设施由多个企业共享并支撑特定的共同利益（如使命、安全需求、策略和合规考虑）的社区。
公共云。云基础设施由某个向公众或大型集团销售云服务的企业所拥有。
混合云。云基础设施有两个或多个云（私有云、社区云或公共云）构成，它们各自独立但又通过标准或私有的技术绑定在一起，以支持数据和应用的移植性（如“云爆发”）。
每个云部署模型的实例都是两种类型中的一种：内部云或外部云。内部云位于企业的网络安全边界之内，而外部云则位于此边界之外。就本书而言，我们主要讨论公共云计算，或使用公共云提供商来托管SOA。很多企业将来可能发现私有云对他们的环境更有利，所以在防火墙内利用云计算的优势。或者，某些企业会选择混合使用公共云和私有云或使用混合云。最后，有些企业还可能创建半私有云或社区云，这是一种只限于封闭的企业组或政府机构之内的公共云。
所有这些都是云计算，而且所有这些架构选择都可使用。本书中强调的步骤适用于私有云、社区云、混合云①以及公共云。我们在第12 章中将详细介绍私有云。
1.6 云计算的组件
伴随着云计算的出现，许多关于如何将它描述成一种计算模型的讨论也涌现出来。成熟度模型已经发布而且被人们热议，而且云提供商都有其产品的模型。
为了更好地描述云计算，我们提出了“服务栈”，它在逻辑上考虑了云计算的每个组件以及它们之间的交互。虽然该模型很复杂，但是这里没有必要描述得那么复杂。该栈是用于定义和提炼云计算概念的模型（如图1-2 所示）。
虽然很多业界人士对这些组件持不同意见，但云计算技术主要有11 大类或模式。
(1) 存储即服务（Storage-as-a-service）
(2) 数据库即服务（Database-as-a-service）
(3) 信息即服务（Information-as-a-service)
(4) 流程即服务（Process-as-a-service）
(5) 应用即服务（Application-as-a-service）
(6) 平台即服务（Platform-as-a-service）
(7) 集成即服务（Integration-as-a-service）
(8) 安全即服务（Security-as-a-service）
(9) 管理/治理即服务（Management/governance-as-a-service）
(10) 测试即服务（Testing-as-a-service)
(11) 基础设施即服务（Infrastructure-as-a-service）
我们将在第3 章中详细介绍这些内容，但是这里有必要从宏观上定义一下它们。
存储即服务（也称为随需应变的磁盘存储），也许你已猜到，是一种将物理上处在远程网站中的存储资源在逻辑上当做本地存储资源一样，供任何需要存储资源的应用程序使用的能力。这是云计算中最基础的组件，是能为其他大多数云计算组件提供服务的一个组件或模式。
数据库即服务（DaaS）提供了使用远程托管的数据库的服务的能力，为多个用户共享此数据库并且在逻辑上像使用本地数据库一样使用该数据库。不同的提供商使用的模型不尽相同，但其作用都是使用通常要耗费数千美元的硬件软件许可才能架设起来的数据库技术。
信息即服务是通过一种定义良好的接口（如API）对远程托管的任何类型的信息进行消费的能力。信息即服务的例子有股价信息、地址校验及信用报告。
流程即服务是将很多资源（如服务和数据，它们可能同在此云计算资源之内，也可能是远程资源）捆绑在一起创建业务流程的远程资源。你可以把业务流程想象成一个元应用，它跨多个系统，将关键服务与信息串连起来形成某种流程。这些流程通常比应用更容易变更，所以为使用这种按需交付的流程引擎的用户带来了灵活性。
应用即服务（AaaS），也称为软件即服务（SaaS），它是通过网络平台为终端交付的任何应用。终端用户通常用浏览器来使用这些应用。虽然很多人将应用即服务与Salesforce SFA 这样的企业应用关联起来，但是办公自动化应用程序事实上也是应用即服务，如Google 文档、Google 邮箱和Google 日历等。
平台即服务是一个完整的平台。它包含应用开发、接口开发、数据库开发、存储和测试等，并通过远程托管的平台交付给订购者。基于传统的分时模型，现在许多平台即服务的提供商可以创建企业级应用，这些应用或本地使用，或以少量的订购费供用户按需购买，或供用户免费使用。集成即服务是在云平台中交付完整的整合栈（包括应用抽象接口、语义仲裁、流控制与整合设计等）的能力。从本质上说，集成即服务包括了传统企业应用集成（EAI）技术中的大部分特性和功能，不同的是它以服务的形式交付。
管理/治理即服务（MaaS 与GaaS）是任何提供了管理一个或多个云服务的能力的服务。它们一般是普通的服务，如拓扑结构、资源利用、虚拟化以及正常运行管理等。治理系统也开始出现了，它提供了治理的能力，如执行数据及服务的策略。
测试即服务（TaaS）是使用远程托管的测试工具和服务对本地或云平台中交付的系统进行测试的能力。应该指出的是，虽然云服务本身需要测试，但是测试即服务具有测试其他云应用、网站以及内部企业系统的能力，并且它们不需要在企业内部部署硬件和软件。
基础设施即服务（IaaS）事实上是数据中心即服务，或远程访问云计算资源的能力。从根本上说，你租用一台物理的服务器（在上面你可以做任何你想做的事情），它就是一个数据中心或数据中心的一部分。这种方法与更为主流的云计算之间的区别在于，你不是通过接口和可量化的服务使用资源，而是能访问整个机器及其之上的软件。简言之，它被包装得较少。
1.7 云计算与SOA 的梦幻组合
虽然你完全可以只使用云计算而不实施SOA，也可以只用SOA 而不用云计算，毕竟云计算的实际价值在于使用防火墙之外的别人的数据中心（SEDC，somebody else’s datacenter）中的服务、数据以及流程。但是，那些决定使用云却缺乏架构远见的人终会发现，云计算不会带来什么价值。相反，在考虑到风险与移植方面的成本时，它还可能会使你倒退几步。
未来几年中将形成若干云计算的成功的核心模式。那些在某种架构环境中使用云计算的人会获得成功，而那些仅仅把东西随意扔到云平台中的人则会面临失败。请记住，如果SOA与云计算结合并运用在一个需要这种解决方案的企业里，它将是一个令人信服的商业提案（如图1-3 所示）。
简而言之，你可以把云看做附加的运行环境。而它的优势在于不再需要向数据中心投入装满软件的服务器以及相应的维护人员。
企业IT 对云计算所持有的将信将疑的态度是可以理解的。如果我们能对云计算多一点点适应，云计算资源在实际上将比本地的设施提更好的服务。云计算带来的好处将继续为搬入（云）的过程提供缓冲作用，包括成本节约、高效以及对数以千计的动态Web 服务的访问。
云计算的回报也驱动了SOA 的回报。SOA 不仅仅是一个驱动重用与敏捷的机制，它还可以用来判别哪些服务应该存在于本地，而哪些则应从云平台中获得。好的SOA 会带来好的云计算战略，最终实现降低成本、增强敏捷性并使云计算比以往我们所见到的更加令人激动。
1.8 SOA 可从云计算中学到什么
1.8.1 服务设计
那些在云平台中部署服务的企业（如Amazon 和Force.com 等）在服务设计方面都表现不错。你的确需要付出努力才能把这讨厌的东西出租出去。很多SOA 项目都有一个倾向，或建立太粗粒度的服务，或建立太细粒度的服务，或者设计的服务太糟糕。在后面讨论使用云计算对SOA 进行服务设计和建模时，我们将详细探讨此话题。
事实上，只有服务是良好定义而且是良好设计的，它们才能在按需交付的过程中销售得好。所以那些要向云外提供服务的企业——主要是大型云计算提供商——必须要在服务设计上花大力气，包括服务的实用性和持续性。我们向需要在SOA 环境中创建服务的人们强烈推荐，不管你使用何种技术或标准，应该看看现有的可租用的服务，将它们视作如何设计、开发和部署服务的好榜样。
1.8.2 服务的可扩充性
云计算服务就是为安装可扩展的需求而设计的，而使用云服务的人这么做的目的是让他们能够在需要使用服务时能按需获得。在SOA 扩充服务往往是个痛苦又昂贵的过程。
实际上，在企业内设计与开发的服务往往没有按照可扩充性而设计。SOA 发展过程中的核心问题是很多IT 人员并不关注服务的扩充性而当他们意识到时为时已晚，难以解决了。云计算提供商必须要快速解决扩充问题。
1.9 云计算可从SOA 中学到什么
1.9.1 服务治理
目前尚无云计算相关的治理问题，同样也很少有相关的策略控制与实施。因此，很多企业并没有正确地转入云计算的世界。
虽然从未被很好地实施，但治理却是SOA 中不争的基本事实。为服务设置策略并管理服务变更是成功的关键因素之一。当将由云计算交付的服务编排到我们的应用及SOA 环境中时，由于随需应变的服务不断变化，我们会经常碰到服务中断。通常，SOA 通过其治理系统管理这些变更，但也许有些治理是随云计算服务诞生的。
1.9.2 由架构驱动
正确地实施SOA 意味着从架构到技术驱动它。而在云计算领域，随需应变的资源是一个起点。云计算与传统的系统一样，需要深思熟虑的架构，这很重要，因为你需要把架构延伸到防火墙之外。
使用云计算资源就是将架构延伸到企业之外，以便与云计算资源合并，所以要记住，架构并不会因为防火墙而终止，这一点很重要。正确地理解企业内的资源与云交付的资源都非常关键，如同了解如何在企业架构中正确配置这些资源以实现业务需求一样重要。
显然，SOA 与云计算是手拉手、肩并肩作战的。云计算只不过为你提供了可使用但不属于你的新平台及新资源。除此之外并无其他改变，你仍然要正确地实施SOA。然而，云计算通过提供随需扩展的SOA 加速了SOA 的采纳。SOA 与云计算可以互相学习，取长补短。本书将二者拉到了一起。
1.10 跨入云计算世界
虽然你买了本书，但是很显然我们并非一定要鼓动你进入云计算领域。我们的目的是引导你从正确的方向跨入云计算世界。在你开始将企业架构向云计算扩展之前，请记住几件事，并带着它们阅读本书。
首先，向云计算转变不会立竿见影。它通过循序渐进的方式转移你的IT 架构，并且要有目的地利用SOA 的方法以及云计算资源。那些希望快速且有策略地驱动IT 变更的人会在此找到很有价值的信息，但是我们依然强烈推荐你做适当的架构计划。因此，你应为此激动，但也要关注重点。
其次，在观察技术的同时也要观察企业中人和流程方面的问题。有些技术人员忽略了这点，虽然最后他们在通向新架构的过程中做得很好，但如果没有人接受或为之买单，那么，所有努力都是徒然。所有能成功完成系统架构改变的人都需要考虑人与文化的问题。
再次，一定要定义商业案例。我们坚信商业案例的效用，所以在第4 章中专门介绍该话题。IT 从业者需养成从业务到架构，再到技术的行为习惯。所有对现有系统的信息变更都应该有清晰的商业案例作支撑，并且IT 团队还应向所有股东和投资人推销该变更。如果变更最终不能带来任何价值，那么它肯定不能完成。
最后，不要被广告牵着鼻子走——至少不要太受其影响。在问题没有弄清楚之前，过早地陷入SOA 及云计算的相关技术和标准的争论之中是无用的。我们热衷于此，因为我们热爱技术。
1.11 立足于积极的颠覆性变化
驱动变化的目标是向更好的方向发展。很多企业都处于很不景气的状况，所以利用颠覆性的技术和方法来实施改变是很有意义的。这意味着重新思考、重新定义并展开颠覆性的改变。SOA 与云计算的使用与多年前的Web 运动相似。Web 的使用彻底改变了人们访问和查阅信息的方式，而云计算将改变我们看待IT 资源的方式。它对糟糕的IT 基础设施采取颠覆性的改变并使之得到改善。
在阅读本书时你要记住，向云计算的转型就是为了改善现状而使用有效的技术及方法进行变革。它要求采用这些技术和方法来调整你的心理和思维，而且这是转型之旅中最艰难的部分。
你们大多数会受到企业中保守派的阻力。尽管大部分驱动颠覆性变化的人喜欢把这些阻力看成障碍，但这却是一个检测你的想法并学习向人们解释这些想法的好机会。检测你的想法意味着要聆听那些反对变化的人的观点，并使用这些观点来检查你在评估哪些要变以及为何要变的过程中是否遗漏了一些方面。有时，当反对者并不完全消极时，你要珍视这种机会，它促使你审视你的方法，而且你还可能根据他们的反馈对你的方法做出相应修改。这样，你就会坚信你正在做的事情是正确的，并能在该过程中增长新的知识和见解。
作为老师，你有机会向人们解释你正在做的事情以及这么做的原因。那些在驱动颠覆性变化的过程中取得最大成功的人是那些对新方法和新技术持有坚定信念，并能为它做出清晰解释的人。
这种变化为你带来的好处是，如果你的企业成功地实现了向云计算和SOA 架构的转变，那么它将会更有效、更高效地满足多数（若非全部的话）商业需求，你的企业将拥有关键的竞争优势以提升市场占有率、创造更好的产品并完成企业的使命，你将拥有助你事半功倍的健康的企业IT 基础设施。
第２章 理解云计算
人们总说时间会改变一切，但事实上你得自己去改变他们。
——安迪·沃霍尔（1928—1987）
在第1 章中，我们讨论了企业架构中存在的问题。从本章开始，我们不再讨论这些问题了。因为这样做于事无补，除非我们告诉你如何通过颠覆性的方法与技术，尤其是云计算，解决这些问题，并且向你解释云计算如何作用以及它怎样与SOA 很好地合作。
从本章开始，我们会深入探讨一些核心话题，它们是解决架构中核心问题时要理解的，其中包括如何通过最佳实践、SOA 与云计算解决问题。
还需要考虑以下几个问题。
云计算并非IT 的救世主。它只不过是企业架构的一种部署方式，不过它可能更有效，更节约成本。从根本上说，它是一个工具，而不是生活方式。它并无魔力，甚至没有新东西，但如果能正确地使用，它就能提高效率。
云计算和SOA 是不同的概念，但是它们却互相联系。SOA 是架构模式，而云计算是架构的实例，或者说是一种架构的选择。SOA 更具整体性和战略性，它解决的是包括业务驱动力在内的整个企业架构的问题，而云计算则更加战术，它是一种解决问题的方式。它们互相联系，并且若要解决企业级的问题，很难取其一而舍其二。
云计算的概念要求企业做出一些反常的举动，比如将流程和信息部署到企业之外。当然，这里需要考虑一些问题，但是没有一种方法完全与云计算相悖，也没有一种方法完全与之相同，正解应处在这两个极端之间。
本书并不鼓吹云计算。请记住，本书的主旨是推荐一些好的架构实践并指导如何将SOA与云计算使用到最佳。你从本书中获得的是不偏不倚的观点，包括什么情况适合使用云计算，什么情况不宜使用云计算。云计算不是“IT 的终结者”，也不是“浪费时间”，它的价值在这两个极端之间。
在我这里，你永远不会听到这样的观点——你应该把你的核心信息系统部署到云计算平台之上，同时你也不会听到“你根本不需要了解云计算”这样的论点。实施云计算应是衡量之后的行为，它需要你在实施任何方法或技术之前了解自己的问题，从而为企业建设更好的IT 基础设施。
2.1 深入理解云计算
现在，云计算到底是什么？它看起来简单，但其定义却千差万别。在第1 章中，我们为云计算做了如下定义：
云计算是跨越因特网提供IT 资源的能力。这些资源通常以订购的方式获得并能根据需要扩增或缩减。它提供的服务包括存储服务、数据库服务、信息服务、测试服务、安全服务和平台服务——在当今的数据中心中能找到的任何服务都能在因特网上找到并以服务的方式交付。
从多方面来看，云计算关心的是如何把远程托管的底层硬件和软件抽象成云计算资源。所以，你关注的是服务，而永远不需要关心底层平台，包括维护、监控以及硬件及数据中心所需的成本等。简言之，云计算是：
你不拥有的事物；
无需你维护的事物，至少从基础设施的角度看是这样的；
你看不见的事物；
通过订购获得或免费获得的事物；
可以根据需要扩增；
可以根据需要缩减。
云计算的理念是使用非你所有、无需你维护的计算资源，并通过规模经济降低计算成本。分享云计算资源的企业越多，其成本就越低（如图2-1 所示）。
此外，你还可以使用更多包含了预制组件的云计算资源。这样，你就不必再一切从头开始。从云平台中，你可以找到很多这样那样的应用块。比起从头开始构建这些应用块，从云中拿来即用的做法会使你更加领先。
一个很好的应用场景示例是提供了信用校验信息的数据服务。你可以自己存管数据并通过传统技术创建接口。或者，你也可以从众多云服务提供商中挑选一个，通过Web API（如图2-2 所示）访问由其提供的信息，这种接口通常是Web 服务（信息即服务）。虽然该服务可能位于千里之外，但你却像使用本地服务一样使用它。如果处理恰当，对于使用该功能的用户来说，这一切都是透明的。
不同之处体现在运维成本以及市场化推进速度之上。在“自建且自有”的场景下，其成本有时候可能是在云平台中寻找相同功能或信息的几倍。而且，自建的方式通常需要花费更多的时间才能把这些鬼东西架设和运行起来。考虑到维护成本、人力成本以及服务可能并不是企业的核心业务等方面，使用云计算的方案变得更加有吸引力。然而，云计算的适用性却取决于企业特定的需求。如我们在第4 章中会看到的，若要明确它能带来的真正价值，你必须为每个问题域设计云计算的商业案例。
显然，并非每个系统都应放在云计算之中。若整体地考虑这些系统的目标以及核心需求，将它们放在云平台中的成本还可能会更高。所以，在使用云计算和SOA 时，你必须采取批判性的思维方法。确保将云计算作为架构的一部分，并且设计云计算的所有商业案例，考虑所有的可变性以及软件和硬件成本。在第4 章中，我们将详细探讨云计算的商业案例。
至此，你已经了解了云计算的价值。那么，怎样判断哪些东西应该放在云平台中，哪些又应该放在企业本地呢？就所有与云计算相关的事物而言，此决定取决于你的企业。不过，你可以通过一些步骤来明确你的需求。在后续章节中，我们将详细讨论这些步骤。
2.2 云计算有何新意
那些刚刚了解了云计算以及它能为企业带来价值的人通常会问的一个问题可能是：“云计算有何新意？”而那些已经深入理解云计算的人——往往是提供商和顾问们——实际上并无很好的答案，原因是，云计算背后的概念已经使用了几十年了。
云计算可以被看成“分时”或者在多用户间共享计算资源的能力。在早期的计算时代，许多公司实际上分享着处在远程数据中心里面的同一台计算机。该计算机能为每个用户和应用程序分配资源并进行管理，而用户能够申请更多的计算时间，也可能更少，并对他们使用分时服务的时间进行调整。
那么，现在云计算为企业IT 带来了哪些新东西呢？
首先，可以利用不同的云资源组件，进而将它们混搭成新的解决方案。你可以使用某个提供者提供的存储即服务，另一个提供者提供的数据库即服务，甚至从第三个提供者那里获得整个应用开发和部署的平台。这种根据要实现的解决方案的需要使用资源，并按照适当的用量使用资源的能力是现代云计算的一个明显的价值所在。
其次，带宽的商品化使得企业能够像使用本地资源一样使用云计算资源。因此，你可以使用云计算提供的存储和运行时资源，就像它们位于本地数据中心一样，这在几年前是很难实现的。
最后，现在有很多创新的云计算提供商。虽然云计算的架构和模型本身没什么新意，但是提供服务的云计算提供商却是新兴的，包括基础设施即服务的提供商（如Amazon 的EC2）以及平台即服务的提供商（如Google 的应用程序引擎）。随着云计算技术突飞猛进的发展，许多更加创新的云计算服务正不断地被创建且发布出来。
早期的分时模型与现代的云计算之间存在着明显的差别，但是在该领域摸爬滚打多年的人却能看到相似的模式。而我们向云计算发展的构思是把云计算当做另一种工具，它可能使企业架构变得更经济、更高效。
然而，与任何新技术的潮流一样，云计算不是用到任何地方都能见效的灵丹妙药。这里不存在我们之前没有解决过的问题，所以无需畏惧云计算，相反我们应该了解云计算以及其他架构方式的价值。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
SOA 与云的结合点
如果你要为企业带来真正的价值，那么就应该将SOA 延伸到防火墙之外的云计算平台之中。然而，这种想法并不为SOA 的实施者们普遍接受。总体上说，大部分人认为SOA应该限定在防火墙之内，而将SOA 扩展到基于因特网的资源则被视为禁忌。事实上，多数企业并没使用通过Web 交付的服务，如云服务。在多数情况下，阻碍企业采用这种新技术的力量更多的是恐惧，而不是它们可能存在的任何问题。我们在第12 章中将详细讨论云计算和SOA 实施的阻力。
云计算实际上是使用基于因特网资源的SOA，包括服务、应用程序、目录以及工具等，并在整体上接受把业务流程部署到企业防火墙之外的想法（如图2-3 所示）。它不是SOA或传统企业架构的替换，而是一种新的架构理念，在这里，核心共识是基于因特网的资源会带来更快的交付、更多的资源以及更低的成本。
云计算的总体理念是通过外包的基础设施为核心业务流程带来了另一地址，并且带来了按需访问的可重用的业务流程。与传统的企业架构相比，这些基于因特网的系统和架构在大多数情况下能提高开发速度、更好地访问预制资源以及带来更多价值。这些都可用于证明SOA 应用于网络平台时比应用在企业之内能带来更多的价值——更快捷、更方便，并能带来更多的投资回报。
“基于因特网的SOA”或向云提供商扩展SOA 正在被人们迅速接受。虽然架构师们仍然在为企业内的SOA 而努力着，但是大多数SOA的模式是存在于企业之外的Web 平台之上的。复合应用正在使用新兴的随需应变工具构建。这些应用需要信息、服务和API 等，并且在因特网上随需要交付。企业也在寻找将现有的企业数据向云计算公开的方法，所以用户管理和安全将仍然是核心问题。如果有更多的架构师阅读了本书，我们就能预见，在不久的将来，多数企业会将更多核心业务流程运行到防火墙之外。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
2.3 云的潜在价值
云计算将至少为你带来哪些价值? 从根本上说，这是分析在企业中使用云计算的投资回报的过程。不要忘记，并非任何系统的外部化都是有意义的，而且必须对实际的开销和收益进行客观计算。虽然在第4 章中将深入探讨云计算的商业案例，但是这里仍然先介绍一些基本概念。
第一步，确定特定应用或业务系统的“当前”状态，包括在运行、维护、设计、开发、测试及部署等方面的成本。从此状态开始，确定云计算资源的“目标”状态。
此外，你应该定位敏捷与扩充性的价值，或者信息系统快速响应业务需求变化的能力，以及通过扩增系统使之能支撑由业务增长带来的处理负载需求增长的能力。
最后，你还要考虑应用系统能否充分利用云计算平台提供的信息、服务和应用的优势，并避免一切从头开始。将所有这些信息记录下来并计算出投资回报，它可能是业务所期望的，也可能是他们不期望的。由此你就能做出是否应该继续前进的判断。
虽然大多数IT 从业者认为云计算的价值是被广泛认同的，但是它的实际价值却需要经过复杂的分析才能确定。实际上，需要考虑的维度有很多，包括移植的实际成本、应用程序的建设与适应性、安全问题、合规性问题以及对你无力掌控的其他企业的信任带来的风险等。再次声明，我们将在第4 章中详细探讨这些问题。
2.4 云计算的优缺点
很多人面对云计算时只是单方面地看到了它的成本。虽然你可以把本地解决方案和云计算解决方案的区别简单地看做是软硬件的“购买或是租用”的区别，但是，实际上云计算的优点与缺点却复杂得多，而且影响深远得多。
虽然从广告的宣传中你只会听到它的好处，但是，那些把云计算当做改进企业架构一剂良方的人们既需知晓此方的好处，也需清楚它将产生的副作用。这才是做出是否需要此方的正确判断的唯一途径。
2.4.1 优点
(1) 成本
(2) 网络
(3) 创新性
(4) 扩充性
(5) 实施速度
(6) 绿色
成本的含义是，在考虑硬件、软件以及维护系统所需人力成本的情况下，作为一种架构方案，云计算要比传统的数据中心更为经济。虽然它并非总能便宜，但至少从概念上讲，它是更加经济的。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
托管还是云
为了开发新系统，你必须支付开发成本，你还要考虑峰值负载，这会产生经常不被使用的能力过剩。这意味着花在硬件和软件上的投资在多数时间里未被利用。云服务却比较经济，因为你只需为所使用的那部分资源付费。如果你正在处理一个已有的系统，即作出是否要将此遗留系统包装成服务或云服务的决定，这种情况下使用云就不那么有说服力了，因为许多要使用的设施已经完成建设并已支付费用。在作出存管还是云的决定之前，你必须考虑所有这些因素。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
由于云提供商使用“现用现付费”或“按需付费”的模型，所以使用费相对比较合理，它通常基于时间、存储单元或云计算的其他计费方法。成本是云计算的核心价值之一，因为使用多少支付多少。
再者，当你使用的是测试版或0.0 版的资源时，节约的成本会更多。因为云作为一个服务并且由远程托管，云提供商会根据需要随时对资源进行更新、修改或者重新发布，并且不会干扰任何用户的使用。那些饱受软件更新折磨的人一定会认为这是一个极大的优势。然而，对更新和补丁缺乏控制也可能为云计算的用户带来高成本。如果补丁的更新不是在需要时进行的——有时却又是必要的——就可能会导致客户端瘫痪。更新可能造成云用户的损失，也可能带来意外的破坏，龙其是在旧服务停止提供服务时。
网络的含义是云计算处在因特网之中，因特网连接了许多能带来附加值的资源，如社交网络、电子商务API、映射API 以及其他云。所以，有了网络，你就可以通过对云计算服务进行混搭来为你要解决的业务问题提供更好的解决方案。通过结合使用一个云服务与其他云服务，从而形成比这些服务能力之和更加强大的自定义服务，这就是云计算的真正益处。
创新的含义是云计算以及它所提供的解决方案是全新的、当下的并且是创新的，而且它还将继续孕育着更多创新的特性，从而为你的投资带来更多价值。同时由于它广为人知的价值、热传以及业内人士的热情追逐，它更容易被人们采纳。那些采用云计算的企业，特别是那些刚起步的，将会发现使用云计算带来了IT 创新的价值，同时也为整个企业带来了价值。
扩充性在某种程度上与成本相关。它指的是只需增加费用，就能在需要时按照需求任意添加能力。另外，也可以方便地缩减能力。你不再需要准备一大堆硬件和软件并等待它们投入大生产环境之中，也不再为所需的资源花上几周甚至几个月的时间进行采购与安装。你可以在需要资源的任何时刻，通过单击鼠标就能得到你想要的资源。
实施速度与扩充性相关。它是云计算的一个优势，因为云计算的实施时间可能是几天，在某些情况下甚至是几个小时。你不需要购买硬件，安装操作系统或者获得使用数据中心一部分的授权。在多数情况下，你只需注册，然后就拥有了对云计算资源的访问权限。那些曾参与过硬件和软件采购、安装、测试、部署并与要与很多人打交道才能使应用运行起来的人，一定会感受到云计算的这个优势。
云计算是绿色的，因为云计算有益于环境。如果你担忧环境问题，那么听到云计算是最绿色的计算方法时一定很开心。共享计算资源并关闭非常耗能的数据中心能够减少电力的消耗。
虽然你可以用“绿色”来推销云计算，但是反对它的人却可能因为讨厌北极熊而期望温室效应的到来。绿色只能作为一种马后炮式的说法，而不能当做重要的价值主张。然而，当下的很多大企业都宣称自己是绿色的，而云计算为他们提供了实践承诺的途径。多数绿色企业仍然拥有大型的数据中心和数以千计的服务、主机、存储设备以及其他高碳设备。这些并不够绿色。
2.4.2 缺点
(1) 安全
(2) 控制
(3) 成本
(4) 开放性
(5) 合规性
(6) 服务级别协议
安全的含义是，因为云计算交付的基础设施不在你的直接掌控之中，你的信息在某些情况下可能被暴露在外。虽然云计算提供商支持加密、用户名和密码级别的安全，甚至基本的身份管理，现在你也不可能把国家机密放在云平台中。然而，由于多数企业信息并不包含国家机密，所以完全可以放在云平台中。此外，随着时间的推移，云计算也会越来越安全。并且，我们没有理由期望云计算平台中的信息与本地系统中的信息一样安全，或更加安全。这只不过是要考虑的一个问题而已。
控制意味着在你使用云计算资源时，你实际上是放弃了对那部分IT 基础设施的控制。一方面，对于“我喜欢拥抱我的服务器”的那群人来说是情感上的事情；另一方面，真正的问题是当你将文件、数据和流程运行在别人的基础设施之上时，你其实是受到另一公司的支配，这可能会给你带来一大堆问题。
可能你无意中违反了某个策略，随后你就会发现你的账户被关闭了。或者你的云服务提供商倒闭了并且关闭了你的服务。一个更现实的场景是云提供者被另一公司收购了，而该公司认为你所使用的服务不再为他们赢利，所以不再继续提供此服务，导致你不得不抓狂地寻找其他解决方案。所以，只要你依赖于你无法掌控的其他公司，总会存在类似的风险。在考虑云计算的商业案例时，你必须考虑这点。
成本这一缺点的含义是，虽然在前一部分中我们看到了明显的成本优势，但很多时候云计算并不能节约成本。有时，在云平台中运行应用程序的成本可能更高，特别是在考虑到移植的成本、应用所需的特殊功能以及本地平台也有可能更经济的情况时。成本既是优点也是缺点，所以对于特定的问题域，你总是要考虑成本并做足功课，分析云计算的投资回报（参考第4 章）。
开放性的缺点指的是许多云平台本身就是私有的。一旦你使用云提供者的语言和架构编写了应用系统，可能会发现若想移到其他云提供者或移回企业，成本非常高。虽然云提供者们正在紧锣密鼓地形成一套标准来降低昂贵的移植费用。在考虑云计算时，不管有无标准，资金安全总会面临一定的风险。
合规性的缺点指的是，对于那些必须执行审核和合规性检查的企业来说，云提供商不能提供它们所需的日志和审核的特性，这些特性与美国企业必须遵循的法律保持一致。发展趋势是云计算提供商将在这方面做得更好，所以在迈向云计算之前一定要考虑清楚你的问题以及云计算提供商在合规性方面的支持。
服务级别协议记录了云提供商和用户在服务、优先级、责任、保证金以及维修合约等反面达成的共识。许多云提供商不提供这些特性，但这种状况即将改变，原因是很多有更严格需求的大公司已经开始使用云计算。该趋势是要求云提供商提供服务级别协议，不过，他们一定会把由此增加的成本分摊到云计算平台的消费者身上。这是使用云计算时需要考虑的另一问题与成本。
2.5 何时适合使用云计算
现在，我们已经了解了云计算的优点与缺点，下面进一步讨论应用或系统是否适合使用云计算。不要忘了该决定需从对架构问题以及应用的设计模式的理解开始。我们将在第10章以及第11 章中详细探讨这些问题，但是在使用云计算定义SOA 之前，对何时适用云计算有所了解还是很重要的。
1. 云计算适合的场景
当流程、应用程序和数据非常独立时，或者当它们与其他应用程序或信息松耦合时。其主要思想是，如果它们之间紧耦合，那么即使可能，它们也很难解耦，所以不能独立地运行在远程平台之上。如果它们之间松耦合，适用性就不再是问题。松耦合的应用程序更容易用于云计算平台。
当有良好定义的集成点时，或者在应用程序内部很好地定义了能够共享数据、行为与流程的集成点时。这样远端的应用程序更容易与企业内的应用程序进行整合。
当较低级别的安全就已经够用时，或者当云计算环境中包含的信息要求的安全级别较低时，又或者信息丢失不会产生太大影响时。云计算系统已经提供了“足够好”的安全，但是正如我们在第1 章中所说的，它还没有安全到可以放进国家机密的级别。
当企业的内部核心架构是健康的，或者企业内部已井然有序时，这样更容易将云计算纳入到企业架构中。
当所期望的平台是Web 和因特网时，或者你愿意把用户接口部署在浏览器之内。现今，随着富因特网应用程序的出现，基于浏览器的应用看起来和用起来都像本地应用程序一样。
当成本成为问题时，或者当你发现使用云计算可以看到如前文所述的明显的成本优势时。如果你正在寻找便宜的平台并想在其上构建及部署你的应用程序，那么云计算往往就是你的方向。
当应用程序是新建的。将新建的应用程序部署到云计算平台比将旧的应用程序移植到云平台要容易得多。在前面，我们探讨了一些问题，它们围绕使用私有语言以及其他导致云计算迁移过程困难和昂贵的机制而展开。
2. 云计算不适合的场景
当流程、应用程序和数据紧耦合时。如果应用程序互相依赖，那么将任何一个移入远程云计算平台都不是个好主意。它们很快就会破坏。记住，松耦合适用于云计算，紧耦合不适合云计算。
当缺少定义良好的集成点时，或者缺乏在远程云平台提供商与企业内现有应用系统之间同步流程与信息的很好的机制时。为这类接口糟糕的系统进行整合为云计算转移带来了很大的风险，它不适用于云计算。
当需要较高的安全级别时，或者安全在你看来是一个很大的风险，因为你不信任那些你无法完全掌控的系统。这种系统应该不多见。
当你很看重控制时。如果你不愿意将关键组件外包给你不是100%信任的企业，那么云计算对你就不合适。
当企业的内部核心架构不完善时。如果你的企业架构功能失调，那么将其延伸到云平台不是个好主意。第一步是要把企业内部整理好，最少在将系统延伸到云平台时不会带来危害。
当应用程序需要本地接口时。如果你要使用本地API（如Win32）而且浏览器不在考虑之内时，那么云计算就是不合适的。
当成本是个问题时。再次，当全面考虑成本时。虽然在很多情况下云计算是适宜的，但有些情况下不适宜使用云计算。我们将在第4 章中深入讨论相关内容。
当应用是旧系统时。如同新应用更容易移植到云计算平台，旧应用则比较难。
2.6 做点与众不同的事
云计算不存在任何革命性的改变。它更像是一个发展的方法，将某些主要的计算平台转移到更优的云计算平台之中。简言之，我们仅仅将架构方法（特别是SOA）扩展到云计算平台。本书盘点了转向云计算过程中需要考虑的一些问题。更重要的是，书中提供了使用云计算定义SOA 的流程，遵循它你就能做出正确的决策。
云计算只是一种架构，而且一直是架构。它只不过为SOA 以及企业架构的实施者带来了更经济、更创新的架构选择。我们做架构的核心目标不会改变，其核心价值也不会改变。云计算关注的就是更高效并且更经济的新平台。