对于服务和技术上的新发明及重大改进,人们一般首先着眼于自身的领域(尤其是以迎合市场为第一要务的软件厂商)。云计算也不例外。例如,IBM提出了Rainmaker技术来帮助企业创建云,Rainmaker技术为此定义了软件和硬件的协同工作。然而,软硬件的协同工作却是用一种非常专有的方式实现的,这正是隐藏在细节中的魔鬼。
现在,我们不再承受得起让市场来为我们(也就是最终用户)做决定。就像此次金融危机的情况一样,缺乏监管往往会导致巨大的灾难。如果我们对于云计算采取同样的放任态度,那么就会丧失掉业务上可能得到的关键利益。谨以本文分享我的一些想法:敏捷和新的市场规则如何深入地改变了我们“消费”IT的方式。
我呼吁创建面向用户并且独立的云社区。这个社区将会集中人才并支持他们从用户的角度来清晰地定义关于云应该是什么的需求,而且还会支持当前的开源云项目之间的协作。我们需要尽我们所能来避免云计算中新的事实上的巨头垄断(不能让几家公司组成的小圈子掌管云世界(或者它们发明的什么新词),Amazon、SaleForce.com、Google、Microsoft、IBM、HP都不行)。我们已经有了SOA的教训。
业务要敏捷才能生存,它需要“开放的、易于部署和互操作”的IT解决方案。在大多数公司中,如果一个人不在IT部门内部工作的话,那么他就不会关心信息技术,而敏捷的业务技术则会长久存在。典型的产品管理团队总是在寻找在完美时机具有完美成本的完美技术,用来在完美的时间内以完美的价格将完美的产品发布到完美的渠道中。“完美”是个业务术语,把它换成IT语汇就是“敏捷”、“快速”和“成本效率高”。让我们直面现实,我们都知道软件即服务(SaaS)被用在核心业务系统中( Line Of Business,LOB),从而减少内部的IT资源和IT成本。除了控制成本,各LOB还想通过“按需”选择和配置所需工具,将业务的兴败也控制在自己手里。业务技术,即可自定义的业务过程及其在云中的实现,应运而生。
敏捷的普及性会影响IT过程和组织,影响IT开发和测试工具和技术,并且最终会影响IT运营和架构。在下面的小节中我们会展示一些例子,从而概述一下有多少种不同的力量集中在“云计算”这一点上。
我们公司在两年前发现了敏捷这个词,从此我们就再没有以原有的方式构建过软件。像Scrum、XP这些方法,以及精益管理都提高了产品的质量,并且缩短了将产品推向市场的时间。当我们具备了真正想要成功的意愿,并且应用了它们的时候,那些过程框架就会使组织功能障碍浮现出来,并且提供了重要的结果。
我们总是需要对过程框架进行自定义,并使其与特定的环境相适应,但同时总是要遵循一些关键的原则。一般需要提到的原则有:团队成员之间的沟通和信任、IT团队中的业务(产品所有者)整合,经常在有规律的和及时定义的间隔中(sprints)发布和部署软件,以及持续地寻找各种浪费并找到节省资源的方法。
让我们来回顾一下IT开发和测试技术当前的进展,它们可以被认为是敏捷的催化剂:
给数据中心购买一台新服务器,并且安装完毕通常需要三个月的工作。在此我还没有提到安装DBMS簇集或者设置VLAN。在同一台服务器上安装多个应用程序会导致某些副作用(需要使用的软件的版本、配置冲突),更不用说部门组织之间的冲突了。
IT运维中的敏捷产生于新一代的数据中心,绿色IT的要求(降温和电力)、虚拟化技术(提高硬件上运行的虚拟机的密度)、以及共享的基础设施(负载平衡、存储、防火墙、安全设备等等)。
将敏捷原则的适用范围扩大到IT运维也造就了“敏捷运维”(这种实践可称为“持续部署”)。
让我们看一下基础设施领域的现状变化得多么迅速,如今它已经被作为服务来提供了(Infrastructure as a Service):
想要得到关于云革命更多的信息,你可以阅读CSC Leading Edge Forum (LEF)上新近关于这个主题的报告 。
在云中,部署和运维都可以更敏捷,并且更好地在统一的流程中贯穿起来。但是不是意味着我们任意创建一个应用程序,就能将其部署到Windows Azure或者Google Application Engine上呢?我们还需要关心应用程序的代码将被部署到什么地方,以及它需要多少个CPU来支持负载吗?我们还需不需要操心应用程序的“XX性”,为此耗费大量时间,冒着出错的风险,额外增加不必要的代码?应用程序的业务和技术事件是否都经过良好地设计安排,以满足必要的弹性需求?我想你已经知道了答案。这个答案也解释了为何LOB们没有一拥而上大规模地采用云。
那么什么是采纳云的主要阻碍呢?
这些阻碍都对主要的参与者提出了要求,首先他们要定义自己的服务,即便需要专利接口或者技术。他们的目标是要尽快争取到市场份额,并推广他们的标准。作为用户,这对于我的核心业务系统意味着什么呢?厂商闭锁的风险当前对于证明这样的行动太重要了,特别是因为它没有被有吸引力的成本模型所支持。除了TIBCO,他还不清楚如何为Silver定价,大多数其他的厂商也都遵循了相同的方法(定价也几乎一样)。
为了加入更多的竞争,并且让新的革新的和独立的参与者不断出现,我们必须:
现在,让我们不要限制业务敏捷性的将来,这需要经过云专利解决方案所形成的孤岛时期,使其相互连接来支持最大可能的优势(像对于航线,其中今天某些航线被取消来达到目标),而并不是为了支持最好的可能的网(像现在对于Internet的情况)。革新也是通过黑客因素达到的(取得、理解、提升、发明……)
一些独立的相关人员需要敏捷的业务过程,他们正在改变业务和IT小组合作和交付的方式。现存的信息系统过于复杂,以至于几乎不可能让它们根据业务命令做出反应。现在是吃掉这个大象[2] 的时候了,每次一口。信息技术不再是通往成功的康庄大道。IT应该注入到业务中,从而创建业务技术。我们可以创建平滑的变更管理和让组织的发展适应敏捷的世界,这只需要遵循一些关键原则,其中最重要的如下所列:(这也创造了SHINE原则)
最近我听说了关于Lokad 的事儿,这是一家“闪亮”的德国小公司。Lokad正在交付业务技术,专门从事对销售的软件、需求以及通话量的预测。有了云,他们可以在一个小时之内对一个主要的德国零售商完成预测的计算(业务SLA是由客户所影响的),而不用花费几个小时,并且成本也很低。Lokad 在Azure上做了投资,即便那时Azure还处于Beta阶段,并且真正使用微软的网络和worker服务定义 重新构建了他们的应用程序。他们可以提供所需要的尽可能多的资源(但并非总像他们那样强大,10个单CPU的虚拟机,每台带有2GB的内存与一台带有20GB内存的10CPU的机器是不一样的),来做一些之前不可能的事情(由于计算时间的原因),现在甚至还支持创建和实现更加复杂的算法来提供更好的预测(由于计算时间不再是问题,而且软件的架构也不再一样)。
像IBM等公司也在着力于创建新的“闪亮”的业务技术服务。大规模混合(M2) 是对混合模型的扩展,它“集成了上G、上T甚至上P的非结构化数据,这些数据来自于基于网络的存储库,释放并丰富使用你选择的非结构化信息关机架构的数据(LanguageWare,OpenCalais等等),让你在特定的、用户定义的上下文中(像ManyEyes )探索并虚拟化这些数据。IBM还开发了改进的敏捷过程,来帮助客户们使用M2。首先它通过两到三小时的简介来识别需求,并且看怎样才能最好地使用M2。然后,使用一天半的时间来设置基础服务,并花费两到四天的时间来完成实现。
核心业务系统传达的第一个需求是对业务技术全面的印象。你怎样才能够让不同的利益相关者接触并理解公司的敏捷的和有弹性的资产呢?接受这样的观点,当前还要应付关于云的标准的战争以及互操作性的缺乏,我们能做什么呢?
我们主张应该发明一种新型的分布式操作系统,用来支持“即时的”IT。然后它会让你向云发出指定并对其加以控制(不仅仅是一台机器)。这种云操作系统会能够在云中管理的任何实体上完成操作(像创建服务器、添加数据库、转移数据、部署应用程序等等)。我们预想下面的关键实体需要由这个操作系统来管理:
让我们用简单的例子来说明我们能够预想作为Scrum用户故事的控制的级别。在公司中将会开始包括两个应用程序的新项目(一个是基于前提的,一个是基于需求的)。我们需要运行这个项目,并使其在公司的云上成为现实。对于这项工作,如果能够使用命令行的解释器会非常棒。因此,第一个目标是要使用一组命令,并且在云操作系统上拥有专有的云适配器,用来在正确的API中解释命令(就像我们回到了EAI的时代……)。为了管理业务技术,并且提供整体的印象,我们需要采集关于应用程序组合、将要部署的应用程序代码、应用程序配置以及非功能性需求和将要使用的有弹性的基础的信息。所有这些都在一个地方被管理和整合,即云操作系统(也被3tera 叫做元操作系统)。
为了在伪代码中构建我的小例子,我试着重用了在云提供商的API中已经提供了的命令,以添加管理组合资产和添加企业架构所需要的属性所需要的数据。这里需要找到跨多个域的最一般的共同特性:
CREATE DOMAIN myPortfolio ; my logical domain name composed of two applications
ADD myPortfolio APP1 Critical OnPremise ; APP1 is a critical application - app. portfolio
ADD myPortfolio APP2 Maintain OnDemand ; APP2 is in maintenance mode - app. portfolio
; Let's Begin with APP1
APP1 CREATE ; Definition of my APP1
APP1 IMPLEMENTS CustomerOnBoarding ; Link APP1 with Business Process
APP1 STATUS = Production ; APP1 is in production mode (portfolio)
; Automated cloud based deployment
APP1 SVN https://mycompany.com/svn/myPortfolio/app1.xml
APP1 REQUIRES JVM 8.x ; (we are dreaming ..)
APP1 SCALABILITY HORIZONTAL DYNAMIC ; Elasticity, create CPU when needed
APP1 PREFERRED AWS, RIGHTSCALE ; Elasticity, Preferred Cloud suppliers
APP1 RULE "COST < $200 PER DAY" ; Elasticity, Rule for elastic cost containment
APP1 SLA = 99.9 ; Elasticity, Rule for elastic cost containment
; Automated cloud based DBMS creation and data load
APP1 DATA SCHEMA https://mycompany.com/config/myPortfolio/Data/DataSchema.xml
APP1 DATA LOAD https://mycompany.com/config/myPortfolio/Data/DataDump.dat
APP1 DATA COMPUTE GRID MAPREDUCE https://mycompany.com/config/myPortfolio/Data/grid/MapReduce.cfg
APP1 STORAGE EXTEND ON DEMAND ; Elastic Storage
APP1 STORAGE DR ENABLED ; Storage with Disaster recovery
; Security information
APP1 SECURITY SSO
APP1 SECURITY OPENId
APP1 INTERFACE WITH APP2 USING HTTPS
; Service call
APP1 USE APP2 ; dependency management at architecture level
APP1 USE Service1 https://mycompany.com/config/myPortfolio/service1.wsdl
APP1 USE Service2 https://mycompany.com/config/myPortfolio/service2.wsdl
; Monitoring
APP1 MONITOR on MonitTweeter #APP1 ; monitoring is done through a Twitter-like interface
APP1 END
; Then
APP2 ATTACH APP2 https://www.app2.com/ ; APP2 is in on Demand 0
APP2 IMPLEMENTS CustomerProfile ; Link APP2 with Business Process
APP2 NEED OpenID ; APP2 is using OpenID
APP2 Certificate https://mycompany.com/certificate/app2.key ; Requires certificate
APP2 END
END Domain MyDomain
业务技术革命驱动的虚拟化是整体上的(服务器、存储和网络)。云需要并行和分布式的操作系统能力,这将会迫使我们忘记本地的操作系统为中心的样子(微软的Windows 7可能会是他最后一个操作系统)。我们还应该对于大量已经可用的关于分布式监控、配置和架构的动态映射进行重用。
显然,我们会提议创建特定的轻量级的类似于Linux的微内核,它是为云所优化的。它应该可以自如地运行在多种类型的处理器上,并且能够运行当前市场上大多数的虚拟机上(或者至少能够通过网络与他们交互)。每个微内核都将会运行在一个处理器或者CPU核心上。中心的系统会收集数据并且对其进行动态关联,以使分布式系统适应当前的状态(在分布式的系统中收集全局的状态具有很重要的价值),并且在需要的时候发出远程的命令(在steroids上分布OSGi)
最基本的方法已经开始在世界范围内实行,以解决这些关键的问题。其中最有前途的有:
云将会迫使企业架构拥有对弹性系统的整体上以及尽可能动态的认识。之前的方法中,我们使用专门的工具(像Aris 、Mega 、Casewise )静态地载入IT的横向数据,这些方法将不再可用。企业架构、应用程序的组合以及架构的管理的整合,是保持对域状态有全局的认识并且看到它在业务价值链上的影响的绝对需求。
运行在自治的架构上的弹性应用程序将会对旧的设计、部署、测试、写文档以及维护IT系统的方式提出挑战。尽管如此,我们需要创建钩子来让我们的IT足够敏捷,从而对新的业务决策做出快速的反应(在向云或者它的继任者做大的跨越之前)。
业务过程的描述、整合和优化在将来会越来越重要,它会在LOB的组织中创造新的工作机会。相反,技术架构师、构架专家以及计划和资产经理的工作会越来越难以区分。
我希望通过简单的“闪亮”原则,你能够按照自己的步骤来使用云计算;我们已经知道,云计算还不成熟,并且随着应用程序的开发和部署需要一些返工。但是,现在已经是让你的企业为云做准备的时候了。
从虚拟化到私有云是向应用程序所有者提供自我服务能力的基本步骤。它提高了灵活性,减少了推向市场所需的时间,同时也提高了管理的复杂度,因为它添加了又一个抽象层。还需要有过程和工具来管理这个层。
使用云的最大优势在于你不需要创建处理异常的峰值的能力。虽然如此,你可以有意地来这样设计,从而得到随之而来的弹性命令和好处,用来更快地或者用一小部分成本来完成工作。
如果我们将云交给IT厂商的手中,因为他们试图让业务相信使用它能够降低成本(这还需要验证),那么我们会再一次失去创建持续敏捷的公司的机会,而内部的IT只是会扩展到稍微敏捷一些的外部供应商。现在是设置或者用户一个组织的时候了,它能够确保对日益增长的云系统的管理。这里的目的是要避免在将来发生IT整体危机。
我真的希望,在不久的将来,会存在像我描绘的那样的操作系统。我无法预见严格的技术上的整合问题,它可能会阻止那样的操作系统的实现。此外,采用一种敏捷的方法,其中实体的粒度以及它们的功能性和非功能性的属性都被很好地界定,会让我们更容易、更快地成功。这个操作系统将能如何对多种事件作出表现(反应),它需要多聪明才能避免过分工程化,仍然需要研究和讨论。
[1] “My View: IT To BT”,George F. Colony,Forrester公司的CEO,2006年8月18日(http://blogs.forrester.com/colony/it-to-bt.html )
[2] Eating the IT elephant, moving from Greenfield Development to Brownfield,Richard Hopkins和Kevin Jenkins著,IBM出版社,2008
William El Kaim是一家大型欧洲旅行社的首席IT架构师,定居在法国巴黎,网志在http://blog.resilient-it.com/ 。