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的更全面的方法能够避开这个陷阱。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论