对IBM“混合”的困惑与再思考

在上周T媒体编译文章《穷则思变，对IBM Watson走向AWS、Azure和Google的几点思考》中，CRN原作者Donna Goodison针对AI、云基础实施（IaaS）与IBM的潜在合作机会进行了评论。

但实际上，这项对混合IT支持声明掩盖了IBM另一项关键消息：IBM即将推出新的IBM Cloud集成平台并加入到混合集成平台（HIP）赛道之中。很多时候，我们很容易认为“混合IT”中的“混合”与“混合集成平台”中的“混合”意思相同。

然而，如果我们仔细研究一下这种流行词汇，就会发现一个令人困惑但重要的区别。二者意义有所不同，很多所谓混合集成其实并不是混合的，因为它指的是那些针对于混合IT本身的集成（尽管许多公司会将意义混淆）。

相反，“混合集成”真正的含义是“不同集成技术的混合”——这种混合很可能与它所支持的混合IT策略背道而驰。

HIP起底

事实上，如果我们去查看市场中对HIP最为鼓吹的厂商，就会发现他们具有共性：IBM、Axway、Oracle、Software AG、Talend和TIBCO。在这些厂商所有供应产品的背后，我们会看到新服务与传统旧服务的混合，就像聚合一群“SKU”并借此创建一个平台一样。

例如，在IBM的例子中，新的IBM云集成平台包括Apache Kafka(用于事件流程)、IBM Aspera(用于高速数据传输)、Kubernetes(用于微服务编排容器)和备受推崇地IBM MQ。

实际上，IBM MQ的历史可以追溯到1993年，当时它还是MQSeries。在2000年代，IBM将其命名为WebSphere MQ，现在它是蓝色巨人云集成平台的一部分。

IBM和其传统同行们会认为，将传统集成技术与全新的云技术混合在一起没有问题，因为毕竟，企业本身就在混合运行传统技术和全新云技术。因此，HIP由这样一类型能力的集合组成难道不合理吗?

其实，Gartner认为企业必须能够对高复杂性的IT进行处理。 “Smarter with Gartner”系列文章中的一篇解释道，“在大多数情况下，传统的集成工具包（一组特定于任务的集成工具），无法解决这种级别的复杂性。企业需要转向Gartner所说的混合集成平台，或称HIP。HIP是所有功能的‘家’，这些功能确保了组织中多个数字转型活动得以顺利集成。”

集成供应商们对Gartner的表述非常满意，因为它证明了向客户兜售新旧集成技术的混合产品并将其包装为一个平台是合理的。

其结果就是双峰集成（bimodal intergration）的出现。Gartner分析师Massimo Pezzini、Jess Thompson、Keith Guttridge和Elizabeth Golluscio在2016年的一份报告中指出:“解决数字革命带来的无处不在的集成需求，正促使IT领导者转向采用一种双峰式的、DIY（Do-It-Yourself）的集成方法。在本研究讨论的最佳实践的基础上实现一个混合集成平台是一个关键的成功因素。”

但这种观点与Gartner “双峰IT哲学”（bimodal IT philosophy）一样，带有缺陷。

双峰集成的不足处

对于许多大型企业来说，双峰IT模式成为现实，而争论的焦点是围绕于这到底是好事还是坏事。

就目前而言，关于混合IT的讨论使人们愈发认识到，双模态IT是一种反模式（anti-pattern），而且有一种更好的方法来处理不同的环境和技术，而不是将它们分为“慢”和“快”模式。

例如: 混合IT（Hybrid IT）是一种以工作负载为中心的管理方法，它抽象了部署环境的多样性，使组织能够关注他们部署的应用程序的业务价值，而不是仅适用于一个或另一个环境的技术细节。

实际上，混合IT的最佳实践是基于云原生（云本地，cloud-native）的。据Pivotal网站介绍:“云原生是一种利用云计算交付模型的优势构建和运行应用程序的方法。”“云原生关于如何创建和部署应用程序，而不是在哪里创建。”

请注意，云原生定义中最重要的特征是它不是特定于云的。事实上，我们也根本不需要依赖一个完全基于云原生的云，只需要采用一种可利用云交付模型优势的架构，即使它是基于本地的。

因此，企业应该应用这样云原生集成方法（cloud native integration approaches），这样不管底层技术在哪里，都可将其抽象出来，而不是将其与新旧工具的大杂烩连接起来。

不过，云原生一样令人困惑。

对云原生集成的困惑

如果企业现在就考虑扔掉Gartner的HIP报告，转而购买云原生集成产品，那么他们实在是太着急了。首先，云原生集成仍然是相当新生的和相对不成熟的，特别是与现有组件相比。

其次，在许多情况下，供应商所称的“云原生集成”根本不是云原生集成——或者至少不符合上面的定义。

例如，Red Hat最近发布了自身的Red Hat Intergration产品，并将其吹捧为云原生集成平台。然而，从表面上看，它仍是一些旧产品的集合包，包括AMQ、Fuse Online和其他产品。

因此，Red Hat Intergration更符合Gartner的HIP理念，而不是一款符合云原生标准的新产品。Red Hat集成经理Sameer Parulkar解释说:“我们发现客户正在构建集成架构，其中包括来自多个产品的功能，因此我们创建了一个专用的SKU，并将我们的集成组合中的所有功能集成到一个产品中。”“所有这些部分都以一种更统一的方式联系在一起，通过一个熟悉的界面进行管理。”

云原生集成和iPaaS之间的界限很模糊

似乎，Red Hat所说的“云原生”似乎更多的是指在云中运行，而不是构建一个跨环境的抽象概念——但是这种区别仍然很模糊。

戴尔 Boomi进一步模糊这一界限。Boomi是一个成熟的集成平台即服务(iPaaS)产品，这意味着它在云中运行，客户可以通过云服务访问它。

然而，仅仅是作为云服务来运行，并不能因此就将该产品定义为云原生产品。话虽如此，Boomi的确正走在云原生之路上。Boomi网站解释说:“云原生集成云消除了客户购买、实施、管理和维护底层硬件和软件的需求，无论他们在哪里处理集成，（比如）在云中、在本地还是在网络边缘中。”

值得一提的是，Boomi的方式与Gartner关于HIP的想法背道而驰。“在混合的IT环境中，Boomi平台可以部署在任何有必要支持集成的地方:在云中、在本地或两者兼而有之，”Boomi网站继续说道。

还有一个云原生代表iPaaS供应商SnapLogic (与此同时，它也在尝试打“HIP ”牌)。“我们已经证明了我们是一个集成的平台,既易于使用和强大到足以处理一组广泛的集成场景,“ SnapLogic CEO Gaurav Dhillon这样夸赞到,“跨越应用程序的集成、API管理B2B集成、数据集成、数据工程,和更多的——无论是在云中,本地,或在混合环境。”

服务网格:云原生集成的未来

如果我们能有幸从一张白纸开始设计云原生集成，那么它可能看起来一点也不像HIP，而且可能也不太像iPaaS。

它看起来更像是Kubernetes等云原生社区所称的服务网格（Service Mesh）。“服务网格是一种可配置的、低延迟的基础设施层，其设计用于通过应用程序编程接口(API)以在应用程序基础设施服务之间处理大量基于网络的进程间通信，”Nginx网站解释说。

此定义虽然在技术方面，但其结论是服务将抽象的网络级通信与API网格化，从而支持混合IT抽象层，通过在网络层实现集成，该抽象层能够实现我们所期望的所有性能。

然而，服务网格的实现(如Nginx所讨论的)还只是刚刚起步。“Istio由谷歌、IBM和Lyft支持，目前是最知名的服务网格架构，”Nginx网站继续说道。Kubernetes最初由谷歌设计，目前是Istio支持的唯一容器编排框架。

Nginx补充了一个重要的警告。Istio不是唯一的选择，其他服务网格实现也在开发中。随着云本地集成的成熟，如今流行的双峰集成方法将愈发过时。所以，IBM支持Istio并不意外。现在的问题是，其他现有的集成供应商何时(或者是否)有勇气效仿。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。