當前位置:
首頁 > 最新 > 精心布局的開源

精心布局的開源

這個世界每天都在變,開源已經不是當年 Eric.S.Raymand 提出的那樣了,和商業直接的關係越來越弱,中間所增加的間接環節,已經讓我們迷惑了。但總有人是清醒的,現在看來它就是人們精心布置的一個局,在雲計算的轉變過程中尤為明顯。

--適兕

致謝

編譯自 |

https://www.oreilly.com/learning/open-by-design

轉載自 | http://www.ocselected.org/posts/opensource/open_by_design/

作者 | Philip Estes, Doug Davis

譯者 | 適兕

這個世界每天都在變,開源已經不是當年 Eric.S.Raymand 提出的那樣了,和商業直接的關係越來越弱,中間所增加的間接環節,已經讓我們迷惑了。但總有人是清醒的,現在看來它就是人們精心布置的一個局,在雲計算的轉變過程中尤為明顯。

由開源和開放治理所帶來的雲計算的轉變

介紹

如果說軟體正在慢條斯理的將這個世界吃掉

[4]

的話,那麼我們可以毫不誇張的說開源軟體正在吞噬世界。現在的開源可不像十幾年前那樣——幾乎無人問津,現在則到處都在談論開源(對於入門者來說,看看講解 Linux 豐富的歷史吧),據統計,無論是社區參與、代碼提交行數,還是企業參與、乃至金錢的收入,都以驚人的速度上升。舉個例子,在2015年8月份舉辦的北美 LinuxCon 會場,Linux 基金會介紹說,僅僅是旗下的子項目就有六千四百萬行代碼的提交,這並沒有包括 Linux 本身!這些提交來自成百上千的獨立的貢獻者,從學生到服務於公司的工程師,據粗略的估價,這些代碼的軟體是已經超過50多億美元的項目。

雖然目前開源已經深入人心,但是我們這裡要探討的更加的耐人尋味,因為開源已經不再僅僅是指傳統意義上的將代碼倉庫公開訪問,以及以某種開源許可證來分發。開源還意味著由開放治理和合作基金會的管理,使得來自世界各地的開發人員能夠協同起來,一起解決來自圍繞雲計算的挑戰:從基礎設施服務,到平台、應用的打包,乃至日益擴展的 Web 產品的交付和運維。

這場開源的革命改變了人們的看法,也讓企業開始思考自己的軟體產品應該如何開發,尤其是企業為其用戶提供雲計算的解決方案時,這一影響更加的凸顯。我們發現在這個新的開放的時代,它本身就是在培養一種開放的思維以及開放的合作,目標人群是那些在自己的企業中已經習慣於封閉開發的擁有豐富經驗的開發者們,而且,我們現在越來越多的軟體的設計使用開放的原則,就雲計算具體來說,企業傳統的做法就是「自己滾起來」。我們稱這個新的時代為:精心布局的開源時代。

開源:歷史回顧

開源是什麼?

為了能夠充分的討論開源這個主題,我們首先需要做的是先澄清此一名詞的概念。首先我們會定義一個基準,然後,我們回顧開源的歷史,它是如何出現的?為什麼會出現?在此過程,我們會遵循在多個行業的開發過程和軟體領域中,以成熟的、可行的、有一定價值的組件來說明問題。

N.B.: Open 這個詞,確實是最近幾年變化非常大的一個詞,近來還讀了另外一篇文章Fifty shades of open

[5]

首先,開放源代碼促進會的開源的十個定義

[6]

對於我們理解起開源是非常有意義的。其中一個至為重要的真相就是說能夠訪問源代碼是必要的!但是僅僅是源代碼開放就說它是開源軟體是遠遠不夠的。正如開源促進會所澄清的,能夠訪問源代碼僅僅是入門級,需要進一步的能夠再次分發軟體,-原有的和修改過的-以及刪除了一些代碼的情況所造成的不同,乃至於不同的人們,如用戶和開發者。最有價值的或者是一文不值的開源項目在多個方面都會有摩擦,如代碼訪問、代碼共享、以及自由的使用和分發,允許任何人和任何組織去輕易使用和修改。

這就是 OSI 的定義所強調的一個關鍵的點。雖然有非常多的可用的開源項目,只是簡單的將源代碼放在了互聯網上,其實這是遠遠不夠的。特別注意的一點就是,很多的開源項目所使用的許可證使得很多的商業公司是無法參與進去的。這麼做的後果就是限制了一些開發者,因此,項目就需要更長時間來獲得增長乃至成功。舉例,某個項目要求所有基於其下的源代碼也必須再開源,這就意味著此許可證強制商業公司所開發的增值(可能是商業化的)必須是是自由可用的。對於一部分公司來說,顯然是接受不了這樣的許可證的。那些最為成功的開源項目都是實現了各式各樣的人們來參與到項目中來,並且會鼓勵採用貢獻者到技術,而不是去強制限制什麼。

除了能夠訪問到軟體的源代碼以及有權利去修改它之外,其實開源項目真正的價值並非代碼庫本身,開源項目真正的價值在於能夠在更加廣闊的範圍很多人為了同樣的目標一起協作形成的社區。一位形單影隻的開發者,即使是一家單一的公司,做了一開源項目,或許還有點實際的用處的,但若是沒有更多的參與者來改進他的代碼庫的話,項目很快就會變黃。眾人抬柴火焰高,有更多的人手來投入時間和資源來讓軟體更好的測試、更好的文檔、更加靈活的處理錯誤、添加更多的功能,從而滿足用戶的需求。原作者可能沒有注意到全部,但是開源真正的力量在於感興趣的人們花時間和專業技能來共同完善它,使之更快的成熟可用,甚至有些功能會超越原作者的意料。

大眾化和商業化

雖然我們可以肯定的說,現代的 GNU/Linux 和自由軟體基金會是推動著開源時代來臨的力量來源,從而讓軟體從受企業青睞、各種專利、以及過去的閉源的專有系統的反面的轉變。但還是有必要回顧一下開源軟體在整個計算機歷史的時間線上的位置的。

在20世紀5、60年代,很多早期的計算系統都是來自於IBM、DEC、以及其它一些學術界、研究機構合作開發的,甚至還有一些政府部門的參與。這就導致最初的操作系統軟體和其它關鍵的軟體組件假設是可以在用戶和開發者之間進行共享的資源,在計算機的歷史上,就這一點可謂是驚人的重複。早期的計算機系統供應商交付他們的硬體的時候,會順帶將全部的軟體的源代碼一起交付,這其中包括了可能需要修改以及構建軟體的工具。拿 IBM 701 大型機來說吧,這種特殊的源代碼共享的方式,直接導致 SHARE 用戶組以及研討會持續了幾十年!SHARE 是一個充滿活力的社區,系統程序員和用戶一起分享他們各自所遇到的問題,然後共享代碼,即那些修復問題之後增加或變更的代碼。

那個時候沒有高帶寬網路的普及,讓人們能夠在全世界範圍內輕鬆的溝通,幾十年以後才實現了。但是,這就是現在開源運動的根源:一個協作的社區,共享解決方案、源代碼、以及專業的知識,而無須考慮專利權、許可收入、各種金錢的收入。

好吧,讓我們還是快進吧,GNU 項目的創立以及自由軟體的想法從 Richard Stallman 頭腦中出現的時間是20世界80年代,沒有過多久,Linus Torvalds 在1991年開始了 Linux 內核的撰寫。這些里程碑的事件

[7]

,究其原因,有連接全球的越來越方便的網路、通過電子郵件來進行大量的溝通、早期的原始網站、放置代碼倉庫的 FTP 伺服器,所有的這些組合在一起,促使新的開發者們加入到開源運動的大潮中來。Linux 和 GNU 項目的各種組件為開源活動提供自由的底層,參與到開源所需要的所有的必要的工具——編譯器、編輯器、網路客戶端、以及腳本語言,都可以在一個單一的自由使用的操作系統中獲得,這一明顯的降低門檻的現象,導致只要擁有一台個人電腦就可以加入到開源的事業中來。

就在90年代中期眾多的參與者加入進來之後不久,此草根的開源運動中開始出現了一些嘗試盈利的商業公司,如—— RedHat、SuSE、VA Linux、Netscape(很快變為 Mozilla)、以及 MySQL AB等等。不僅僅是這些新成立的開源公司,而且那些大型的企業很快也看到了開源開發模式的價值,並且也積極的參與到開源社區中來,並且鼓勵員工全職為「上游」做開源的工作。IBM 就是在早期採用這一策略的大公司之一:在1998年成立了 IBM Linux 技術中心,僱傭 Linux 內核專家,以及培養內部員工積極的參與到 Linux 內核和其它上游的項目中,目標是讓 Linux 能夠在所有的硬體類型上運行,且能夠支撐IBM 中間件產品,IBM 專門為其下受歡迎的企業級產品—— DB2 和 WebSphere 開發了 Linux 的版本,甚至是過去專門面向大型機的軟體如 CICS 和 MQSeries。更多的大型企業也紛紛效仿:Oracle、HP、SAP、Intel、以及其它公司也開始直接支持 Linux,讓他們等軟、硬體開始支持 Linux 操作系統。開源不再僅僅是自由軟體運動的「次文化的產物了」(因為他們有時會被人嘲笑);它現在已經壯大,是幾十億的市場了。

相比於早期的企業參與到開源的那些日子,人們使用開源軟體和專有軟體或解決方案的混合,是一個從最初的忐忑不安到慢慢的適應的過程。但是在今天,你很難找到沒有使用開源軟體的地方,從移動設備、到嵌入式控制系統、再到企業級數據中心解決方案,開源軟體的大眾化和商業化的浪潮在我們寫這篇文章的時候仍然在加速發展。這一點在雲計算更加顯得特別,Linux 操作系統讓 web 擴展的計算資源成為可能,很多的開源項目也是雲計算的基石——從 Hypervisor 到基礎設施管理,再到部署,乃至應用程序層的框架。這些項目以及其背後的社區都是響噹噹的角色。其實,它們之中多數是通過基金會的所創建的開放治理社區。但是,在我們要談開放治理之前,我們還需要交代一件事,那就是開源將業界瓦解的歷史。

瓦解

不管它們是否能夠理解,當下大多數的消費者都在使用開源軟體。即使消費者僅有一點點的技術意識,也會在不知不覺中受益於開源。這些最終用戶獲益的最大的來源就是通過面向消費者的設備實現的,從 GPS 單元、到家庭無線路由器、再到諸如 Roku 和 Chromecast 這樣的流設備。作為開源項目最好的案例-Android ,每天全球有幾十億用戶通過智能電話和平板電腦在使用它。即使是在個人電腦上的商業操作系統之中,人們也在使用諸如 Firefox 和 Chrome 這樣的開源項目,而且是與日俱增。讓我們從個人用戶往後推點,看看託管供應商,Apache web 服務仍然是 web 伺服器的老大,儘管現在有了新的競爭對手-Nginx,但是 Nginx 依然一款開源的項目。在 Web 的內容方面,我們必須得提一下非常流行的內容管理系統 WorkPress,開源的內容管理平台,每天承載著上百萬的博客提交和撰寫,其中多數的人們對於平台之後運行的開源一無所知。

基於這樣一個常識-開源軟體幾乎滲透於軟、硬體的各個系統的層次!讓我們回顧一下在過去的15年,開源是如何逐個瓦解各個關鍵領域的。

伺服器操作系統

在 Linux 到來之前,伺服器操作系統是被 Windows 和一系列的商業 Unix 所瓜分的。即使是在 Linux 剛誕生後的早期,企業界的客戶仍然是不願意採用這個羽翼未豐的操作系統,那怕它是「免費的」。當然,後來所發生的事情就是,Linux 的生態系統迅猛成長,一些公司開始提供企業級的發行版以及相應的支持,市場的份額也迅速的發生了變化。在2007年底,IDC 調查稱,Linux 終於在單一季度內打破了 20億美元的瓶頸,已經是所有伺服器收入的12.7%。在2012年這個數字逼近17%,但是到了2012年第一季度,Linux 已經佔據伺服器市場的20.7%,這已經超過了 Unix 的18.3%:

在八月份舉行的 Linux 基金會研討會上,IBM 副總裁 Brad McCredie 大聲疾呼,這是 Linus Torvalds 在20年前創建內核項目是絕對沒有想到過的事情:

他說道「在伺服器操作系統這塊市場中,Linux 已經超越了 Unix」

[8]

讓我們將視野調回到超級計算機上,我們可以非常明顯的看到這塊從 Unix 向 Linux 的轉變。如下圖所示,請注意,從2000年到2010年 Linux 佔有 TOP500 超級計算機的操作系統份額從不到5%增長為接近90%!非常明確的一點就是,開源的操作系統為研究者和硬體設計者們帶來強大的力量-對硬體加速功能的快速創新、自我定製設備驅動程序、和加強內核技術以便快速的看到原型、得到基準、然後來提高高性能計算的負載。順帶提及一點的,就是 IBM 也在 Linux 的投入上加大力度,開始讓 POWER 架構 和 z system 大型機平台支持 Linux,為其企業用戶提供一體的服務,包括傳統的強大的硬體以及 Linux 的靈活。

server os

在近期2014年底的報告中,IDC 繼續報到了 Linux 每年的收入和伺服器出貨量。但看 Linux 2014年的世界範圍內的出貨量一項,Linux 的份額就達到了40%,以每年16.4%的速度增長,比它情況好的仍然是微軟的 Windows,佔有59%,同比下降4%。比較有趣的一點是,不看世界單看美國在2014年的出貨量的話,Linux 的增長率和 Windows 是很接近的。分別是48.7比50.3%

[9]

雖然我們看到的是 Linux 在伺服器操作系統這塊市場的破壞性的成長,但是伴隨著它的成功,它同時也打開了其它無數的開源的市場。我們還會看到,值得尊敬和長期堅守的開源項目在世界範圍的被廣泛使用。

Web 伺服器

在 Web 的早期階段,對於 Web 伺服器軟體的選擇非常的少,在公共領域由 Rob McCool 開發的NCSA

[10]

其實是事實上的標準。在上世紀90年代中期,微軟在其 Windows NT 3.51 上開始提供一款叫做互聯網信息服務(IIS)的 Web 伺服器,大約在同一時間,Apache 的開源 Web 伺服器項目也誕生了。Apache 是基於 NCSA 伺服器的基礎之上開發的,因為 NCSA 在這個時候已經被叫停開發了,不再維護了。除了公開代碼之外,Apache 項目的意圖是希望通過有興趣的人們一些協同開發,隨後最初的8位貢獻者組成了 Apache Group,沒過多久就有了很多的追隨者。

在接下來的幾年裡,Apache Web 伺服器的開發進展良好,功能漸趨完善,可擴展的架構帶來更好的移植性,而且可以跨各種 CPU 架構的硬體上以及多種操作系統中運行。在1999年,Apache 軟體基金會正式成立,這讓早期的開發者們有了可持續的資金收入、治理方式、以及管理和法律等方面的幫助。該基金會很快變發展了很多的開源項目,而不再僅僅是一個 web 伺服器了。

到今天,Apache 已經是託管互聯網站點最為流行的 web 服務平台了。下圖展示了 Apache 在 web 伺服器領域的霸主地位。它已經堅挺了20多年!

圖片來源:Netcraft

[11]

既然談到了 Web 伺服器,筆者認為還是有必要再多說一點,讓我們再看一張近幾年 web 伺服器統計的圖片。可以看到在此市場中有了一個新生代的挑戰者:nginx!

圖片來源:Netcraft

[12]

限於篇幅和為了節省大家的時間,我們對於所有的流行的 web 相關開源軟體項目是如何成為互聯網的核心和靈魂的故事就不鋪開來講了。不過值得一提的是 Linux 和 Apache 的組合是術語 LAMP 軟體棧的基礎。其中M表示的是非常流行的開源資料庫 MySQL,而P則代表的是 PHP,PHP 是一種用於編寫 Web 應用程序的語言,不過最近有被另外一個新崛起的叫做 Node.js 的項目替代的趨勢(Node.js 也是一款開源的項目,而且目前也成立的相應的基金會)。

移動設備

在講述完伺服器和 web 技術領域了之後,我們要進入關於移動設備的世界了。在移動設備爆炸的今天,要探究最初,就得追溯到2007年,即最早引入「智能手機」的年頭。那年有兩個重要的事件發生:Apple 推出基於 iOS 的 iPhone 手機 和Google Android OS 引入移動設備的誕生。到今天, iOS 和 Android 均有各自的支持者,也一直在辯論著哪個「更好」!但是結果非常的明確,那就是開源項目勝出,Android 在手機、平板、和其它設備上跨多個製造商構建了一個強大的生態系統。由於這是一個非常廣闊的市場,即使是看起來 Apple 的收入更高些,但是從全球的手機交貨量來說,是 Android 勝出:

圖片來源:IDC 數據

[13]

鑒於 Android 相比於 iOS 更加的傾向於低成本和入門級市場,這樣的數據顯示,沒有什麼令人值得驚訝的,還有更為細粒度的數據顯示,在印度、中國等主要市場,iOS 和 Android 的出貨量比例是懸殊很大的。

虛擬化

在1999年 VMware WorkStation 出現之前,軟體 Hypervisor 早已存在了好多年了,但是是作為那些非常昂貴的企業伺服器的一個部分存在的,即那些如 IBM、HP、以及 Sun 的大型機,工作在這裡的工程師們從來沒有想過有誰能夠改變他們的職業生涯。然而,當 VMware WorkStation 出現以後,這一切都改變了。在任意的筆記本或個人電腦上的 Windows 系統中可以看到 BIOS 的啟動!這是多麼的令人驚奇和興奮!在接下來的十多年,虛擬化都是炙手可熱的技術點:不僅僅是因為它能夠輕鬆的將原來物理伺服器轉換為虛擬機,使整個的應用更加的容易備份、配置和遷移,還有它能夠在同一台伺服器上將大型的不同的負載完全的隔離起來的全新方法,而這是數據中心運維模式的巨大轉變。

從VMware 發布 WorkStation後,沒過多久,開源社區在虛擬化這一領域也有了新的突破。Xen Hypervisor 在2003年橫空出世,它為Linux提供了半虛擬化的內核;加上 QEMU 模擬器軟體的搭配,形成了完善的虛擬化解決方案,而且它還在不斷的發展,新的功能和特性與日俱增,如提供非 X86 架構,例如 Power 架構,如 ARM。或許讀者你對老牌的公有雲提供商 亞馬遜 web 服務(AWS)非常的熟悉,這家公司就是在2006年開始為用戶提供虛擬化的計算能力的,但是你可能不會知道,AWS 運行虛擬機使用的技術就是 Xen Hypervisor!

在開源界還有另外一款 Hypervisor,在十多年前,一家名叫 Qumranet 的以色列創業公司,開發了一款基於硬體虛擬化的 Hypervisor,它就是後來大名鼎鼎的 KVM。利用 Intel VT-x(或 AMD-V)的硬體輔助虛擬化技術。KVM 在2007 被合併到 Linux 內核;2008年紅帽又將 Qumranet 收購;在那之後,KVM 迅速崛起,很多發行版都開始支持它,成為了主流的 Hypervisor,而且也是很多企業級 Linux 的虛擬化產品,諸如 紅帽企業級虛擬化(RHEV)、IBM 的 PowerKVM等。(PowerKVM 是基於 IBM Open Power 硬體平台的,操作系統為 Linux)。

雲計算

軟硬體的虛擬化技術的成熟是雲計算之所以能出現的關鍵,從近幾年來看,這是一個快速創新的領域,並且是各種投資市場所青睞的對象。幾乎所有的廠商,包括硬體和企業 IT 均競相在私有雲、公有雲、以及混合雲尋找機會和作出變革。

儘管在雲計算這塊依然有專有的廠商,但是我們在今天所看到的是,有無數個開源項目在這個領域扮演著重要的角色,並展開了整個雲計算的創新。而且那些專有廠商也開始往開源這邊傾斜,有時候在純粹的開源項目和專有之間並沒有那麼清晰的界線。正如我們看到一直在 IT 市場上扮演專有廠商的微軟近來也開始擁抱 Linux,稱他們在 Azure 雲中可以託管 Linux 虛擬化,無獨有偶,微軟近來還投入人力到 Docker 這個開源項目的上游社區中,試圖將容器技術帶入到 Windows 伺服器版和 Azure 雲中。

從本質上說,正如 Cloud Foundry 基金會的執行總監 Sam Ramji 最近的結論:「開源已經贏了!」 現在想從任何一家雲計算廠商中找到沒有開源項目的組件,那真是太難了。無論是 hypervisor、託管操作系統這個層、還是應用程序的運行層、如 Node.js、PHP、Ruby、Python 等開源項目的例子。

我們今天所看到是開源的復興!其中,很多圍繞雲計算的關鍵活動和創新都是通過開源社區和它們各自的基金會來進行的。有三個社區值得我們拿出來仔細的研究,因為它們是對大型的 IT 企業的 IaaS 和 PaaS 實現產生了非常大的影響,即 OpenStack、Cloud Foundry、以及 Docker,這三家均擁有龐大的開源社區力量並且仍然在快速的增長,每年所舉行的研討會都有成千上萬的人參加,有著足夠的聚光度,媒體紛紛報道,而且還有來自所有的大型 IT 企業作為合作夥伴和支持者。在下文的開放治理:基金會模式中我們將開始探討基金會模式作為開源振興的關鍵點來切入,看它是如何影響我們前面所提到的這些社區以及歷史上大型的開源項目的。

開放治理: 基金會模式

超越開源

我們已經看到開源不再是被孤立的集體或與世無爭的了:開源的商業化和普及化引來了一些公司和大企業的投資和參與。但隨之而來的問題就是,在這些項目中商業化和社區的興趣之間的衝突日益的計劃,儘管開源有太多精明的參與者。

在開源和商業利益的十字路口,問題日益嚴峻的是有關權威、真實性和文化的問題。 –Nathen Harvey, Information Week

[14]

Nathen Harvey 在Information Week中的文章中指出了三個問題:「項目應該由商業的贊助商驅動還是外圍的貢獻者驅動?商業利益是否應該凌駕於社區的意願之上?該如何以及在哪裡為商業實體和開源社區之間划上一個明確的界線?」

這三個問題確實是異常的尖銳,回答起來就顯得非常的關鍵,但通過基金會的模式,開放的治理可以解決大多數的問題。

不過,首先還是讓我們來了解一下開源軟體世界的基金會的歷史和崛起,這將更加的有助於我們的理解。

基金會的崛起

讓我們先來看幾個較為著名的基金會,以及在特定社區所扮演的角色。通過對這些基金會的快速遍歷,希望可以更好的理解他們,看他們如何通過開放基金會的模式來分享願景以及是如何開展工作的。

Apache 軟體基金會

Apache 基金會(ASF)創立於1999年,創立時主要的工作時圍繞 Apache HTTPD web服務的項目進行開發、資金和治理的協調工作。發展到今天,ASF 已經是世界上最為著名和成功的託管開源項目的基金會之一了,在它的管轄下有超過300多個項目。ASF 通過定義法律和協作框架來為開源項目託管和協作開發鋪平了道路,現在已經是基金會的標杆,很多後期的基金會都在效仿 ASF 的做法。舉例來說,Apache 許可證,Apache 旗下所有的項目都是使用的 Apache 許可證,同時也是今天很多項目使用及最受歡迎的許可證之一,當然這不僅僅是指在 ASF 的託管之下的。儘管 ASF 最初是從項目 Apache web 服務起家的,但是經過了這麼多年的發展,ASF 已經在項目上覆蓋了很多技術,有編程語言、雲計算平台、甚至還有辦公效率套件。

ASF 採用的是精英主義路線,所有的事項都是通過受歡迎的社交技術——公開的郵件列表、WIki、代碼倉庫等來進行的。有一些 ASF 下所開發的項目成為了非常受歡迎的項目,甚至成為了事實上的標準,但是 ASF 本身並非是一個制定標準的組織,而且也不會像 W3C 那樣的組織去專門的制定、生產標準。

Linux 基金會

Linux 基金會在2007年成立,由原開源開發實驗室(OSDL)和 自由標準協會(FSG)合併而成。目的是提供發行版中立的發展和加強 Linux 操作系統及其相關的技術。據其官方網站

[15]

的說法:

Linux 基金會旨在保護和激勵自由的理念,通過 Linux 開發來加強合作。而且要分享這些理念來加強和鞏固,目的是讓我們生活的地方未來更加的美好。

Linux 基金會最初成立的目標之一就是為 Linux 的創始人不受任何廠商的影響保持中立,因為這些廠商可能會影響內核開發的優先順序。這個規定在今天仍然生效,即使是有了諸如 Linux 內核維護人 Greg Kroah Hartman 這樣受雇於 Linux 基金會的人的參與。除此之外,Linux 還旨在推動 Linux 全球會議的管理、保護 Linux 的商標、以及處理法律和許可證的問題、並且還會在規範上出一把力,如 Linux 標準工作組制定的 Linux 標準介面。

Linux 基金會合作項目

和 ASF 類似,伴隨著 Linux 基金會漸漸的成熟,也開始孵化一些和 Linux 相關的開源項目了,但是項目並不會特定於和 Linux 操作系統開發有關。通過合作項目的促進,已有的 Linux 基金會流程,管理員支持,以及可以直接利用的治理程序,可快速而有效的生成新的合作項目。近年來,Linux 基金會合作項目的名單日益漸長,其中包括開放大型機項目、汽車應用,乃至現在的雲計算平台項目諸如 OpenDaylight、OPNFV,以及 Cloud Foundry 基金會、開放容器促進會、雲原生計算基金會等。

為了能夠更為透徹的了解在雲計算的世界這些合作的項目基金會究竟又何特別之處,讓我們來一同探究一下近來進入 Linux 基金會合作項目羽翼之下的四個子基金會。

Cloud Foundry 基金會

Cloud Foundry 是一款提供 PaaS(平台即服務)環境的開源項目,PaaS 是可以為開發者有效的提高交付應用的能力,而且還是跨範圍的運行時環境的,從 Java 到 Node.js 再到 Python、Ruby、PHP、乃至於 基於 Go 的應用。Cloud Foundry 最初是由 VMware 發起的項目,後來交付給了有 VMware、ECM 和 通用電氣 聯合成立的新公司 Pivotal 軟體全權接管。

當 Cloud Foundry 成為 Pivotal 的一個開源項目時,Pivotal 則基於開源的代碼庫來為客戶提供免費的和商業的產品。很明顯,Pivotal 是控制著項目和社區的。為了解決這樣的一個單一廠商控制的局面,在2014年12月成立了 Cloud Foundry 基金會,隸屬於 Linux 基金會合作項目成員,這個新的組織目的是防止有那個單一的廠商將項目控制,而且將 Cloud Foundry 轉變為一個真正的開放治理模式下的項目。

開放容器促進會

我們將會在開放雲的合作一章更加詳細的談論開放容器促進會(OCI),但這裡必須提及的一點是OCI是託管在 Linux 基金會合作項目之下的。在2015年6月,OCI 的組建就是為了讓應用程序的容器化在兩個競爭的運行層面標準化和協調性。眾所周知,Linux 容器在過去的幾年裡可謂是非常火的技術,這一切都得歸功於 Docker 在應用程序容器運行時和生態環境的構建和實現。但是這裡面,有一個現象值得大家注意下,那就是 Docker 是近年來才出現,並段時間崛起的技術,但是稱之為 Linux 的核心技術之一的 「容器」已經出現了十多年了。隨著容器技術的不斷升溫,Docker 也開始有了一些批評的聲音甚至出現了強有力的競爭者。在2014年12月,CoreOS,一直以來都是 Docker 的盟友,發布了容器的運行時環境——Rocket。OCI 的設立就是協調這兩個競爭者的規範和實現,即 Docker 所提交的libcontainer,也就是 Docker 的核心容器運行時組件;和 一個新的用戶運行時環境,名稱叫做runC,基於規範的實現,是 OCI 治理和控制的。

目前來說,OCI 仍然處於形成階段,但是不論是 CoreOS 還是 Docker,(甚至是 Google、紅帽、IBM、華為、以及其它)均是最初的創始成員。目標都是為最終用戶建立一個可移植的、標準化的運行時的規範實現,共同構建容器創新的生態環境。

Node.Js 基金會

在2009年由 Ryan Dahl 和他在 Joyent 的工程師團隊所發明的 Node.js,在短短的幾年證明了這是一個用於 web 應用程序開發的服務端,基於 JavaScripts 語言實現。Node.js 從誕生之日起就是開源的項目,許可證協議採用的是 MIT 許可證。Joyent 引領此項目的開發好多年,從最初的僅支持 Linux 平台下,最後移植到微軟的 Windows、Apple 的 OS X、乃至於如 IBM Power 和 Z 系列的架構平台之上。在2014年末,Joyent 的治理下開始出現了一些分歧,有一部分工程師開始以全新的分支——io.js,這對於 Node.js 可謂是一件不好的事情,io.js 的發布周期短時間就擁有了更多的用戶。

在2015年2月的 Node.js 研討會上,有人提議需要一個廠商中立的基金會。沒過多久,在那個夏天來臨時,Node.js 和 io.js 兩個項目宣布合併,成立 Node.js 基金會,放在 Linux 基金會合作項目之下。就這點來說,Node.js 基金會可謂是開放治理模式的成功典範,是廠商中立的基金會實現。和其它我們討論到的其它基金會相類似,它會採用業務(董事會)委員會混合技術指導委員會的方式,而後者則是技術決策的精英主義。

node.js 基金會有6位鉑金創始,其中也包括了 node.js 的創始者——Joyent,以及16位黃金和白銀成員。Node.js 基金會致力於為其開發提供嚮導,希望node.js 能夠在迅猛的發展道路上穩步前進。

雲原生計算基金會

我們在前面討論過的 OCI,是針對應用容器化的底層的運行時的規範所成立的組織。但是越來越多的雲廠商開始意識到 OCI 的工作還遠遠不夠能涵蓋所有的一切,雖然對於基本的單個容器運行時很重要,但是更高級別的管理結構也需要一個全行業的標準。在2015年的8月,仍然是在 Linux 基金會的合作項目羽翼之下,成立了雲原生計算基金會,在本文寫作的時候,CNCF 的工作確切範圍仍在商討中,但是已經聚焦於數據中心內的容器集群的編排、分發、發現、以及生命周期管理。這些技術的集合統稱為「數據中心操作系統」(DCOS)。

和 OCI 一樣,CNCF 也會採取代碼加規範的做法,在開發 DCOS 架構規範的同時會實現它。目前,Google 的 Kubernetes 和 Apache Mesos 項目已經開始討論實現 CNCF 的規範。

和 Node.js 基金會類似,CNCF 是由一些雲計算業界的幾家企業共同發起的:在本文寫作的時候共有22家公司支持CNCF,其中包括一些大型的企業諸如 IBM、Intel、Huawei、Google以及 AT&T等。這裡有一個有趣的現象。我們已經能夠看到開源和開放治理跨界的合作,在雲計算的環境中,在支持的成員公司中還包括 Docker、Cloud Foundry、Weaveworks、以及 CoreOS——所有的這些公司都是開源項目,都對於雲計算的未來編排和管理有著合作的意願。我們將會在後面的章節中接著討論這點。

OpenStack 基金會

OpenStack 項目發起時間是2010年,由 NASA 和 Rackspace 聯合,目的是想為數據中心的基礎設施管理創建一個可編程的、基於 API 的 IaaS(基礎設施即服務)層。在2012年又有很多廠商參與進來,這時並一起創建了 OpenStack 基金會,也就是現在運營著OpenStack項目開發的法律、技術和行政治理。

OpenStack 項目最初是致力於計算、存儲和網路資源的管理,但是隨著項目的成長,包含了大範圍的 IaaS 相關的項目,每個項目都有特定的名稱;最初均是處於孵化,一旦成熟之後就會進入 OpenStack 官方的半年發布一次的版本。目前,2015年發布的 Liberty 版本有 16個獨立的子組件交付。

(N.B.:譯者註:翻譯本文的時候,OpenStack 已經發布 Mitaka 擁有19個子項目

[16]

。)

基金會本身由多個社區組成,有運維、有用戶、也有開發者社區,以非常健壯的治理模式快速的成長著,治理模式有各自的章程,用於指導其管理和開發的流程。並由董事會和技術委員會進行監督。OpenStack 現在擁有8家白金贊助商,(對應8位董事會的代表)17家黃金贊助商,以及120家企業贊助商。

若是沒有這樣的正式的治理和開發流程,就不會有如此多的雲計算供應商一起工作在 IaaS 層和 API。但是有了基金會的結構,一些公司,諸如 IBM、HP、RackSpace、Intel、以及其它共同協作來開發核心的技術,然後再去基於 OpenStack 平台之上創新和差異化自己的產品,我們會在本文後面花筆墨講解更多的這樣的合作,以及「合作競爭」的模式。

其它開源的基金會

限於篇幅和時間關係,我們無法做到涵蓋所有的開源基金會,以及他們所支持的開放管理和相關的流程,以及圍繞和商業的合作等等。但是,仍然有一些事值得我們為之寫上他們的名字的,正式因為他們,才能夠讓整個的開源更加的健康。他們有:

? 自由軟體基金會(FSF)

? Creative Commons

? Eclipse 基金會

? Internet Systems Consortium (ISC)

? Mozilla 基金會

? 開源促進會(OSI)

? 軟體自由法律中心(SFLC)

還有我們無法在這裡一一列出的,他們都在相應的開源項目和促進中扮演著各自的角色,尤其是在商業和獨立興趣之間的平衡。

「其它」的開源:開放標準

在我們結束討論開源和開放治理之前,還有值得一提的就是,在開源軟體項目中目前還有一股商業參與的潮流,很多的業界公司都在使用非源代碼的基礎來實現類似的廠商中立的合作,通過使用標準來達到合作的競爭。

若想忽略掉軟體產業,哪怕是一小會,只需要簡單想一下你每天的日常生活即可,你會發現非常多的例子,如企業、某些情況下的政府機構等,他們會聯手創建一些標準的設計或組件,這對於所有人都是有好處的——無論是作為生產者,還是作為消費者。這些標準或者是標準的設計,例如 USB 埠 或國家的插頭類型等,是產品在一定程度上能夠達到製造廠商之間的互操作性、可移植性、以及重用性。商定的標準仍然允許基於這個共同的基礎之上進行開發創新和突出個性;每個製造商或生產商都可以通過一個共同的標準來受益。

在軟體的世界中,我們依然能夠看到這種合作競爭的局面。舉例來說,這如原先所提到的一樣,Apache web 服務通過開源項目的合作取得了巨大的成功,但是Apache的項目最初並不是在web 服務的核心技術上去創建一個共享的標準;更確切地說,它是關於使用源代碼作為協作的基礎。還有一些組織,諸如 W3C(由著名的萬維網創始人 Tim Berners-Lee 在1994年創立)和 IETF,IETF 創建的初衷就是開發協議的標準,是今天互聯網能夠成功的的重要基石。但是這些標準若沒有諸如Apache這樣成功的項目就不能實現。

這些標準的成員是由組織和公司組成的,他們一致的認為沒有這些跨越計算機和人溝通的協議的話,互聯網是不可能發展起來的。舉例來說,想像一下沒有 HTML 標準的 Web,每個站點都是以自己的語言來實現的頁面布局!互聯網——尤其是 Web,作為接近無限的資源,輕易可獲取的信息,——我們今天所擁有的一切也就不存在了,這都得歸功於多年以前所建立起來的核心標準。

即使是在今天,開放標準仍然在業界佔有舉足輕重的地位,當然變化還是有的,我們已經看到從過去的「on-paper-standard」轉變為以代碼為標準或者是參考實現的規範,我們前面討論過的開放容器促進會即是很好的例子。鑒於這種變化,我們發現,負責開放源代碼項目的開放基金會的模型是未來工作的一個更令人信服的模型。當然,未來的雲計算的活動會由新的開放標準來保駕護航,然後在以開源的方式實現,但我們相信,這將是由供應商中立的行業聯盟領導的情況下,逐案決定,為開放標準和開源軟體再次提供一個公平的競爭環境。

開放治理:合作的重要性

在本章的開始我們考慮了在開源軟體項目中商業參與相關的重要問題。正如我們已經檢驗過的通過基金會模式的開放治理實現那樣,我們注意到了,開放的治理實踐回答了有關開源中的影響、所有權、領導力、以及制定決策。每一個項目都會在獨立和商業貢獻者參與的糾結成長之路,我們相信通過廠商中立的開放治理,能夠打造一個精英式的技術開發實踐,都會讓開源作為事實上的開發模式而持續有力發展,無論對於商業的還是非商業的實體。

在接下來的一章,我們會更加的實際一些,來看利弊之處,社區如何運營、並舉例說明和指導在開源的革命的實現飛躍,儘可能的包含到在未來可能會計劃啟動一個合作的項目的細節。

開放雲的合作

鑒於我們之前所討論過的有關開源的流行和商業化問題,我們知道在可預見的未來合作和競爭將會共存。我們也過了一遍幾家基金會,他們都成功的讓很多公司和獨立成員共同遵守精英式的開發、技術規劃、以及決策的模式,帶來了廠商中立的競爭環境。在這一章中,我們會更加詳盡的去了解關於雲計算開源項目成功的指標。我們也會儘可能的為未來的項目提出嚮導性的建議,當然這均基於我們在深挖過去的和當下的、成功的和不成功的開源項目和標準的時候所證實的。首先,我們來總結一下上一章看到的治理模式。

通過開放治理促成的成功合作

「是什麼成就了優秀的治理模式?」 這是一個讓我們竭盡全力去努力回答的問題。通過研究過去和現在都很成功的項目——舉例,Apache 軟體基金會或 W3C —— 我們發現了一個通用的有關項目的文化的關鍵的方面,即「透明度」:無論是人員的組織,還是管理和開發的流程。「透明度」在此上下文中有多種不同的涵義,舉例如下:

? 社區的運營是否支持這樣的一種方式:哪怕是來自社區外部的人們都可以關注社區的討論和進度?舉例來說,所有的文檔(會議時間、問題列表、未來工作項等等)都會在網站上讓人們訪問,而且是以非常快捷、方便的方式。

? 是否歡迎來自社區外部的成員?是否針對成員和非成員的反饋、提問、以及建議提供相應的機制?

? 是否提供知識產權機制來鼓勵分享想法?很明確的是,有一些開源項目的許可證是對於商業公司產品中使用是提出挑戰的,反過來的話,如果有知識產權政策並不要求貢獻,而是由社區自由自配並可重複利用,(沒有,舉例如支付特許權使用費),然後嚴格限制交換想法,這麼就可以說社區成功了。

可以確定的是治理模式可能會包含成員的不同的等級制度(舉例如根據年度貢獻),必須保證所有成員擁有平等的機會獲得晉陞的公平流程。舉例來說,如「付錢玩」的模式,其中一個公司可以通過簡單地寫一張支票獲得了關鍵的領導作用,傷害了組織的感知客觀性。通常,對於技術社區領導力來說,優點/貢獻模型的效果最好。在眾多我們所覆蓋的開源項目中,只有那些提交了顯著數量的有意義的代碼的貢獻者方會被認為是代碼的提交者、審核者、或者是維護者等角色。

我們還注意到了,一個活躍的、開放的、友好的社區是項目極為重要的部分。成功的項目能夠利用到我們前面所提及的要創造一個能夠對新老成員一視同仁的公平環境。一個老的成員如何對待新進成員是衡量一個社區是否開放的重要標準。肯花時間去回答「菜鳥」的問題,而且會幫助新手們對於開發步驟、初始提交變更中的任何相關問題,而且也樂意幫助社區的成長、希望社區的成功,這樣會鼓勵更多的開發者,並因此而獲得更廣泛的專業知識和貢獻。隨著一個項目的成熟,我們注意到,現有的開發人員傾向於開始更具挑戰性的新任務,因此,能夠讓新進社區的人絡繹不絕是一個項目保持健康和成功的重要因素。如果讓感興趣的新人感到沮喪或被忽視,那麼他們就會傾向於去尋找能夠讓他們覺得舒服的環境去付出時間和努力。

案例:封閉標準以及私有的API

在本小結中,我們來簡要的看兩個反例,這絕對是開源和開放標準治理模式的反其道而行之道典範,也是真正的開放協作的雲項目失敗的典型。

封閉標準:雲基礎設施管理介面

我們已經花了太多的時間和筆墨來討論開源項目和開放基金會了,僅僅簡單的提及了一些基於非代碼的合作,諸如 W3C 的」Papaer 標準」工作。其中一個雲計算的例子就是雲基礎設施管理介面(CIMI)。這樣的一組關於雲計算的規範正是在 DMTF 的主持下開發的,意圖是將 IaaS 的用於管理虛擬化的資源 API 給標準化了。

CIMI 的成果代表了傳統的標準開發方式,由一些開放的組織和過去的團體來具體制定。雖然這些機構的標準,比如 POSIX ,在今天依然是有很高的價值的,在大多數情況下他們的工作是在私下完成的,成員付費,並沒有開放給公眾來監督。他們所進行的討論是不透明的,沒有郵件列表、沒有缺陷跟蹤、也沒有功能特性計劃。雖然 CIMI 的規範也有幾個業界的主要廠商參與進來了——比如 IBM 參與的CADF

[17]

規範工作,結果是它被 OpenStack 的審計和日誌功能所採用,即它們使用的標準 CADF 消息格式——他們通常會集中在「規範第一」的方法。雖然還能體現一點點價值,但是這些規範的開發是沒有考慮到實際情況的場景和實現的,而且會忽略掉那些沒有付費的提供的有價值的部分,以及開放社區的專家們:普遍在開源界的 「多隻眼睛」 所看到的。

非常遺憾,這就意味著所開發的參考實現嚴格限制了測試規範的目的,並且和真實世界中的軟體系統沒有關聯起來。這也就是說此規範是——憑空想像來製造的——無法滿足最終用戶和運維人員的需要,這更加的證明開放的和透明的社區開發出的開放標準或開源實現更具優越性。

CIMI 的規範制定工作仍然在進行中,目前有多少雲計算的社區採用了它還不得而知。由於DMTF天生就是創造規範的,但是其缺乏一個類似開放社區的反饋閉環,雲計算產業作為一個整體都在向標準的 IaaS 層 API 傾斜,比如 OpenStack。

私有 API:Eucalyptus

Eucalyptus 是在2008年就發布的一款開源項目,那時還是第一款 IaaS 平台的開源版,在當時的一段時間,還算在雲計算社區,獲得了一定的發展。但是,現在再看,Eucalyptus 在社區幾乎無人問津,在2014年被當時還沒有拆分的惠普收購。我們無法得知為何 Eucalyptus 在 IaaS 項目中失敗的全部原因,但是我們從一些事情上是可以看出一些端倪的。

首先,Eucalyptus 是特別針對兼容亞馬遜的 IaaS 雲產品——AWS 而寫就的,其是直接實現了亞馬遜的雲 API。鑒於 AWS 作為公有雲市場的領先地位,它似乎有可能成為替代基於亞馬遜託管的解決方案的不錯的選擇。這個API的一致性將允許通過 Eucalyptus 私有或內部部署雲的實現,將和市場領先的AWS公共雲的用戶完全兼容。然後,我們可以注意到此方法有兩大問題。第一,作為一個和 AWS 兼容的解決方案,Eucalyptus 就得推遲自己的設計、功能集、以及潛在的成功趕上亞馬遜 AWS 雲平台——AWS 的功能可謂是日新月異(也就意味著更多的API),這也就意味著 Eucalyptus 將永遠是以「追趕」模式來嘗試迎合亞馬遜隨時心血來潮的功能和API的變化。Eucalyptus 等於被亞馬遜牽著鼻子走。

另外,或是是更為重要的,亞馬遜的 API 和雲基礎設施的管理是閉源的、專有的實現。亞馬遜對其 API 並未提供任何的許可指導,這就留下了對於其它公司是否可以自由的實現其 API 集的法律風險,Eucalyptus 依賴於 AWS 的API 能力,將其作為核心,也是唯一能夠為最終用戶提供的,這可能是一個危險的勢頭。雖然我們也看到其它的開源 IaaS 項目提供 AWS 兼容的API,但它們通常也只是兼容可用,而且可遷移,還不是為最終用戶提供的核心功能。

綜上所述,Eucalyptus 的案例告訴我們應該注意到,作為一個開源項目不應違反事實——只能作受限的合作活動,以及近乎為零的開放治理,還是圍繞這一個封閉的、單一廠商 IAAS API 去實現的。我們暫時不去考慮 Eucalyptus 在雲計算的世界中受到的其它影響,我們至少可以明白,一個開源的雲計算需要跨整個生態系統來進行開放的協作和開放的治理——從 API 的定義再到實現——應該提供更加友好的,廠商中立的社區,方能吸引到更多獨立的個人貢獻者和公司參與,從而產生更大的動能。

案例:開源構建的開放雲

在看完兩個有關開放協作和開放治理模式的反例之後,我們該重溫一下我們在第二章所討論的基於基金會的三大主要的雲計算開源項目了,所有的這三個項目—— OpenStack、Cloud Foundry、以及 Docker——均擁有大型的社區,由眾多的參與者,都是開放的生態系統,完全實現或者是正在進行中的開放治理,在現實的世界中影響力正在增長,從創業公司到大型企業,整個如此的跨度都可以提供生產就緒的雲計算產品。

OpenStack

正如我們在上一章,開放的治理:基金會模式,所提到的,OpenStack 已經是一家大型的、快速成長的開源項目,主要的目的是提供一個全面的 AIP 和 IAAS 層的雲計算技術棧的實現;它主要集中在計算、存儲、網路等資源的管理上。OpenStack 基金會成立的目的就是對 OpenStack 項目承擔起管理和推廣、責任治理、商標和法律監督等。

但是值得注意的是,雖然 OpenStack 受到廣泛的業內支持以及很多頂級供應商的支持,其開放源代碼所實現的 API 規範(它是以 OpenStack 獨特的模式「blueprint」開始的)並非是按照傳統意義上的「paper 標準」去實現的。因此,額外的規章制度的變化,以及伴隨著新的項目的增多和成長,OpenStack 基金會在應對供應商之間的互操作性實現顯得非常的乏力。RedStack 社區項目和 Defcore 委員會就是為了補救 OpenStack 的情況而成立的,若是供應商有意使用 OpenStack 的商標和兼容性認證的話,它們通過提供測試套件以及要求「核心」軟體代碼的實現的驗證。雖然這種方式在如此巨大而多樣的社區會遇到各種坎坷,但是 OpenStack 基金會的治理和精英化的發展模式為社區的積極的協作和發展途徑提供了一個堅實的框架。

OpenStack 在很多方面還顯得有些稚嫩,但是隨著基於 OpenStack 的雲計算平台的增多,以及來自諸如IT大鱷 IBM、HP、Rackspace、華為、和思科(Piston)等重量級公司的參與,按照其目前的成長勢頭,勢必在將來的一段時間內在開放雲協作方面顯示它舉足輕重的作用。

Cloud Foundry

Cloud Foundry(CF)開源項目為用戶提供了 PaaS 環境,致力於為應用程序的開發者們提供能夠掌控運行時參數、可擴展性、應用的生命周期的部署框架,例如監控和自動重啟。CF 還自動化了管理負載均衡和來自用戶的路由請求,消除了許多通常與應用管理為開發和運維雙方都有關的繁瑣的任務。

正如我們在第二章:開放治理:基金會模式 所提到的一樣,Pivotal 將 CF 項目的治理移交給了 Cloud Foundry 基金會,自2014年末都是以開放治理和廠商中立的精英型模式來運營的。

從一開始 CF 成為開源項目算起,再加上開放的治理,造就了健康的生態系統,有廠商持續不斷的加入,且擁有廣泛的業界雲計算參與。基於 Cloud Foundry 的 PaaS 雲平台產品有 IBM、惠普、ActiveState、Pivotal、以及CenturyLink均已上市,CF 仍然保持著增長的趨勢,其雖然還很年輕,但是通過開放基金會形成的堅實的治理結構會給 CF 帶來光明的未來,以及圍繞整個行業的PaaS解決方案的合作。

Docker

Docker 是一款最新的開源項目,更準確點說是現在站在雲計算的「風口」。Docker 的核心,是容器技術,不過其重新發明了輪子,目標是替代已有的容器技術—— LXC。容器技術是一種操作系統級的虛擬化技術,在用戶空間的表現是看起來像擁有一套獨立的系統一樣。Docker 還希望通過改進用戶體驗,簡單而易用的來在任何地方「構建、交付、運行」 應用程序的代碼,甚至想取代傳統的虛擬機或者是 PaaS 的某些應用場景。如果要對過去兩年的 Docker 有什麼要說的話,Docker 以非常成功的方式應證了開源!近來,Enterprise Technology Research (ETR)調查了 685家的CIO們,詢問他們是否有意在接下來的一年裡使用 Docker 相關的付費產品,令人頗為驚奇的結果是:97%的 CIO們說會!這是 ETR 創始以來得分最高的調查

[18]

。另外一個可以佐證 Docker 的成功以及其龐大的影響力的是,亞馬遜近期通過其 AWS ec2 的容器服務來支持 Docker 的API。儘管亞馬遜通過其 AWS 平台支持了很多傳統的開發標準,但是採取其它非標準的 API 定義尚屬罕見。這就非常明確的承認了 Docker 在容器化世界的領導者地位——正如我們經常所看到的,很多廠商為了迎合 AWS 這個 IaaS 市場領導者地位,將自家的產品做的和 AWS API 兼容。

一如我們前面所討論的其它的雲計算的開源社區剛剛起步的時候,Docker 這個開源項目當面面臨的問題,由一個單一的商業實體發起並控制,且名稱都是一樣的。Docker 有限責任公司在整個開源項目中是關鍵角色且是維護的主要力量。Docker 和我們前面討論過的一樣,擁有多個積極有利的一面,幾乎所有的 Docker 的開源社區方面的工作、計劃、和討論都是在公共的論壇上進行的。Docker 的員工,也是開源社區的成員,對於新的成員表現出非常好的態度;事實上,我們的經驗是他們(很多開源項目均是)到處去招徠新的成員加入,不管他們的經驗如何、或是對於項目本身的了解。儘管 Docker 並非是一個理想的開源項目,因為它有著最為致命的——單一廠商的控制,其實正如我們所一路看過來的,這對於一個剛剛創立不久的項目是非常正常的。我們有理由相信,Docker 會在其下一個成熟的周期會確保項目的長期成功,包括如何治理和監督。

伴隨著 Docker 的成功,Docker 也開始承受來自業界其它的角逐者的競爭壓力,因為這是雲計算應用交付的未來,只漸趨白熱化的技術焦點。還有的壓力是來自社區的分裂:最為顯著的就是 CoreOS ,一直以來都是 Docker 的支持者,其實現了一套容器運行時環境,叫做「Rocket」,是 2014年12月發布的容器運行時規範「appc」的實現,這樣公開的撕逼和社區分裂行為讓 Docker 項目著實不太好過(希望不會太久)。大家最初的反應都是第一步先找一個就容器技術的開放治理組織,以及解決 Docker 運行時的核心規範。

在2015年6月,Docker 將其核心的容器運行時代碼庫貢獻出來了,以 Docker 的子項目的形式出現,名稱叫做「libcontainer」,以及針對開放容器促進會所要求實現的「runC」的新的容器運行時介面。關於開放容器促進會,我們將會稍後專門進行討論。隨著時間的推移,我們期望容器的開放治理和開放協作逐漸的成熟起來。這將對於商業和開源合作來進行創新和產品提供是有益處的,這對於目前對於消費者的熱點技術來說,是消除他們擔心廠商鎖定,增強可操作性、可移植性的最好契機。

案例:開放基金會擴展了雲的協作

我們所看過的所有的開源雲項目都有自己所擅長的地方,並在自己所屬的領域內找到內在的價值,但是我們所看到也只是起點,在未來會有更多的規範,那就是開放基金會所創建的合作多個開源項目。這些雲計算的基金會將會將特定的技術領域如標準化介面、定義跨項目的合作等,且未來會比我們今天所看到更加的寬廣。這些都是嘗試解決下一代雲計算挑戰的令人激動的時刻,但是我們這裡要特別講述的是新近成立的基金會,它們更加的能夠讓我們感覺到開放雲協作的新的時代。

開放容器促進會

正如我們在上一章所提到的,開放容器促進會(OCI)一款託管在 Linux 基金會的項目,旨在使用 Docker 的 libcontainer 組件作為實現容器運行時模式的標準化工作。除了以 libcontainer 作為參考起點之外,OCI 被指定為 CoreOS 已經開始的 appc 的統一來開發規範,Rocket 和 Docker 事實上的實現。目前的 OCI 項目還處於起草最終的批准章程階段,項目的範圍也在商討當中,預計至少要標準化容器打包或 bundle 格式的定義、運行規範,以及通過容器如何被管理的生命周期所決定的API。bundle 或打包代表了容器文件系統的內容以及所有運行時執行所需要的元數據配置。生命周期的定義將會定義如何管理容器的運行時,即啟動、定製、暫停、和恢復容器。

OCS 是下一代開發標準和跨項目合作的標杆。正如前面我們所討論過的,過去都是有標準的組織來開發「paper標準」的,然後在要求所有的實現者來測試其所定義的規範。相反,現在很多的開源項目均是專心的用代碼來實現,以及它的 API ,當積累到足夠的人氣的時候,已經成為事實上的標準,毋需任何的規範、互操作性測試、以及所有感興趣的參與者們的聯合通過。

OCI 在這兩者之間都會做一些嘗試:規範或標準,將會以開源的實現為參考進行開發。而模式是不需要追求過新,Docker 同意使用這些參考的實現作為 Docker 自身的一部分,Docker除了消化社區定義的參考實現之外,我們還看到 Cloud Foundry 開發社區的建議是使用 runC 的參考實現,來作為 Cloud Foundry 的應用框架內的容器運行時標準。這是 OCI 剛成立就表現出來的亮點,說明這些參考的實現不僅是規範的精確表示,而且還會立即在現實世界的場景得到使用和測試,來自實際的客戶體驗,幫助雲計算社區確保該規範是滿足實際需求的。另外,我們還看到 OCI 規範的多個實現都在開發當中。這確保了沒有一個特定的實現是非必要的編纂實現。此注意力集中在將標準與真實世界的代碼庫鏈接起來,在多個雲廠商的共同開發下,這是標準化流程很自然的下一步的走向,這與我們所一直以來所堅稱的開放治理模式是開源項目成功的基石是吻合的。

雲原生計算基金會

在2015年6月所創立了 OCI 之後不久,一些雲計算市場上關鍵的角色開始意識到需要在 OCI 所提供的運行時環境之上建立一些標準。儘管在單個容器的核心管理上的重要性已經達成一致,但是在這之上更高層次的容器管理也非常的有必要。於是,在2015年8月,在 Linux 基金會合作項目的羽翼之下,雲原生計算基金會(CNCF)成立了。,在本文寫作的時候,CNCF 的工作確切範圍仍在商討中,但是已經聚焦於數據中心內的容器集群的編排、分發、發現、以及生命周期管理。這些技術的集合統稱為「數據中心操作系統」(DCOS)。

雖然我們現在還無法明確的描述 CNCF 目前的工作範圍,但是我們有理由相信,如此眾多的業界大腕們聯手通過開放式的精誠合作,能夠為 OCI 所鋪墊的標準化交上一份滿意的答卷的。尤為重要的是,在這個高級別的如編排、生命周期的層次中,我們希望看到圍繞分發、發現、和管理特性的通用性,能夠增進各個供應商之間的互操作性,尤其是在開放和混合雲解決方案的開發上。

請在開放雲中站穩您的腳跟

到現在為止,我們已經捋過了多個開源項目、多種開放治理方式、以及一些基金會的模式,且可以看到對於雲計算的技術來講,真正的開放才是未來,才是真正有價值的,即協作的創新和合作競爭這條道路。我們也已經注意到了,其中主要的雲計算的倡議和項目,越來越明顯的感覺到,要完成很多的跨項目的合作才能解決雲計算日益臨近的挑戰。

我們也可以看到,在運維人員、開發者、生產者和消費者之間的界線越來越模糊,而且代碼、社區、和開源文化的性質正在悄然發生著變化,已經超出了傳統的涵義。這就必然導致一個任何人只要有興趣就可以成為開源項目的開發者和貢獻者的扁平化時代的到來,至於方式,無論是為最終用戶完善文檔還是為開發者提出新的特性的建議,已經不是需要特別提醒的常識。

對於感興趣的最終用戶來說,這意味著再也不是站在純粹的消費者一邊的了:可以投入到自己感興趣的項目,根據自身的需要在項目未來的發展方向上發出自己的聲音。對於開發雲計算平台的公司或者是運營雲服務的公司來說,投入到開源中來,既可以受益於社區,又可以加速進入市場的准入門檻,以及不僅能夠實現自己的利基專長,還能夠吸收其它的來自開放社區的能力。參與到圍繞關鍵雲計算項目的基金會開放治理中來,還有助於提供公平的競爭環境,作為更為廣泛的參與提供發出更多的聲音以影響廠商中立的決策制定。

如果你正在考慮將自己的內部使用的技術開源,又或者是通過創建獨立或企業領導引導的新社區項目,請記住,請選擇將項目開放,以獲得在整個生態系統的長期的生命力。一如我們所看到的那些成功的開源項目一樣。你需要讓其他各方的人們參與進來,並成為一些領導的角色。由健康的開放治理模式來引導。基於精英主義的技術發展路線,這在開始的時候是蠻困難的——因為沒有人樂意將自己的想法或項目放棄控制權的。然而,正如我們所列舉出來的,這條途徑在雲計算中是最為有利的,真正的協作!

總結

我們相信開源軟體項目通過健康的開放治理原則的治理下,以及廠商中立的基金會的交付實踐,會締造一個成功的雲計算相關技術的未來的!我們已經看到一些大型的項目如 OpenStack、Cloud Foundry、Docker ,以及我們在前面討論過的圍繞它們的每個基金會,強強聯手蓄勢待發、企業的贊助和參與,引來了一大堆大大小小的廠商參與。這些開源和開放治理的項目,既允許廣大社區協作,也允許獨特的創新,這就可以讓傳統的廠商和初創公司基於開放的技術交付雲的產品都可受益。

另外,我們也相信,在不久的將來,開放雲的的跨項目合作將是趨勢,通過一些基金會的庇護,在雲計算的底層和應用層的編排和管理組件尋找一些標準的關鍵組件。對於 IaaS 或 PaaS 來說,客戶最為需要的不是一個項目就能滿足所有需求的所謂的產品,而是會覆蓋多個潛在開源項目和產品的全面途徑。跨多個雲基礎架構類型的編排、集群管理、以及分散式/部署的標準介面——舉例來說,虛擬機和容器——在下一次的變革中,誰將是雲計算中的王者?在這些關鍵的概念上的一些通用性和互操作性都是跨多個廠商和多個相關的開源項目的協作的。這就帶來了眾多的機會,一個潛在的新的利基廠商的實現,將帶來新的收入、新的產品。

我們深信開放雲的未來就是將開源精心的規劃。

作者簡介

Philip Estes

[2]

Philip 在 IBM 開放雲技術團隊擔任高級技術組成員的職位,目前代表 IBM 在 Docker 開源社區,亦是 Docker 的核心維護者。Philip 還和 IBM 的產品團隊以及客戶管理一起共事過,將開源的雲技術轉化為實際的產品、解決方案和 IT 項目。Phil 的成員團隊均工作在關鍵的開源雲項目的上游,如 OpenStack、Cloud Foundry、Docker等。在 Phil 加入開放雲團隊之前,Phil 是 IBM Linux 技術中心的首席架構師。

Doug Davis

[3]

Doug Davis 在 IBM 的開源雲和標準部門工作。他在開源和標準這個細分的領域內有超過15年的工作經驗,曾經參與過過個現下非常流行的研究標準,諸如 Apache SOAP & Axis、圍繞 Web 服務/SOAP 的 W3C 和 OASIS 標準、OpenStack、Cloud Foundry、以及最近參與的 Docker、OCI、和 CNCF。他還是 WSTF 的創始人,WSTF 是基於 Web Service 的內部操作機制的實現,地址是http://soaphub.org,並有多個企業使用此實現來做他們的實時協作。

譯者寫在後面

通往開放雲指南–開放雲項目簡短介紹

[20]

,這篇文章是我職業生涯的轉折點,令我熱血沸騰的開始了自己的創業之路;但是本篇將我的創業夢敲醒,讓我回到了殘酷的現實!我似乎玩大了,開放雲精選

[21]

的野心是 IBM 開放雲團隊的目標! 我看起來似乎毫無希望!沒有團隊、沒有錢,有的就是似乎是人家的想法。接下來該如何走?我陷入了深思。。。。。。


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 Linux中國 的精彩文章:

Linux 文件系統詳解
如何暫時禁用 iptables 防火牆

TAG:Linux中國 |