读书月福利
欢迎光临中图网 请 | 注册
> >
服务虚拟化-改善企业应用软件开发的速度.成本.性能和敏捷性

服务虚拟化-改善企业应用软件开发的速度.成本.性能和敏捷性

作者:米科尔森
出版社:机械工业出版社出版时间:2015-03-01
开本: 32开 页数: 126
中 图 价:¥21.9(7.3折) 定价  ¥30.0 登录后可看到会员价
暂时缺货 收藏
运费6元,满69元免运费
?快递不能达地区使用邮政小包,运费14元起
云南、广西、海南、新疆、青海、西藏六省,部分地区快递不可达
本类五星书更多>

服务虚拟化-改善企业应用软件开发的速度.成本.性能和敏捷性 版权信息

服务虚拟化-改善企业应用软件开发的速度.成本.性能和敏捷性 本书特色

《服务虚拟化:改善企业应用软件开发的速度、成本、性能和敏捷性》 服务虚拟化技术的先行者和资深技术专家亲自撰写,从服务虚拟化技术的基本概念、演变过程到高层架构和实际应用,提纲挈领地阐释服务虚拟化技术和*佳实践,引领读者深入理解服务虚拟化技术并将创新理念付诸实践,以新的思路来改善软件开发周期,提升企业竞争力。

服务虚拟化-改善企业应用软件开发的速度.成本.性能和敏捷性 内容简介

本书大致可分为4部分。**部分(第1~4章)阐释服务虚拟化的概念与演变发展过程、当前技术开发方法论所面临的问题和挑战,以及选择服务虚拟化技术作为解决方案的原因。第二部分(第5~7章)讲述服务虚拟化技术带来的好处,服务虚拟化如何应对软件开发生命周期中的限制,服务虚拟化技术实际效果,以及如何使用服务虚拟化。第三部分(第8~11章)重点阐述服务虚拟化的系列*佳实践,涉及交付更快捷、减少基础设施所占空间、改变性能和规模以及数据场景管理。第四部分(第12~15章)揭示虚拟化面临的风险和推行的公司环境,如何成功进行服务虚拟化,推动服务虚拟化,如何应对各种约束,服务虚拟化的评价。

服务虚拟化-改善企业应用软件开发的速度.成本.性能和敏捷性 目录

《服务虚拟化:改善企业应用软件开发的速度、成本、性能和敏捷性》大致可分为四部分。**部分(第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台不同的服务器。非常有意思的是,我们甚至没有测试这些服务,我们仅仅需要这些服务来测试高端依赖服务,然而它们却需要花费许多时间来安装和管理。 消除使用实际系统的需求,极大简化我们的流程。为了采用虚拟服务,我们必须证明虚拟服务比实际系统工作得要好以获得信任。首先我们要为绩效经理提供他的周期之外的一周时间,这好比送给他一袋金子。 但是在公司中任何思维方式的转变被接受都是非常困难的,尤其是当你面临的情况是“事情原本就是这样的”。因此,我们对于任何想要实行虚拟化服务和接口的人的建议就是:挑选一个最受制约的点,专注于此,将它做到最好—人们就会公开支持它。

商品评论(0条)
暂无评论……
书友推荐
编辑推荐
返回顶部
中图网
在线客服