中間件能否在無服務器時代存活

本文最初發佈於medium技術博客,經原作者授權由InfoQ中文站翻譯並分享。

無服務器架構避免了配置中間件的繁瑣操作,簡化了應用的運行環境。中間件能否在無服務器時代繼續存活乃至發展?本文剖析了核心、集成、輔助中間件等應用層次受無服務器的影響情況,探索了雲部署和本地部署環境下中間件的優劣所在。

思維實驗

請讀者考慮以下場景。假設如下:

  • 無服務器部署已經取得突破,並形成了統領新軟件服務市場半壁江山的三大雲服務巨頭。
  • 由於各巨頭間大打價格戰,用戶從雲中獲取主機的成本要低於自建服務器。
  • 大多數新應用是使用IDE編寫的,這簡化了無服務器部署。開發人員使用IDE編寫功能函數,然後通過函數調用構建可工作的應用。進而應用將在本地開發、調試、一步步執行和追蹤,一旦可正確運行就在雲端部署。IDE還支持版本控制和CI/CD。

上述假設場景中的三巨頭可映射爲現實中面帶微笑的傑夫·貝索斯、立刻跟進的微軟,以及掌控了龐大資金來源的谷歌。最終,隨便一名小朋友都能在一小時內讓應用在無服務器環境中運行起來,爲自己的了不起開心不已。

那麼中間件將置於何處,其未來何在?下面我們基於不同類型的中間件,分別闡釋這個問題。

應用架構刨析

一個典型的應用,其底層通常包括數據庫等多個核心中間件服務,還可能依賴於其它一些服務,例如消息隊列、緩存和流處理器等。

在覈心中間件層之上,是ESB、工作流引擎和API管理工具等集成中間件。這些集成中間件整合多種服務,以交付特定的業務用例。

集成中間件層之上,將爲終端用戶提供應用體驗,一般是運行在瀏覽器中的Web應用,或者是移動App等形式。

最後一層提供一些輔助服務(helper services ),用於提升用戶體驗,改進應用操作環境,目的是使服務生命週期儘可能的平滑。

上述各層都離不開中間件的支持。下面我們將闡釋無服務器雲將如何影響各層的實現。

對核心中間件的影響

核心中間件包括爲服務和應用的編寫和託管提供幫助的中間件(例如應用服務器、Web服務器等),以及應用直接使用的中間件(例如數據庫、消息代理、緩存和流處理器等)。

核心中間件受無服務器衝擊最嚴重。考慮到廣域網中存在高延遲,所有中間件會盡可能地部署在同一處。

應用服務器首當其衝,受到了無服務器的直接威脅。很多新應用都傾向於採用微服務架構,無服務器是微服務架構的自然擴展。微服務架構已將單體應分解爲各個松耦合的服務,由此應用非常易於遷移到無服務器架構。

無服務器雲服務以PaaS方式提供數據庫、消息代理和流處理器等服務。這裏需要考慮兩個問題。首先,是否依然給中間件留下了足夠的獨立用例?其次,如果無服務器架構接管了大部分開發,是否也將選擇接管中間件層?

對於第一個問題,應認識到無服務器架構固守着自己的做法。因此,用戶可能會遇到並不符合自身期望的情況。這完全可能成爲中間件得以延續的理由。另一方面,要解決此類問題,需要精心編排客戶服務。中間件市場依賴於被服務商和組織視爲合作伙伴關聯的客戶關係和客戶服務,而非“不容討價還價”的黑匣子。但是在雲服務巨頭服務的DNA中,從來都沒有客戶服務和客戶關係的一席之地。二者的業務模型完全是背道而馳的,存在難以彌補的鴻溝。雲服務巨頭如果無法解決這一問題,那麼就完全忽視了落於長尾分佈尾部的大量應用。這一鴻溝爲中間件企業留出了足夠的生存空間,甚至完全擠掉雲服務巨頭,贏得長期競爭。一種好的做法是,雲服務巨頭可以拿出部分收入,讓中間件供應商去處理客戶服務。這種模式更具可行性。

對於第二個問題,即便無服務器佔據了大部分市場,也不能說雲服務巨頭會吞併所有中間件,幹掉所有獨立項目。中間件可不簡單,它歷經數十年的時間,匯聚無數人的聰明才智,解決了大量的分歧,才達成目前的現狀。一旦缺乏維護,中間件代碼會隨着其所依賴的終端、硬件和業務的不斷演化而腐爛變質。接手它們有太多太多的工作要做,即便是雲服務巨頭也很難做到。

許多中間件項目都具有活躍的開源社區。由此,雲服務巨頭可以參加到項目中,做出貢獻,並引導項目,進而成爲市場領導者,甚至可出於自身的利益考慮做一些市場營銷。這樣,那些不屬於開源項目的獨立中間件將會陷入困境,進而逐漸消亡。多家雲服務巨頭甚至可以出於共同利益或者是並非真正競爭點的考慮,合作構建出類似於Kubernetes那樣的項目。

對於非開源廠商主導的市場,例如當前使用的Oracle數據庫和微軟Windows,雲服務巨頭可通過支付許可費或實現收益分成而參與其中。一方面,隨着無服務器的崛起,中間件獨立開發的市場將收縮。另一方面,通過向無服務器授權,中間件公司也可獲得新的收入來源。但是在這種關係中,雲服務巨頭無疑處於價格談判的上峯。中間件公司將會看到自身的收入雖然增加了,但利潤去下降了。鹿死誰手,尚待觀察。

如果許可費過高,並且中間件並未受到法律保護,那麼雲巨頭們可能會選擇另起爐竈,重新編寫一個新版本。具體結果將取決於中間件的複雜性,因爲重寫並非易事。巨頭們可能會在燒掉數百萬投資後,才發現自身缺乏相應的才能和對問題的理解。複雜性將是雲巨頭的敵人。如果試水重寫,它們可能會像一些古帝國那樣分崩離析。

如果中間件受到法律的保護,或者這些中間件產品的構造非常複雜,那麼雲巨頭可考慮併購方式。雲巨頭可在運營這些公司的同時,控制“使用收益”,並以更高的利潤向每個單獨用例出售。

對集成中間件的影響

核心中間件之上一層是集成中間件,例如ESB、工作流引擎和API管理工具等,它們組合和集成函數、服務和API。

讀者可能會認爲集成中間件並非無服務器。這就是爲什麼我們關注“無服務器支持的中間件”,而不是“無服務器”。在iPaaS和本地部署的集成中間件之間存在着競爭。

但是,這場戰鬥的勝負很可能是在其他地方決出的。集成中間件的性能取決於其獲取所集成服務的延遲。如果大部分服務、API和功能都部署在雲中,那麼雲中的集成中間件相比本地部署的同類產品具有明顯的優勢,反之同樣成立。如果集成中間件和所集成的服務都部署在雲中,那麼它們之間的網絡連接性能更高,因此延遲也會更低。並且,雲巨頭也可能做一些優化,將同一應用的相關部分部署於同一處。

在少數情況下,延遲無關緊要,這時將取決於iPaaS和本地部署中間件之間的功能差距。縱觀歷史,本地部署中間件一直在功能上處於領先。但是,隨着iPaaS的成熟,他們也將面臨艱苦的戰鬥。

對輔助服務中間件的影響

輔助服務包括安全性、可觀測性、追蹤和調試、運維、異常和欺詐檢測、應用生命週期管理(例如CI/CD、版本管理以及金絲雀、紅綠部署等負載均衡模式)等。

我認爲輔助服務正是雲巨頭的強大之所在。巨頭們控制着運行環境,進而通過投入資金,爲開發人員提供缺省環境之外的更多優秀的輔助服務。這一過程正在進行中。雖然本地部署也能做到這一點,但是設置環境並使其正常運行需要耗費大量的時間、精力和技能,因此一般僅適合於大型組織中的開發人員。

雲巨頭並不會直接插手本地部署的輔助中間件。雲巨頭本身也會使用輔助中間件。但是,輔助中間件可能會發現自身的用戶羣越來越多地遷移到雲中。它所導致的動態發展與我們在覈心中間件一節中所闡釋的類似。

無服務器平臺也將對編輯器和工具提出挑戰。編輯器和工具同樣需要與無服務器緊密集成在一起,雲巨頭也鼓勵編輯器和工具支持無服務器。但是不同於其他中間件,編輯器和工具本身很少受無服務器的挑戰。例如,開發人員可以在筆記本電腦上構建應用,然後推送到無服務器雲中,這並不會產生任何運行時延遲。看上去似乎雲巨頭也對插足編輯器不感興趣。

私有無服務器平臺

無服務器面對的最大風險,就是用戶會顧慮在缺乏標準情況下產生“供應商鎖定”的問題。人們真正關注的並非無服務器本身所提供的功能,而是這些功能所需的輔助服務以及安全性、可觀測性等平臺服務。這些服務是構建有意義應用所不可或缺的。如果缺乏諸如用於API調用的SQL這樣的標準,則很難有效地抽象出這些服務。

標準化正受到當前無服務器市場主導者的抵制。尚不清楚雲巨頭更應該擔心的是其它的雲巨頭,還是擔心用戶對供應商鎖定的反感。如果雲巨頭間的合作將提供可移植的應用,那麼就可以擴大整體的市場份額,進而使大家都從中受益。但達成這一願景尚需時日。另一種可能性是由政府去實施標準化。儘管這一考慮目前的可能性不大,但在一個能推行GDPR的世界裏,也並非是完全不可能的。任何形式的標準化,都將大大推進無服務器的採用。

Apache OpenWhisk等私有無服務器平臺(PSP,Private Serverless Platforms)正致力於爲此提供解決方案。他們提出,組織可以通過運行PSP,不依賴雲巨頭而獲得無服務器的大部分好處。這正是IBM等中間件公司在應對無服務器對中間件的威脅時所採取的戰略性解決方案。

但是,PSP需面對兩個挑戰:

首先,一旦沒有了平臺服務,PSP將失去其大部分生命力。PSP中必須加入數據庫,否則由於無服務器的無狀態本質,將造成交易的中斷。缺失其他平臺服務所造成的影響,尚待進一步觀察。誠然,我也並未押注於PSP。

第二,只有在組織能夠運行一定規模無服務器平臺的情況下,PSP才能通過提供規模經濟爲組織節省成本。在雲巨頭的IaaS產品中運行PSP將會失敗。即便PSP可以運作,雲巨頭也會相應地調高IaaS的價格。反過來看,探索多個小型組織是否可以將自身的資源安全地集成到同一個無服務器平臺,應該是一種有意思的嘗試。

微軟將自己的大部分無服務器平臺做了開源,並因此佔據了一席之地。企業可以選擇在本地運行同一工具。

尚未波及之處

機器學習算法本身已經形成了一些針對優化性能的專用硬件、GPU和系統。

看上去無服務器並未插足機器學習算法。對於算法交易、系統管理工具、AR和VR等對低延遲有需求的應用,同樣如此。

無服務器也可反戈一擊。例如通過使用機器學習或基於人工判斷等優化技術,支持將相關應用物理部署在同一機器上,類似於Kubernetes對pod的操作。無服務器可以處理部分用例,但並不是全部適用。

無服務器也可以通過提供預封裝版本的通用機器學習算法,在市場中分一杯羹。

即使無服務器無法進入這一細分市場,但從總體上看,這只是市場的很小一部分。無服務器難以進入的市場會越來越小,一切只是時間上的問題。

結論

中間件將繼續存在,尚未失去一切。很多應用依然依賴於核心中間件,本地部署的中間件也難以通過無服務器等將服務託管遷移到雲。服務託管一旦失守,多米諾骨牌開始倒下,其它所有都會失守。我認爲的這一戰場上,專利和商業機密相比開源軟件要起到更大的作用,因爲開源軟件已在雲巨頭們的掌控中。

原文鏈接:
 Can Middleware survive the Serverless enabled Cloud

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章