你的 PaaS 是組合型還是上下文型?

類別: IT

我想探討一個微妙的話題,但這個話題將對抗脆弱(anti-fragile)IT系統的進展方向和PaaS(Platform-as-a-Service,平臺即服務)提供商將做何抉擇產生深遠的影響:上下文型和組合型這兩者在系統的可擴充套件性和可程式設計性方面的不同之處。我一直在探索,在雲端計算的時代,如何將DevOps、複雜適應系統(Complex Adaptive System)以及抗脆弱性這三者中的概念應用到軟體開發和IT運營之中。該話題就是我這個探索中的一個非常重要的部分。

Neal Ford自稱是系統整合商ThoughtWorks公司的“主管、軟體架構師以及文化基因辯手他最近所發的文章對這兩種模式描述的很透徹:

在我的主題演講中,我定義了在軟體開發界很流行的兩種型別的可擴充套件性/可程式設計性抽象機制:組合型下文型。基於外掛的體系結構就是個使用上下文型抽象機制的很好的例子。外掛API提供了一堆資料結構以及一些其它的上下文,開發者或者繼承或者呼叫已有的方法。但為了使用這些API,開發者必須熟悉上下文提供了些什麼,有時要熟悉這些東西所付出的代價比較高昂。。。 要進行看似微不足道的改變,所需掌握的知識和所需花費的精力卻成了讓改變發生的障礙,讓開發者空有一個永遠笨拙的工具。上下文型的工具並不總是很糟糕,沒有上下文型這種方式,Eclipse和IntelliJ將不復存在。上下文型的工具提供了大量開發者可以直接使用的基礎設施。只要你能掌握好,複雜的Eclipse的API就為你提供了大量封裝好的功能。。。問題的難點來了:這些都是怎麼封裝的?

在20世紀90年代後期,4GL還在大行其道,那些語言就是上下文型方式的例證。它們將上下文內嵌到了語言本身之中:dBASE,、FoxPro、 Clipper、 Paradox、 PowerBuilder、 Microsoft Access等等這類相似的語言和工具直接都具有了資料庫所具有的一些功能。最終由於Dietzler定律,4GL失去了人們的寵愛。在我所寫的書《卓有成效的程式設計師》(Productive Programmer)中,基於我同事Terry Dietzler的經驗, 我定義了該定律。那時他正在我的老闆那裡幹著許多各種Access專案:

Dietzler的Access定律

每個Access專案最終都將失敗。這是因為,儘管使用者想要的東西當中有80%在建立起來很快並且也很簡單,還有10%也能做到但有難度,但最終會由於誰也無法超越內建的抽象機制,那剩下的最後10%不可能完成,可使用者總是想要得到100%的他們所想要的東西。

最終,Dietzler定律消滅了4GL的市場。儘管它們使得建立簡單的東西變得容易了也快了,但它們沒有上升到能滿足真實世界裡的很多需求。我們都回歸到了通用程式語言。 

組合型系統往往是由更細粒度的部件組成,各部件間以特定的方式進行連線。這種抽象機制比較強大的例子出現在各種*-nix作業系統的shell當中,這些shell能夠將互相獨立的行為串聯起來產生一種新東西。 1992年的一個著名的故事說明了這種抽象機制是多麼的強大。有人請Donald Knuth寫一個程式來解決這個文字處理問題:讀入一個文字檔案後找出其中n個使用率最高的單詞,並將這些單詞以及它們出現的頻率排序後列印出來。 他用Pascal寫了一個十幾頁的程式,並在此過程中設計(並記錄)了一個新演算法。後來,Doug McIlrov演示了一個用不超過一條Twiiter博文的長度寫的shell指令碼,以更加簡單、優雅和更容易理解(如果你能看懂shell命令的話的方式解決了同樣的問題:

tr -cs A-Za-z '\n' |tr A-Z a-z |sort |uniq -c |sort -rn |sed ${1}q

我猜即使是Unix shell的設計者也常常會對開發人員利用Shell那簡單但強大的組合型抽象機制搞出來的別出心裁的用法感到驚奇。

Ford繼續非常詳細地描述了每種方式的利與弊,但我認為,對於理解應該如何開發能夠驅動新IT模型的工具和工具鏈來說,他所得到的主要結論非常關鍵。


這些抽象機制同樣適用於工具和框架,特別適用於必須在功能和複雜性方面要向上適應的工具,比如build工具。 通過來之不易的經驗教訓得知,組合型的build工具比上下文型的(在時間、複雜度和可用性上)能更好的向上適應更復雜的專案。就象Ant和Maven這類上下文型的工具可以通過外掛API進行擴充套件,對於原先作者預想到的擴充套件做起來就很容易。然而,要是想以一種並沒有在API設計範圍之內的方式進行擴充套件,不是非常難就是不可能。Dietzler定律又回來了。這一點對於那些其內部功能實現的關鍵部分,比如各項任務的排序,不通過很特殊的手段就無法控制的工具來說更是如此了。

Ford的對比最終幫我理清了我這段時間以來我一直所關心的同PaaS有關的一個關鍵問題。在我的心目中,目前市場上主要有兩種型別的PaaS系統(現在用Ford術語說非常清晰)。一種是上下文型的PaaS系統,它提供了編碼框架,按照此框架編寫的程式碼可以很少或者不用特殊的配置或者定製自動化就能得到這種PaaS所提供的功能。另外一種是組合型PaaS,它的主要功能是通過可以按需組裝以支援不同的應用程式的部件(包括運維自動化)來實現的。

上下文型PaaS

上下文型PaaS的例子有Google起初釋出的App Engine、Heroku以及其它一些“第一代”PaaS系統,這些系統要求開發者遵從特定的體系結構,要在應用中使用各PaaS系統專有的類。 在建立這些框架本身設計中就考慮到的各種變化範圍內的應用程式時,這些框架驚人地強大,但一旦出了這個範圍,它們馬上就不行了。

Google的App Engine對後臺請求的處理時間有個30秒的限制,這就是一個最有代表性的例子。這對想寫個Facebook遊戲的人來說沒問題,但這個限制使得大家無法用它建立很多的涉及多個步驟的事務處理型應用。當然,也有辦法處理掉這些問題,但多數情況下這些辦法都比較複雜,而且也會給系統平添一些風險。

Ford在他的文章中還談到,在20世紀90年代後期,4GL也出現過類似的問題。那時我還在Forte軟體公司(1999年被Sun微系統公司收購)工作,我們為分散式應用程式的開發建立了一個開發執行環境。 我們的業務模型非常依賴於做系統整合的合作伙伴,這些系統整合商幫助我們的客戶編寫很多都非常複雜的應用程式,而且每個系統整合商最後都建立了各自的框架環境,力求讓編寫那些複雜應用程式變得“更加的簡單”。 

問題是什麼?幾乎使用這些框架中的某個框架的每一個客戶都有該框架不能完美處理的一個(或多個)需求。造成的結果,要麼是系統整合商為了滿足那些需求去胡亂修改他們的框架,從而不可避免地導致框架用起來不那麼“容易”了;要麼就是客戶為了實現需求完全跳過了框架,結果得到的應用程式執行、除錯起來更困難了。

組合型PaaS

組合型PaaS系統站在另一個角度,對基於其建立的應用程式的體系結構或功能並不作太多的考慮,它考慮更多的是,要對包括基礎設施自動化、資料來源、專業的資料工具等等在內的服務的裝配進行簡化。我認為,Cloud Foundry是組合型PaaS的一個最有代表性的例子,它是來自VMWare的開源的PaaS,現在Cloud Foundry是VMware公司 拆分出來的Pivotal Initiative的一個組成部分。當下最新的Heroku、EngineYard、CloudBee以及一些別的PaaS也都比“第一代”PaaS系統越來越多的展現出這種新思路了。

Cloud Foundry的一張舊的但很具說明性的示意圖。

然而,可能最重要的是,現在有一些為建立和釋出應用程式而直接部署在基礎設施服務中的開源build工具鏈(tool chain),完全體現了很純的組合型思路。將GitHub同Jekins、Gradle、AWS、CloudFormation、Autoscaling等等工具都結合起來,就能得到一個完全自動化的、領會的應用程式開發和執行“平臺” —— 這正是你想從PaaS中獲得的東西。當然,美中不足的是,在未來的時間中將需要你來裝配和維護這個工具鏈(而不是讓PaaS供應商為你做這些事情)。

現在把概念再往前推一步。想象一下這樣的部署環境,它提供了非常廣泛而大量的單個的工具和元件併為你簡化了根據需要將它們組成你所需要的工具鏈的步驟。想象一下這樣的環境,環境中的每個開發團隊都允許從已知的工具鏈“模式”中進行選擇,並能讓他們針對每個專案對所選的工具鏈根據需要做出修改。這是我所認為的將會勝出的終極通用PaaS,而絕不會是那些難用但是上手容易的、基於框架的PaaS。

組合型和上下文型的概念當然遠遠不僅僅適用於PaaS和雲端計算。但必需指出的是,同穩定性和靈活性兩者一樣,這可不是一個非黑即白型的選擇題。IT環境中的有些部分應該是組合型的,但往往也有一些部分使用相對穩定的上下文型擴充套件更合適。組合型系統也可以利用本身主要設計目的就是用過上下文的方式進行擴充的基於API驅動的系統。

關鍵在於要從它們是如何使用的角度考慮每個系統,然後根據需要對它們的擴充套件機制進行定位。然而,要記住的是,選擇了上下文型的道路之後,其必將比組合型的方法在將來能夠以何種方式使用系統方面,具有多得多的限制。

你的 PaaS 是組合型還是上下文型?原文請看這裡

推薦文章