Jerry Cuomo谈云计算和IBM的PaaS

同我们在一起的是IBM WebSphere产品线的CTO,Jerry Cuomo。我们将探讨一些云计算方面的话题。Jerry,请您谈一谈云计算领域的最新进展。
总体上说,我们仍然就着我们通常看到的云分类来谈一谈。首先是基础设施服务,我们的基础设施服务进展不断。围绕IBM云的很多工作都在开展之中。IBM商 店还运行在Amazon平台上,因此你可在那里找到许多IBM的中间件软件。基础设施层之上就是平台服务层了,我们在此领域的投入越来越多,待一会儿我们 可以就这一方面简单谈一谈。

软件即服务是该分类系统中的第三个层次。同样,在这一层我们也做了大量的工作。当然,我们现在谈论的线索是将云当作基础设施服务、平台服务和软件即服务。 正如我们之前曾经谈到的,IBM云的独特之处在于,我们不区分服务到底运行在哪里。它们可以在本地(许多客户喜欢开始于先将服务运行在本地某个安全位置) 或外界的公共云(之前我跟你提到过我们的公共云产品)中运行,还可以在二者的组合,也就是混合云中运行。

公共云,私有云和混合云都是我们的目标。在我们跨类别提供产品,服务和解决方案时,我们思考的始终是共有云、私有云、和混合云之间的动态性。我想这就是让我们在该分类中保持独特的原因所在吧。

您刚刚提到了混合云。这个东西我们并不常听到,您能就此多谈一点吗?
混合云既包含公共云最好的方面又包含了防火墙背后的数据中心的能力。打个比方,我们的基础设施服务,当它发展到某个特定点时它就开始过载了, 考虑到可以在必要时租用能力,所以我们将超载的部分转移到公共云中。这个例子很有趣,譬如,我们在IBM做某些伸缩性测试时,需要租用别人的机器来运行伸 缩性实验,或担任客户端压力机,它们可能来自IBM云,也可能来自Amazon。

测试完成后,我们就把这些机器还回去。以上是一个很好的用于测试的混合云的示例。当然,也有使用混合云构建业务应用的。也许你的数据记录系统位于本地,企 业内运行了很多服务。但是,接着你又通过外包的方式租用一些互联网上的服务–物流服务、或者如Salesforce之类的公司提供的CRM服务–继而 构建混合应用。该应用也许继续使用本地的数据记录,但同时需要使用互联网上的服务。这是构建混合应用的另一种形式。

这是SOA的另一种代名词吗?
这绝对是SOA的另一代名词。我们当然会将这看成面向服务的架构,如果你是个基础设施的系统管理员,那么你所要打交道的是一组基础设施服务;如果你是一个 应用或服务消费者,你就会使用服务创建复合应用。你需要从防火墙之内和防火墙之外的各种服务中选择合适的功能。

但是,在这种SOA中,你必须考虑治理,你还要考虑安全,而在此之前,如果一切都运行在你的数据中心里,你可能根本不需要考虑它,或者不需要这么紧急地考 虑它。你需要分析,如果从外部访问服务,怎么支持双向信息访问的审计,你可能会和公共云之间建立一种安全通道以保证数据流的安全。这些都是当你的SOA延 伸到企业防火墙之外时你需要考虑的方方面面。当然,这绝对是SOA的一种形式。

开发者一般都对平台服务感到兴奋。对此,IBM想说点什么,IBM提供了哪些服务?
在基础设施服务中,核心是镜像(image);而在平台服务中,核心则是应用。下面我将详细解释一下我这句话的意思。在基础设施服务中,你有一个镜像,你 将该镜像部署在你最喜欢的云服务之中,而该镜像中有什么对于云平台来说是个黑盒子。里面有哪种类型的应用,哪种平台,这些都取决于你。在镜像中你可能已经 放置了任何你想放的东西。

而对于平台服务来说,你一般是带着你希望运行的应用来寻找平台服务的。多数平台服务有自己的特点。比如,它们运行Java应用、运行.NET应用或运行某 些特殊类型的应用–拿Force.com来说吧,它支持可在Saleforce生态系统内运行的应用。当然,IBM、WebSphere以及Java周 围也有着庞大的开发社区。

自然地,我们希望我们的平台服务专注在我们所擅长的领域–处理JEE这一领域内的应用程序,不仅仅提供运行它们的能力,还提供一些QoS方面的能力。比 方说,你带着一个WAR文件找到我们的平台,你带来的不仅仅是WAR文件,还有你的QoS策略,它是一个文档,里面包括你所理解的应用程序良好运行的描述 –必须实现高可用?必须执行某种特殊的安全加固?应用健康性相关的策略?它能够使用的内存是多大?等等。

有了这样的策略,你就可以放手了,那些非常繁重的应用程序管理相关的任务–管理其规模、性能、健康–都交由我们的平台服务去做。有趣的是,当我们谈及 平台即服务时,我们首先想到的是应用。而使用平台服务的用户可能是一个开发者,他带来的是一些应用程序和它们如何良好运行的一些目的。

接下来,我们处理应用程序和策略,并保证应用按照合同要求的方式运行。对于开发者而言,它提供了运行现有程序以及开发新应用的有效环境。

IBM有计划提关PaaS相关的产品吗?IBM倾向于那些编程模型(model)、语言和方法?
很好的问题!就WebSphere而言,答案绝对是”没错”。我们做的很好,而且我们挑选的一组客户的测试结果也很好。很快你就会在IBM云中看到它了, 我们的平台即服务将很快面世。你问到环境?作为起点,当然是以Java为中心的环境。我们在这一领域积累了太多专业知识,所以平台的核心一定是它,不过我 们相信,我们可以提供一个能够支持多种运行时(runtime),多种Java方言及API(也就是JEE)的平台。

考虑到使用这种API的应用程序即便尚未达到百万级,至少也有成百上千个,我们当然希望利用该领域内的技术和人们的素养。我们希望能够将你的JEE应用部 署到IBM的PaaS上运行。同时,我们相信还有一些新兴的编程模型能够与JEE互通有无,它们可能是以数据为中心的模型,有了它们之后,你就可以进行数 据分析、MapReduce、数据网格运维等。我们还希望在PaaS中提供对所有这类工作的支持。

当架构师处于一个拥有无穷无尽的技能和资源的环境中时,他们该如何思考设计和编程模型呢?
在某种程度上,架构师们仍然继续思考应用程序设计的基本方面,因为在一定程度上这些并没有改变。MVC模式仍然是应用架构的主要选择。我们希望人们能继续发展它并不断加入一些新的能力,比如与云相关的弹性伸缩等。

有一件需要考虑的事是如何对你的服务进行绑定。在我们的平台上,我们正在为架构与设计做的一件事情是,从你的应用程序运行时中将核心服务服务提炼出来,并 让这些服务成为平台级的共享服务。比如队列、数据存储和某些核心功能服务,当然还有为服务订阅者提供的非功能服务,如负载管理、日志管理和安全等。

将这些服务提炼出来,在云服务器上的以全局能力而暴露出来,你就能明确你的应用到底依赖于什么,依赖于哪些服务。如果你要建设一个Web应用,它需数据服 务,那么你要寻找的就是数据库表的映射逻辑。如果你想进行发布和订阅之类的能力,那么你就应该考虑提供消息队列能力的相关服务。

可能你还有安全需求,譬如单点登录。如果能够事先定义好这些服务,这将给你的应用带来一些灵活性,你不需要在应用中实现这些能力,而只需利用一些外部服务 即可。关于这些服务,比较爽的一件事情是平台已经为你管理好他们了。它们已经在那里,你不需要担心那些能力的分配,服务质量(QoS)之类的问题。你完全 可以假设它们已经在那里,这是非常给力的事情。现在你只需集中考虑应用的核心部分了。

你刚刚谈到的一些东西,比如消息队列和数据,听起来像是Amazon。他们有何区别,IBM的PaaS产品能够带来的最大的不同点是什么?
其实在市场上我们的一些产品已经名声在外很多年了–数据方面的DB2、WebSphere应用服务器、消息队列中间件MQ。我们正使用这些产品提供共享 服务的基础。他们在一定程度上不是黑盒子。当你面对该领域(PaaS)中我们的竞争对手时,你其实并不知道这些玩意是如何实现的。当然,也许在某个程度 上,你可能并不需要知道。

但是,有趣的是(记得我们前面谈到的吧),我们的客户似乎能够在他们的防火墙外面运行这些服务。他们喜欢云的概念,喜欢自助门户的概念,喜欢自己摆弄一些 运行时环境。他们喜欢弹性地管理这些环境,通过QoS文档明确表示他们的需求,不论是在本地还是在云中,它们都乐意这么干。

最酷的事情是,我们使用你的IT部门所熟知产品来支撑云的相关能力。比如说,DB2和WebSphere运行在你的云中,你的IT部门很可能已经拥有使用 这些工具的技能了。不论你信或是不信,在一个云环境中,你需要中间件来支撑它,而中间件将会产生日志,它们有命令行管理工具,而且,必须得有人去管理这些 东西。

我们在这些工具上建立门面,比方说,使它们更易于在多租户环境中工作,人们还得运维这些玩意儿。当你维护IBM云时,支撑数据的将是DB2,现在有成千上万的DB2系统管理员。所以说,你还需要培养管理这些工具以及运行时环境的技能。

对于这些运行时环境,与之交互的方式,命令行接口和WebSphere周围的所有工具,你会发现它们似曾相识。日志服务、JMX以及所以你已经知道而且喜欢的能力都会成为该生态系统的一部分。虽然它将被做成一个黑盒子,但是你可以走进它,而且你看到什么都能记得起来。

云的移植性问题呢?IBM曾是JEE的创立者之一,您对此问题怎么看?
绝对没错!有一件事让我着实很诧异,即便是同样的客户,他们曾经有很多想法,关于JEE,关于对该环境的一些期望,现在仍然是这样的。在这一领域,我们有JCP,有Sun和IBM以及其他公司参与标准的制定。但是,在云的领域里,他们却鸦雀无声。

我相信,标准非常非常重要。不管走到哪里,我们都离不开标准,它一直是个关键的东西。我们希望能够给客户足够的自由,他们构建的资产开始可能运行在供应商 A的云上,而当由于某种原因A不再提供服务 了,它还能转移到供应商B的云上去,并且不需要重新生成资产。实现云互操作的API层的相关标准,能够随意部署、随意运行、随意调试和管理,这是关键,而 且从未失去关注。

如我前面所说,我们面对IBM的PaaS和IaaS的时候,我们力求不把客户锁定在我们的云上,不论是公有云还是私有云。我们希望把选择适合其业务的方案 (公有云,私有云,甚至混合云)的权利留给客户,我们还希望继续与业界的其他厂商合作–就像我们以前所做的那样–致力于云上的标准。因为……我可以这 说,JEE和Java周围的标准已经影响到正在上学的孩子们。

我希望下一代API能够允许大家以同样的方式竞争,因为我认为正是这种自由的竞争使得客户热衷于我们的产品。我们可以期待为他们带来最好的东西,一定会 的。当然,我知道我们的竞争者们也能做到。但是,我还是希望能从用户那里听到他们的意见,就像他们以前那样,把我们拉到讨论标准的不同桌面上,JEE的、 JSE的、以及云标准。这是个好问题,我希望我们的客户能够不断地问出这样的好问题,因为这的确是很好的问题。

如果PaaS存在相关的云标准,它会是怎样的呢?
我认为可能会有不同的API解决云的不同领域的问题。在平台和基础设施的交叉点就需要相关的API。有一些开源项目如Eucalyptus就是一个例子, 它们希望将环境的供应抽象出来。我想,从我们提供服务的角度看,应该要确保在API层不被锁定,这样你的PaaS及可以立足于IBM云上、也可以立足于 Amazon云 上,甚至任何你认为重要的云上。

上面说的只是一个层次。我刚刚提到过在PaaS环境中,你希望注册服务,你希望有数据库服务或消息服务,等等。那么在PaaS和这些服务之间的契约的正确 性就变得非常重要了。我们称之为注册这些服务的云注册库–该注册库的格式是怎样的?如何成为该注册库的插件?这是另一层次,从应用服务层看待标准,以及 如何将你的应用做成其(译注:指PaaS)插件。

也许,甚至在容器层,还需要对不同编程语言的支持,不论它是JEE,还是脚本语言,或者是一些别的API,以支持平台服务注册。我觉得这样的例子可以产生 于IaaS与PaaS之间。在PaaS中有这样的API,围绕管理系统有非常多的API,比如接收日志警告信息。在这块我们可以做更多的标准化工作。

当然我不是说业内就没有这样的标准化活动;这样的活动一定是有的 。但是,我们还是希望在社区里听到用户的声音,希望他们能反馈哪些厂商与他们共鸣,同时我们也愿意给他们反馈哪些是与我们共鸣的。

如何在内部云和外部云间编排服务,将应用的不同部分部署在不同的地方?
与公共的SaaS服务相关的一件颇具诱惑力的事情是其低廉的价格与其广泛的可用性。每天都会有更多的服务出现,如果你愿意走向全球化,你就会见证这个n维 度事物的发生。如果你到过中国,哪里你有整套的commerce服务,那是一组B2B业务服务。消费这些服务的最佳方式是什么?如何基于他们构建复合应 用?正如你所言–数据放在何处?如何访问这些数据?

我们所看到的是,我们的客户,特别是有很多遗留系统的较大型企业,他们不能将数据放在多个系统中。让他们使用非本地服务并将其数据放到云端并不是一个好主 意。我们正在引进云环境,譬如CastIron环境,我们正在将流程治理延伸到云中,以辅助你完成一些工作,譬如创建工作流。

事实上,你可以使用我们提供的一些可视化工具,它可以帮助你将数据保留在防火墙后面,同时又能完成诸如向云供应商(如Salesforce)同步数据之类 的工作。你可以拷贝某些数据记录,但是工作流知道哪些数据是拷贝的、它们是如何移动的,甚至你还能在这些地方加上检查点(checkpoint)。在外部 服务交互时,你可使用任意可用的安全连接级别,HTTP、HTTPS、乃至VPN通道,可以根据数据的敏感程度逐步提高。

从编程的角度看,我们希望的这一切对你来说就像你的网络一样。在你的程序中,你就像打开一个连接某个云端服务的套接字(socket)一样,但这是基于你 所拥有的基础设施,它知道哪个才是真正的云端,然后我们做相应的处理。对与混合云计算而言,其关键是管理你的数据,使你既能控制你的数据,又能使用云端服 务。

我们已经看到客户开始使用云端服务,在SMB(译注:中小企业)范围内开展的远比大企业更热烈,但是我现在与我们的客户越来越多地谈到”互联网外包”的诱 人之处。通常,你购买套装应用,在本地围绕SAP构建应用系统,你围绕Oracle构建应用,围绕IBM构建……但是互联网上还有许多别的能力。

能够创建业务混搭,同时利用你的本地核心系统和云端服务,这是非常诱人的,前提是你拥有合适的工具。像CastIron提供的能力就能帮助你完成这种整合,快速构建健壮的整合应用。

能为我们介绍一些混合云部署的案例吗?它看上去是什么样子的?较之于只有公共云或只有私有云,混合云的意义何在呢?
比方说你为一家保险公司工作,该保险公司希望产生更多利润,进而想到了销售雪地汽车保险的点子,他们的目标是美国的西北部地区。通常开展一项销售活动需要围绕客户数据库建立相应的应用系统。它可能运行在某个本地ERP系统中。

我不知道现场的朋友中有哪些人的工作要与管理ERP系统的那些家伙有密切联系,但是,如果你希望以机会主义的方式来做这个事情,比方说”冬天就要来了”, 那么你的公司就可能无法足够敏捷地把应用搭建起来。我们看到一些人寻求第三方服务,比如”我们基于Salesforce构建该应用吧”。在此场景中,仅仅 为了雪地汽车我们就希望通过Salesforce收集线索。很好,但是,如我前面假想的,你现在有两个记录系统。

新的客户线索会流向Salesforce,然后才能转到本地其它人员手中。这就是”我喜欢这样,Salesforce非常廉价、非常便捷。我可以让我的汽 车销售应用搭建并运行起来。构建应用完全的过程完全是模板驱动的,所以我无需编写很多深奥的代码。大部分工作是模板和基于一大堆资产的配置”的一个很好的 例子。

但是,如何才能保证我不会拥有两份记录呢–一份位于Salesforce云中,一份可能在本地SAP系统中。这就是混合应用(混合云)的用武之地了。通 过它,你就可以从Salesforce获得提醒,然后触发一些工作流,譬如进行数据同步的工作流。每当一个新客户插入到Salesforce系统时就执行 该流程进行数据同步。

该触发事件将客户信息拷贝到你的系统记录中,你可依次完成接下来的任务,这就是它的优势之处,根本不需要麻烦你新建一个应用来处理这些客户机会。这只是互 联网外包管理客户机会的一个示例。它可能是一个短期机会,因为你不大可能在夏天销售雪地汽车。(我再一次勾勒了CastIron是如何工作的)最后,你也 可以加入一些控制点以监控公共云与本地中发生的活动。

这个环境中应用程序代码的可移植性怎样?支持人们的应用程序从一个云中迁移到另一个云中吗?这是否很重要?又是如何做到呢?
移植性是个关键点。这又回到了我们早前谈到的一些标准的话题上了。模型移植性至关重要。如果你关注现今一些本地应用程序的移植性,你就能发现一些东西,因 为在很多时候,本地应用会针对状态管理、数据访问等可能会影响通用的应用程序扩展的方面做一些大胆的假设。这就解释了为什么你会看到云端或PaaS运行时 API在一定程度上存在某些限制和约束,这真是为了支持底层系统平行伸缩的能力。

不论如何,从IBM的立场来看,我们希望能为用户提供现有环境中托管的应用的移植性支持。但是,我们在提供以移植性的同时,还将引入一些API,不论它来 自共享服务(数据库服务、支持底层方便地管理伸缩的缓存服务),不论你是一开始运行在IBM云中,然后要迁移到本地进行测试甚至运行,还是你一开始运行在 本地,后来有又觉得”对我而言,在本地运行没有多大价值了,我要将它转移到云端”。

API的移植性是最上层的。该领域中将成为真正的领导者的是那些驱动移植性标准的公司。不只是API层的移植性,还包括底层基础设施的接口的移植性,另外还需要一组有意思的付费模型/方式。这样才能使你做到–今天运行在本地,明天就可能搬迁到某个云端供应商。

在Java社区,似乎只有你们和VMware才能提供完整的端到端的解决方案。
这块一定会有越来越多的厂商聚拢过来。
在什么情况下使用云计算比维护本地数据中心还要昂贵呢?
我相信,如果你听过我们收购的CoreMatrix和Sterling Commerce的话,在IBM的软件部,就是这种情况。所以我非常感谢这个问题!上述两个公司维护他们自己的数据中心以提供他们的功能,以及我们在 IBM内所提供的功能。那些公司的特点是:专注于一小块应用集,同时这类应用的访问量却非常大。不论是CoreMatrix,还是Twitter或 Facebook,都能看到这一特点。

这些应用程序的差异不大,但是访问量很大,扩展性很强。我们常常看到构建这类应用的公司, 他们真正了解多租户运行的机理、如何实现弹性化、如何满足n次方的访问量,因为应用是他们的。而与其相对的情况是,我有许多应用程序。此时我只需达成某种 程度的平均行为就好了,因为这符合大数原则(或平均法则)。

我敢打赌,在我的平台上或托管环境中,不会出现所有应用同时达到峰值的情况。我的假设基于平均法则:有些应用忙,而另外一些则不忙。那么,我就可能在底层 进行资源的协调。我将就此对我的云环境进行行为的优化。所以,如果你的应用的访问量不大,也许通用云就能满足你的QoS要求,扩展性、弹性、QoS和其他 方面的要求,如安全等,云还在不断发展。云并非适合于每个人,有一些专属的云解决特定类型的应用。

你的公共云计划是什么?会支撑IBM商店吗,会重新收复Java社区吗?
显然,就像你归纳的。我们非常关注我们当前的用户群,而且我们知道,与他们合作对我们整体云产品和战略都是非常重要的。但是,通过内部组织的成长以及收 购,通过使用公共云,我们已经成长到能够抓住人们的心了。我可以给出这样的例子,也是我们一直在做的一个领域是我们引入了Cast Iron。

一般来说,CastIron有本地部署的方式,当然它能够支持我们通常做的转换工作,但是它还可以在IBM托管的第三方整合环境中托管,譬如本地与云之 间,云与云之间,帮助你构建复合应用。我们也通过CastIron产品学习了很多经验。此外,通过对Lombardi的收购,我们目前已经有一组基于云的 产品了,它们为业务分析员和业务领导提供了一组很好的工具。

而且,不通过传统软件方式卖,而是通过基于云托管的工具或托管产品来卖。这些产品不断地吸引了很多我们希望赢过来的客户,他们不一定是IT方面的客户,也 包括业务领导们。随着我们不断扩大我们的云产品,我的期望当然不只是吸引我们现有的客户,我们还希望能够吸引其他客户,不只是传统地域内的。我的意思是, 我们还希望,我们的一些云产品能够帮助我们在新兴市场上吸引到来自其他地域的更多客户。

我们正在开展一些工作。例如,我们在中国建立了一个Commerce云,我们还做了一些别的工作,帮助我们在新兴领域里树立了我们的形象,我们还希望在全 球推广这些工作。从部署模型的角度看,云,尤其公共云,帮助我们触碰到了这些新机会。我们将一如既往地迎合大企业的需求,但是我认为我们也有很多迎合各个 行业的其他人们的机会。

This entry was posted in Cloud Computing, SOA. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s