【51CTO.com快譯】Joyent率先舉起了容器支持的大旗，而后又得到了Docker方面的認證。盡管技術水平出眾，但像Joyent這樣一款獨立的公有云方案是否能夠在市場上闖出一片天地?

憑借著自己記者的身份，我得以接觸到技術業(yè)界當中那些最具智慧的頭腦——而且不僅僅是拜讀他們的文字，還能夠與其面對面交流。今年10月，我更有幸在Couchbase Live NY大會上與Joyent公司CTO Bryan Cantrill直接溝通。 

[[155263]]

Cantrill是那種很有天賦的技術人員，他能夠在不自覺中將枯燥的專業(yè)內容變得娛樂化，并在極為平常的表述中達成技術宣傳的目的。只要一開口，他就能夠對計算機技術的發(fā)展歷史如數(shù)家珍，并很好地切合當前的討論話題。上次遇到這么風趣的技術牛人還是在我為JBoss效力的時候，Marc Fleury也擁有這樣的出眾魅力。

那些PaaS尚未成型的歲月

在分享與Cantrill的交流內容之前，讓我們首先聊聊背景信息：2012年，我曾經在一篇名為《我到底該選擇哪款PaaS方案?》的文章中提到，SaaS不會快速轉變?yōu)镻aaS。

而在那之后，Cloud Foundry用了很長時間來重新編寫并推廣PaaS方案，但其始終未能受到高度重視。紅帽公司的OpenShift實現(xiàn)了可觀的改進成效，不過其并不屬于真正的公有云方案，而且直到今天也未能真正在世界范圍內普及。我甚至都快忘記了Heroku的存在，目前提起云計算我們能夠想到的似乎只有Amazon以及新興的微軟與谷歌。

不過如今情況開始有了轉變：Docker正在迅速興起。Docker允許我們在享受大部分PaaS優(yōu)勢的同時，繼續(xù)保留對軟件層以及使用規(guī)范的控制能力(因為我們都不希望在部署應用時被服務供應商所牢牢束縛)。

Node項目成員打造出的非Amazon云成果

盡管Cantril所在的Joyent公司向來以“Node.js項目成員”所建立而為人所知，但這家年輕的企業(yè)并沒有始終沉迷于過去的輝煌當中。Joyent公司是一家云服務供應商，其同時提供計算與存儲選項，且擁有自己的多座數(shù)據(jù)中心。該公司還銷售與Cloud Foundry以及OpenShift相似的受支持開源環(huán)境，但這套環(huán)境完全基于容器技術構建而成。

用Cantrill的話來說，Joyent公司優(yōu)于或者說至少走在了市場的前面：

在Cantrill的表達當中，我產生了一種強烈的既視感：將Docker與Solaris Zone聯(lián)系起來。作為Sun公司的前任員工，Cantrill當然很清楚這段掌故，而且他自己也曾經有過這方面的感受。不過Joyent公司不僅能夠準確地定義什么是錯的，更有能力弄清什么是對的。當然，Cantrill也以非?？陀^的態(tài)度承認Joyent是一家知名度相當?shù)偷墓性乒蹋裁媾R著一場艱苦的影響力提升戰(zhàn)：“我們不是Amazon，我們也不是OpenStack，我們仍然默默無聞。”

但在另一方面，OpenStack本來也不是個值得效法的對象。Cantrill將OpenStack比作了當初的Solaris CDE;雖然有一些企業(yè)試圖以其為核心進行開發(fā)，但幾乎沒有任何一位參與者得到了理想的成果。而盡管OpenStack項目吸引到了遠遠超過CDE的支持者數(shù)量，但Cantrill認為OpenStack的時代已經成為過去：

我認為人們當下已經開始意識到這一點。OpenStack代表的是一波已經過氣的技術革命。而我們正將精力更多集中在我們認為將代表未來革命的成果身上。這在目前也許只能算是一種希望，但在明天卻可能呈現(xiàn)出一股容器技術浪潮，并體現(xiàn)為一整套基于全容器機制的堆棧。我們堅信這一點，而我們所開發(fā)的軟件全部為開源項目。

與其它廠商一樣，Joyent公司也同時擁有公有及私有云產品。Joyent公司的容器技術Triton能夠提供內核原生容器功能，但同時亦支持Docker軟件包。Joyent方面還宣稱其具備裸機運行能力——畢竟Triton的開發(fā)基礎正是擁有數(shù)十年發(fā)展成熟度的Solaris Zone。

考慮到用戶往往傾向于在Amazon環(huán)境之上運行Docker鏡像，這類容器型虛擬化方案本身也需要以虛擬化形式運行?？偠灾统鲥X包給AWS付錢吧!相比之下，Joyent不僅在CPU與資源使用成本方面低于Amazon，同時所需的資源總量亦將有所削減——畢竟我們用不著干將容器運行在虛擬機之上這種沒必要的蠢事。

這是一套與EMC殊為不同的非Hadoop/非S3存儲方案

SAN實在是種很傻的事物。將我們的存儲資源從計算體系當中各設備的每塊磁盤中剝離出來并散布到整個網(wǎng)絡，這簡直就是一套專用形式的客戶端-服務器計算機制。很明顯，我們應該采用具備彈性的新型軟件設計方案，而對那些單純用磁盤堆疊并模擬而成的所謂“彈性”說不(抱歉，戴爾，說的就是你)。

而這正是Joyent公司走在時代前列的重要表現(xiàn)之一——同時也略微領先于HDFS、EMR以及S3——也就是Manta，一款集成有計算機制的對象存儲解決方案：

我將向大家列舉我們利用Manta所實現(xiàn)的具體效果，我們已經將其引入日常工作，但市場對其尚未做好準備——正因為如此，我們并未對其積極宣傳，因此客戶可能還接受不了這樣的方案?？偠灾?，它的作用在于提供對容器存儲資源進行拆分的能力。如此一來，我們就能夠擁有一套與S3類似的對象存儲體系——但如果大家只希望對存儲對象進行計算處理而非將其移動到對象存儲之外，則能夠直接在對象所在的位置建立容器系統(tǒng)。

諷刺的是，我發(fā)現(xiàn)Cantrill似乎并不相信在一臺設備當中塞進大量磁盤驅動器，而后通過網(wǎng)絡進行連接，最終對所有接口進行粘接的作法是什么好主意：

不，我認為這種集中化存儲設計不是什么好東西……應用程序能夠計算; 因此將存儲與計算資源硬性拆分開來根本沒有必要。這種思路只是符合人們的思維習慣，而且確實能夠為計算機制帶來一種比較良好的特性——即臨時性。一旦某臺設備出了問題，大家可以將其啟動另一臺，因為計算與存儲并非處于同一設備之中。這確實不錯，但好消息也就這么多了。畢竟計算資源在那、存儲資源在這的設計本身就存在弊端，而且需要強調的是，大家還需要為此對可能出現(xiàn)故障的組件進行沒完沒了的優(yōu)化——但事實上，這些組件本身可以說是我們能夠買到的最可靠的東西了。我得再說一次，目前基礎設施當中最不靠譜的東西就是傳統(tǒng)磁盤驅動器，但它們在真正出現(xiàn)故障之前都有質量保證周期，這意味著我們至少能夠對其做出較準確的更新管理預期。

在Manta的幫助下，大家可以通過API建立起存儲體系并運行由R、Python、Node.js、Perl、Ruby、Java、C/C++等各類語言編寫而成的大規(guī)模并行流程。另外，Manta還支持流媒體。不過Manta有著自己的既定任務，它不是Spark、當然也不是Hadoop。

不過我們還要考慮到，歷史也許會在Joyent身上重演。如果沒有兼容性API以及強大生態(tài)系統(tǒng)的支撐，Manta也許最終只會成為另一項走得太快、導致市場無法跟上的早夭技術。很明顯，走得快一點不是壞事，但如果快到人們無法理解或者底層技術優(yōu)越性不足以構建起擁有吸引力的生態(tài)系統(tǒng)，那么消亡將只是時間問題。

單單更好就夠了嗎?

當初Joyent公司剛剛開發(fā)出自己的容器技術時，尚不存在任何既定的行業(yè)標準或者基于Linux的API。Docker的橫空出世創(chuàng)建出了客觀層面的執(zhí)行標準，也使得人們開始爭取投向容器技術的懷抱——而這又從另一個角度為Joyent創(chuàng)造了市場空間。

也許當Spark成為業(yè)界領先的API時，Manta也會擁有同樣的效果。之所以值得肯定，是因為Manta確實擁有出色的設計且具備開源屬性，因此它應該能夠抓住相當一部分用戶的眼球——畢竟它確實優(yōu)于HDFS、SAN或者其它現(xiàn)有圍繞虛擬化建立起來的規(guī)?；鎯Ψ桨?。

不過生態(tài)系統(tǒng)的構建在很大程度上屬于一項社會性任務，而非單純的技術或者經濟性事物。擁有更好的技術是否就足以幫助Joyent實現(xiàn)突破性的市場影響力?目前這家年輕的企業(yè)面對著眾多巨頭的壓迫：Amazon、Hadoop/Spark及其相關項目，而每一種方案都希望成為人們眼中的核心“混合云”實現(xiàn)途徑。所以，單單更好就夠了嗎?這一切還有待時間的檢驗。

原文標題：Joyent: The Docker-friendly cloud you’ve never heard of

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】