Benoit Lheureux 在其博文中写道,云计算不仅仅是
……激增且混乱的云服务、创新、混搭和云资源的消费……
在他看来:
云服务消费对于业务来说仍然非常技术化,其中存在大量管理和合规问题。到最后,至少有一些公司需要帮助,来解决这些问题(想一想服务就知道了)。
所以,
治理、整合、安全。这些只是企业在消费云服务(这里的云服务不是那些相对容易的基于浏览器的服务,而是基于 API 的较为复杂的云服务)时必须解决的几个问题。
Daryl C. Plummer 认为,解决云服务整合的问题需要云服务的代理,这:
……是云计算中最大的利润增长点,总市场价值约为 1 万亿。
为更好地描述这些整合问题,Plummer 引入了一个新词汇——Cloudstreams,它:
……关注整合、治理和安全影响点……云服务产生了(云)服务间整合的需要……前所未有的需要。企业希望将本地应用与云服务连接起来,也希望实现云服务间的连接。并且,所有这些连接都应该安全地进行,其性能也应被管理起来。简言之,他们需要的是灵活的、良好定义的、API 层的服务整合,使用策略对数据、消息以及服务调用进行编排。这就是Cloudstream。
Plummer 认为,SOA 供应商:
……为一些基本相同的事情建立了一套很绚的词汇。他们说 SOA 网关和 XML 设备提供 SOA 的安全与管理,现在其保护的对象则是云。这些产品通过本地设备、软件、甚至云服务的方式交付……这些不同的词汇之所以会出现,是因为这些公司服务的客户使用不同的方式谈论他们的问题,尽管这些问题几乎相同。客户需要内部系统与外部服务(SOA 或云)之间的交互,他们需要管理、安全加固、整合、以及加强这些服务的访问。问题是,他们在描述需求时都站在纯技术层面;所以,供应商也随之带回了解决这些需求的相关技术语言……因此,除非具体到细节,不然就很难理解为什么选择这个供应商而非那个。
Plummer 认为,新名词使得我们站在一个较高的层次探讨云与 SOA 中服务整合问题。它不考虑具体的 API/ 技术层面的事情,相反,它考虑的是云服务之间或云服务与企业之间的信息流(以及策略和关键指标):
这是使我们能一致地描述云服务间的整合的唯一途径。它描述的互操作性是面向所有人的,而非只是那些天才工程师们……将云间的整合(CI )的打包成Cloudstreams的想法为(提供这类仲裁服务的)提供商们敞开了机会的大门。既然人们还记得,云(以及 SOA)应该封装与服务交互的技术细节,让人们把这些交互作为业务的一部分来思考解决方案,Cloudstreams也应该有其相应的生存空间。让我们应关注解决方案中的其他整合需求,而非只是那些设备或具体技术。
在对 Plummer 博文的回复中, K. Scott Morrison 说:
Daryl 所描述的问题是太多公司……使用技术去解决根本的业务问题。技术是关于细节的游戏……但是,当面临几乎举不胜举的功能列表时,大多数客户很难在供应商之间做出选择。某供应商使用对应于 WS-Security Kerberos Token Profile 的 Kerberos 令牌,而另一供应商则使用另一套 SSL 加密套件。若单纯地比较产品的特性,会不自觉地迷失事实,也许业务要解决的问题是与 Salesforce.com 进行简单地整合。Daryl 的目标是用Cloudstream归纳云服务整合有关的讨论,而不是以牺牲技术上最终需要的配置细节为代价。
SOA 之所以消失,原因之一是它试图通过(由供应商驱动的)技术解决业务问题。但愿一个围绕Cloudstream的更全面的方法能够避开这个陷阱。
评论