對IBM“混合”的困惑與再思考

在上周T媒體編譯文章《窮則思變，對IBM Watson走向AWS、Azure和Google的幾點思考》中，CRN原作者Donna Goodison針對AI、云基礎實施（IaaS）與IBM的潛在合作機會進行了評論。

但實際上，這項對混合IT支持聲明掩蓋了IBM另一項關(guān)鍵消息：IBM即將推出新的IBM Cloud集成平臺并加入到混合集成平臺（HIP）賽道之中。很多時候，我們很容易認為“混合IT”中的“混合”與“混合集成平臺”中的“混合”意思相同。

然而，如果我們仔細研究一下這種流行詞匯，就會發(fā)現(xiàn)一個令人困惑但重要的區(qū)別。二者意義有所不同，很多所謂混合集成其實并不是混合的，因為它指的是那些針對于混合IT本身的集成（盡管許多公司會將意義混淆）。

相反，“混合集成”真正的含義是“不同集成技術(shù)的混合”——這種混合很可能與它所支持的混合IT策略背道而馳。

HIP起底

事實上，如果我們?nèi)ゲ榭词袌鲋袑IP最為鼓吹的廠商，就會發(fā)現(xiàn)他們具有共性：IBM、Axway、Oracle、Software AG、Talend和TIBCO。在這些廠商所有供應產(chǎn)品的背后，我們會看到新服務與傳統(tǒng)舊服務的混合，就像聚合一群“SKU”并借此創(chuàng)建一個平臺一樣。

例如，在IBM的例子中，新的IBM云集成平臺包括Apache Kafka(用于事件流程)、IBM Aspera(用于高速數(shù)據(jù)傳輸)、Kubernetes(用于微服務編排容器)和備受推崇地IBM MQ。

實際上，IBM MQ的歷史可以追溯到1993年，當時它還是MQSeries。在2000年代，IBM將其命名為WebSphere MQ，現(xiàn)在它是藍色巨人云集成平臺的一部分。

IBM和其傳統(tǒng)同行們會認為，將傳統(tǒng)集成技術(shù)與全新的云技術(shù)混合在一起沒有問題，因為畢竟，企業(yè)本身就在混合運行傳統(tǒng)技術(shù)和全新云技術(shù)。因此，HIP由這樣一類型能力的集合組成難道不合理嗎?

其實，Gartner認為企業(yè)必須能夠?qū)Ω邚碗s性的IT進行處理。 “Smarter with Gartner”系列文章中的一篇解釋道，“在大多數(shù)情況下，傳統(tǒng)的集成工具包（一組特定于任務的集成工具），無法解決這種級別的復雜性。企業(yè)需要轉(zhuǎn)向Gartner所說的混合集成平臺，或稱HIP。HIP是所有功能的‘家’，這些功能確保了組織中多個數(shù)字轉(zhuǎn)型活動得以順利集成?！?/p>

集成供應商們對Gartner的表述非常滿意，因為它證明了向客戶兜售新舊集成技術(shù)的混合產(chǎn)品并將其包裝為一個平臺是合理的。

其結(jié)果就是雙峰集成（bimodal intergration）的出現(xiàn)。Gartner分析師Massimo Pezzini、Jess Thompson、Keith Guttridge和Elizabeth Golluscio在2016年的一份報告中指出:“解決數(shù)字革命帶來的無處不在的集成需求，正促使IT領(lǐng)導者轉(zhuǎn)向采用一種雙峰式的、DIY（Do-It-Yourself）的集成方法。在本研究討論的最佳實踐的基礎上實現(xiàn)一個混合集成平臺是一個關(guān)鍵的成功因素。”

但這種觀點與Gartner “雙峰IT哲學”（bimodal IT philosophy）一樣，帶有缺陷。

雙峰集成的不足處

對于許多大型企業(yè)來說，雙峰IT模式成為現(xiàn)實，而爭論的焦點是圍繞于這到底是好事還是壞事。

就目前而言，關(guān)于混合IT的討論使人們愈發(fā)認識到，雙模態(tài)IT是一種反模式（anti-pattern），而且有一種更好的方法來處理不同的環(huán)境和技術(shù)，而不是將它們分為“慢”和“快”模式。

例如: 混合IT（Hybrid IT）是一種以工作負載為中心的管理方法，它抽象了部署環(huán)境的多樣性，使組織能夠關(guān)注他們部署的應用程序的業(yè)務價值，而不是僅適用于一個或另一個環(huán)境的技術(shù)細節(jié)。

實際上，混合IT的最佳實踐是基于云原生（云本地，cloud-native）的。據(jù)Pivotal網(wǎng)站介紹:“云原生是一種利用云計算交付模型的優(yōu)勢構(gòu)建和運行應用程序的方法。”“云原生關(guān)于如何創(chuàng)建和部署應用程序，而不是在哪里創(chuàng)建。”

請注意，云原生定義中最重要的特征是它不是特定于云的。事實上，我們也根本不需要依賴一個完全基于云原生的云，只需要采用一種可利用云交付模型優(yōu)勢的架構(gòu)，即使它是基于本地的。

因此，企業(yè)應該應用這樣云原生集成方法（cloud native integration approaches），這樣不管底層技術(shù)在哪里，都可將其抽象出來，而不是將其與新舊工具的大雜燴連接起來。

不過，云原生一樣令人困惑。

對云原生集成的困惑

如果企業(yè)現(xiàn)在就考慮扔掉Gartner的HIP報告，轉(zhuǎn)而購買云原生集成產(chǎn)品，那么他們實在是太著急了。首先，云原生集成仍然是相當新生的和相對不成熟的，特別是與現(xiàn)有組件相比。

其次，在許多情況下，供應商所稱的“云原生集成”根本不是云原生集成——或者至少不符合上面的定義。

例如，Red Hat最近發(fā)布了自身的Red Hat Intergration產(chǎn)品，并將其吹捧為云原生集成平臺。然而，從表面上看，它仍是一些舊產(chǎn)品的集合包，包括AMQ、Fuse Online和其他產(chǎn)品。

因此，Red Hat Intergration更符合Gartner的HIP理念，而不是一款符合云原生標準的新產(chǎn)品。Red Hat集成經(jīng)理Sameer Parulkar解釋說:“我們發(fā)現(xiàn)客戶正在構(gòu)建集成架構(gòu)，其中包括來自多個產(chǎn)品的功能，因此我們創(chuàng)建了一個專用的SKU，并將我們的集成組合中的所有功能集成到一個產(chǎn)品中?！薄八羞@些部分都以一種更統(tǒng)一的方式聯(lián)系在一起，通過一個熟悉的界面進行管理?！?/p>

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

似乎，Red Hat所說的“云原生”似乎更多的是指在云中運行，而不是構(gòu)建一個跨環(huán)境的抽象概念——但是這種區(qū)別仍然很模糊。

戴爾 Boomi進一步模糊這一界限。Boomi是一個成熟的集成平臺即服務(iPaaS)產(chǎn)品，這意味著它在云中運行，客戶可以通過云服務訪問它。

然而，僅僅是作為云服務來運行，并不能因此就將該產(chǎn)品定義為云原生產(chǎn)品。話雖如此，Boomi的確正走在云原生之路上。Boomi網(wǎng)站解釋說:“云原生集成云消除了客戶購買、實施、管理和維護底層硬件和軟件的需求，無論他們在哪里處理集成，（比如）在云中、在本地還是在網(wǎng)絡邊緣中。”

值得一提的是，Boomi的方式與Gartner關(guān)于HIP的想法背道而馳。“在混合的IT環(huán)境中，Boomi平臺可以部署在任何有必要支持集成的地方:在云中、在本地或兩者兼而有之，”Boomi網(wǎng)站繼續(xù)說道。

還有一個云原生代表iPaaS供應商SnapLogic (與此同時，它也在嘗試打“HIP ”牌)?！拔覀円呀?jīng)證明了我們是一個集成的平臺,既易于使用和強大到足以處理一組廣泛的集成場景,“ SnapLogic CEO Gaurav Dhillon這樣夸贊到,“跨越應用程序的集成、API管理B2B集成、數(shù)據(jù)集成、數(shù)據(jù)工程,和更多的——無論是在云中,本地,或在混合環(huán)境?！?/p>

服務網(wǎng)格:云原生集成的未來

如果我們能有幸從一張白紙開始設計云原生集成，那么它可能看起來一點也不像HIP，而且可能也不太像iPaaS。

它看起來更像是Kubernetes等云原生社區(qū)所稱的服務網(wǎng)格（Service Mesh）。“服務網(wǎng)格是一種可配置的、低延遲的基礎設施層，其設計用于通過應用程序編程接口(API)以在應用程序基礎設施服務之間處理大量基于網(wǎng)絡的進程間通信，”Nginx網(wǎng)站解釋說。

此定義雖然在技術(shù)方面，但其結(jié)論是服務將抽象的網(wǎng)絡級通信與API網(wǎng)格化，從而支持混合IT抽象層，通過在網(wǎng)絡層實現(xiàn)集成，該抽象層能夠?qū)崿F(xiàn)我們所期望的所有性能。

然而，服務網(wǎng)格的實現(xiàn)(如Nginx所討論的)還只是剛剛起步?！癐stio由谷歌、IBM和Lyft支持，目前是最知名的服務網(wǎng)格架構(gòu)，”Nginx網(wǎng)站繼續(xù)說道。Kubernetes最初由谷歌設計，目前是Istio支持的唯一容器編排框架。

Nginx補充了一個重要的警告。Istio不是唯一的選擇，其他服務網(wǎng)格實現(xiàn)也在開發(fā)中。隨著云本地集成的成熟，如今流行的雙峰集成方法將愈發(fā)過時。所以，IBM支持Istio并不意外。現(xiàn)在的問題是，其他現(xiàn)有的集成供應商何時(或者是否)有勇氣效仿。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。