重磅推荐
《服务虚拟化：改善企业应用软件开发的速度、成本、性能和敏捷性》大致可分为四部分。部分（第1~4章）阐释服务虚拟化的概念与演变发展过程、当前技术开发方法论所面临的问题和挑战，以及选择服务虚拟化技术作为解决方案的原因。第二部分（第5~7章）讲述服务虚拟化技术带来的好处，服务虚拟化如何应对软件开发生命周期中的限制，服务虚拟化技术实际效果，以及如何使用服务虚拟化。第三部分（第8~11章）重点阐述服务虚拟化的一系列*实践，涉及交付更快捷、减少基础设施所占空间、改变性能和规模以及数据场景管理。第四部分（第12~15章）揭示虚拟化面临的风险和推行的公司环境，涉及如何成功进行服务虚拟化，如何推动服务虚拟化采纳，如何应对各种约束，以及对服务虚拟化的评价。
【前言】
“生活本质上是令人讨厌的、野蛮和短暂的，但是在虚拟环境中却不是这样的。”
——虚拟托马斯·霍布斯
“好的开发者重用，伟大的开发者虚拟化。”
——虚拟巴勃罗·毕加索
“草莓虚拟开发环境。一切皆幻。没有什么值得牵挂。”
——虚拟约翰·列侬
“骗我一次，你羞耻。被你骗两次……不会被虚拟服务再次欺骗。”
——虚拟布什
【媒体评论】
【作者简介】
John Michelsen 资深技术专家、培训师、作者、演讲家，CA技术公司CTO和ITKO公司联合创始人。在数据库、分布式计算、虚拟/云管理、多通道网络应用门户、服务虚拟化（LISA）等领域拥有丰富的创新经验。目前主要负责帮助企业客户推动IT前沿转变以交付商业成果。
Jason English ITKO/CA技术公司营销副总裁，在营销、市场分析、软件构建、用户体验、游戏配乐方面拥有丰富经验。他之前曾担任i2技术监制和信息架构师，主要为HP、IBM、EDS、Delphi、TaylorMade、Sun、Realm、Adaptec、Motorola和Sprint等财富500强客户定义客户体验。
【免费在线读】
序幕
联邦快递FedEx的虚拟化
大多数企业想逃避的现实
15年前，联邦快递FedEx的一个团队必须完全确定，他们的交付物都可以通过一个有大约200个系统的软件架构实现。现在，他们必须结合在一起的活动件和服务的数量很容易就超出了几千个独立IT服务和系统的能力。这只是其中一个重要的组。每天来自全球几百万的终端客户和合作伙伴的交易进入联邦快递FedEx的系统。
下面就是联邦快递FedEx IT主管Russ Wheaton讲述的他们的历程。
为了及时响应用户的需求和期望，我们公司在15～18年前就测试了一个特定的软件栈。因为我们公司有些关键系统是在20世纪80年代构建的，初的目标是证明软件的功能对于公司来说是“影响收入”或者“面向客户”的。随着时间的推移，系统实现越来越接近公司的期望，属于这种类型的系统的数量、类型和规模都增长很快。
我们正在面临的挑战是：随着我们持续地为客户推出和引入更高程度的灵活性与服务水平，越来越多的核心系统在客户和收入影响的方面发挥着作用。随着系统互联数量的增长，“商业交易”的复杂度也极大地增加了。结合公司快速增长的战略以实现不断增长快递业务，这就产生了一个庞大的解决方案，即我们如何专注于端到端的核心流程的认证，而不用经常增加资源或预算来实现新的功能。我们必须改变我们的战略。
与此同时，一种称为SOA（面向服务架构）的新技术正在崛起，SOA定义了一系列针对分散的、可互操作的服务架构的原则和方法，以达到简化问题的目的。这种技术非常好，因为它使我们能够重用和快速开发通用的企业服务，使我们能在更高的管理层面设计、部署和解耦合，更好地消除许多所谓“大系统”的依赖关系和失败重来的战略。
但是SOA也为大型系统认证过程带来了一个缺点。当你已经有了很多组或者已经存在互相依赖的系统时，这些依赖会对进度产生影响。如果在认证过程中的某个时段需要的服务排列得不合适，或者没有准备好，或者在端对端的测试中同时进行，SOA就不起作用了。在保持进度的同时将所有部分组织在一起就是一项极具挑战的工作。
大约在7年前，我们在开发过程中引入了接口标准化作为核心架构原则。我们决定在传输和编码中使用接口标准化技术。良好定义的接口（甚至在某些情况下自定义的接口）产生了许多好的效果，它有助于在复杂多样的异构环境中极大地提高软件的设计和交付能力。我们也希望我们在为未来的问题进行投资，有一天，所有这些将为我们非常复杂的应用提供更加标准和可重复的认证过程。理想情况下，我们可以利用“仿真”技术（其他行业已经使用仿真器几十年了）。在这种技术中，我们能够模拟良好定义的接口，在功能和性能测试中模拟它们，从开发进度的角度看，相互依赖的开发组可以独立工作，只要他们之间的接口或“约定”是定义良好的和标准化的。
这对保证进度非常重要，我们也非常重视可靠性。我们如何独立地证明这些系统作为基线并使用科学的方法，即使一段代码改变了，我们也能以自动化的方式确定我们期望的结果会发生？其实就是我们如何利用这种技术来开发新技术以潜在地提高代码和单元测试之类的开发生命周期的质量？
对于我们这样规模的公司，部署解决方案用以证明我们的收入影响或面向顾客的应用，在后端必须是技术不可知的。我们继续与架构师社区合作，利用标准化的技术如SOAP、REST、EJB和集成技术，而不管他们说的是后端框架、内部分布式服务、云，还是外部服务。所有核心企业接口使用一致的技术和编码，对我们来说这就是天堂般的理想。
20年前业务都很简单。企业和IT被巨大的鸿沟隔离。IT能够用于诸如会计之类的业务，但是几乎没有企业的生产力是由IT驱动的。但是互联网开始消除这种差别，现在企业的战略都是紧密依赖于IT解决方案和IT能力战略的。
为了寻找更好的企业解决方案，这给我们的IT系统增加了很多压力。我们需要IT来驱动新功能，对新服务产生更快的响应，使业务更加便捷。我们必须更快地验证以便更快上市。随着IT进化，客户期望也在增加，客户对系统失败的容忍度在降低。随着时间推移，有时候，它会从刺激客户进化到改变客户的商业模式。
我们必须不断提高自己。如果我们的系统不够快、不安全和不准确，客户就会去其他地方做生意。
多年前，当John Michelsen在我们办公室的时候，我给他提供了一个情境：快速增长的业务复杂性，开发新特性的需求，及时，次正确，次次正确—因为没有人能获得额外的时间、资金或者资源来实现它。我们想改变规则以提高单位时间的生产率和我们需要满足的人的要求。同时，在我们的职业生涯中，保持一种合乎情理的有益的工作生活的平衡。这迫使我们重新思考我们的环境。
当今，一切都在虚拟化，这给了我们相对其他事物更高程度的重复性和可预测性。我们有虚拟服务器；一年前，业界就开始应用这些技术了。通过面向服务的架构（SOA），在当今企业的计算环境中，商业化的服务和数据变得很普通。随着服务虚拟技术的引入，服务虚拟就是我们内部所谓的“接口仿真”技术，现在我们能够支持数百个接口和虚拟后端而不需要依赖复杂的外围系统（相对于测试的系统来说）。我们团队就有这样一个例子，我们模拟25个后端服务，这些服务表示传统意义上我们在某地拥有的大约200台不同的服务器。非常有意思的是，我们甚至没有测试这些服务，我们仅仅需要这些服务来测试高端依赖服务，然而它们却需要花费许多时间来安装和管理。
消除使用实际系统的需求，极大简化我们的流程。为了采用虚拟服务，我们必须证明虚拟服务比实际系统工作得要好以获得信任。首先我们要为绩效经理提供他的周期之外的一周时间，这好比送给他一袋金子。
但是在公司中任何思维方式的转变被接受都是非常困难的，尤其是当你面临的情况是“事情原本就是这样的”。因此，我们对于任何想要实行虚拟化服务和接口的人的建议就是：挑选一个受制约的点，专注于此，将它做到好—人们就会公开支持它。
……
【目录】
译者序
作者简介
技术审核者简介
致谢
序幕 联邦快递FedEx的虚拟化
第1章 引言
1.1 定义服务虚拟化
1.2 你可以实现这种转变
1.3 关于本书
第2章 商业规则：创新或死亡
2.1 客户毫不心慈手软
2.2 业务需要敏捷软件交付
2.3 增加的变化和复杂性是不可避免的
2.4 没有模拟商业软件不可持续
第3章 我们如何走到这一步
3.1 从单一应用到复合应用
3.2 当前复杂的服务环境
3.3 从瀑布开发到敏捷开发
第4章 约束：敏捷之敌
4.1 范围内与范围外
4.2 不可用的系统和有限的容量
4.3 冲突的交付时间表
4.4 数据管理和变动
4.5 第三方成本和控制
4.6 存根和模拟远远不够
第5章 服务虚拟化是什么
5.1 虚拟化的另一半
5.2 创建虚拟服务
5.3 创建和维护虚拟服务的选择
5.4 什么可以作为虚拟服务
5.5 对开发和测试，虚拟环境比真实环境好
5.6 稍等一下—虚拟服务环境能替代实时环境一直到生产阶段吗
第6章 服务虚拟化技术的能力
6.1 “类实时”的开发环境
6.2 自动化消除手工存根和维护
6.3 虚拟服务，治愈自己
6.4 开发和测试并行
第7章 从哪里开始服务虚拟化
7.1 IT管理者必须管理和鼓励服务虚拟化，否则这种情况将不会发生
7.2 识别利益相关方（服务虚拟化战争委员会）
7.3 谁应该首先使用服务虚拟化
7.4 设置发布的真正价值目标
7.5 避免不适当的技术
休息时间
思考练习
第8章 实践1：交付更快速
8.1 通过虚拟私有化减少等待时间
8.2 现在就终止存根，或者以后偿还
8.3 Sprint：将向左移付诸实践
第9章 实践2：减少你的基础设施所占空间
9.1 找到过度利用的资源
9.2 主机开发也需要虚拟化
9.3 避免巨大的IT花费
9.4 客户案例：躲避波浪
第10章 实践3：改变性能和规模
10.1 虚拟化性能环境：你在等待失败吗
10.2 组件级性能预算
10.3 从生产了解性能
10.4 设置阈值，把性能向超过我们想象的更左侧移动
10.5 设计性能测试
第11章 实践4：数据场景管理
11.1 vTDM：就是你需要的数据
11.2 消除数据冲突
11.3 数据屏蔽：可信但虚拟化
11.4 期望的结果
第12章 虚拟化
12.1 服务虚拟化的利害关系是巨大的，所以不要停下来
12.2 软件开发生命周期过程（SDLC）的改变
12.3 在虚拟IT环境中构建新技术和角色
12.4 好的帮助几乎总是需要的
12.5 我们应该集中或联合
12.6 另一种酷的使用方式：虚拟培训环境
第13章 服务虚拟化和开发测试云
13.1 云开发和测试的约束
13.2 实现高性能云环境
13.3 云中的大规模并行回归测试
第14章 评估价值
14.1 更快：上市时间的价值
14.2 度量结果：更快
14.3 间接价值：运行更快
14.4 更好：质量价值
14.5 结果：更好的质量
14.6 间接价值：更好
14.7 更便宜：节约成本的价值
14.8 结果：更便宜（低成本）
14.9 间接价值：更便宜
14.10 组织路线图：规划持续改进
第15章 结论
15.1 工业化的软件供应链
15.2 在经济繁荣时期和困难时期的创新与发展
15.3 准备重温你的企业发布战略
后记
术语表
