編者按

容器技術目前已經成為技術圈內的“常識”，但是容器生態能否健康發展仍然任重道遠。在收穫最初的讚揚之後，領軍者Docker如今身陷非議：今年執意壯大發展Swarm進軍編排領域，似乎Docker公司一方面惹毛了很多強勁的編排領域玩家，另一方面也並沒有收穫預料之中的成果。12月14日，Docker計劃將其關鍵容器執行模組之一Containerd貢獻給開源社群。在周暉先生看來，這意味著Docker的重心將回歸到容器技術本身，或已放緩其在編排領域的步伐。一直從事PaaS和容器技術研究的周先生還認為，不管怎樣，Docker都是一家有著特色的優秀公司，Docker成功地將容器技術理念深入人心，並且也增加了業界對PaaS的認識和信心。以下文章來自於InfoQ對Pivotal大中華區雲端計算首席架構師周暉的採訪整理。

嘉賓

周暉，Pivotal大中華區雲端計算首席架構師，有著豐富的PaaS雲實際建設經驗，負責過國內某知名銀行已經生產上線一年的PaaS雲的架構設計和部分功能的實現，參與過某超算PaaS、某超市電商PaaS、某電力PaaS等專案的建設。

誕生與興起：Docker贏得聲譽

容器技術被傳頌並深入人心，是因為Docker；但是，其實技術積累由來已久，早期的容器技術是Google、IBM等公司貢獻出來的，Pivotal也發展了Warden容器技術，這些公司都專注於在各自的常規業務中，並沒有重點投入容器技術；而Docker很好地將容器技術單獨形成專案產品推向社群。

為什麼有同樣技術潛力的公司，會有如此迥異的產品決策？我認為是因為著眼點不一樣或者說基因不同，大公司著眼於規模化的企業應用，比如Pivotal把容器技術內建在PaaS技術中，然後以完整的解決方案的形式提供出來。結合自身例子來看，其實Warden比Docker早，但是Pivotal從成立的第一天起，就是面向企業級的，產品程式碼模組很完整，Warden容器的程式碼量很可能少於整體Cloud Foundry的千分之一，單獨拿出來對企業客戶意義不大，並且目標客戶也不需要知道那麼底層的技術細節，他們需要更專注於業務創新。

而Docker公司具有開發者基因：Docker的產品很適合開發者，快速升級以滿足新的功能需求，完全不用管和前面版本的相容性，就像有故障重啟Windows那麼簡單，但是你讓客戶去重啟他們生產系統的Linux就不會那麼輕易了，並且Docker對開發者簡單易用。Cloud Foundry提供的容器是黑盒子，對運維人員來說簡單易用，無需關注容器細節，甚至都不需要直接操作容器；而Docker是白盒子，隨意增添組合特性，對於技術fans很有價值。同樣Docker也有很多很棒的設計，舉例說明，映象倉庫，誰都可以把自己做好的Docker映象上傳上去，目前Docker的映象倉庫有海量的映象，這符合網際網路的分享精神並因此發展壯大。所以Docker之所以發展起來，可以說他摸到了市場的脈絡。

因此除了自身優秀和容器界技術成熟之外，另外一個因素是Docker生逢其時。2013年Docker誕生之時，正值企業應用轉向網際網路應用高速發展時期，應用小型化微服務化的需求正好是其用武之地，也就是適應了今天流行面更廣的微服務的一個方面---應用部署到容器中執行。

變形發展：急於盈利，引起生態圈的利益衝突

Docker在2016這一年做了讓生態圈反感的事情：通過之前收購一些公司大張旗鼓地發展Swarm，集中發力叢集編排管理。

容器生態中有兩個領域：一類是容器本身的領域，另外一類編排叢集管理領域。這兩個領域雖然會有重疊的部分不完全獨立，但是基本上各有各的發展方向，靶向用戶不同。

第一領域是Docker最開始在做的內容，面向開發者、小型企業或者個人版嘗試測試，直接應用在大型企業中的還是比較少，最多是一個部門級別的應用（數量級一般為個位數）；用於開發和測試，在生產中用的比較少（設計時也沒有考慮到生產的複雜性）。

第二領域的領軍代表是Mesos、Kubernetes和Cloud Foundry，或者說現在的CaaS。在企業中的應用，這個派系更適合做成雲，管理的是大規模的應用執行生產環境。

兩者的定位是不一樣的，但是第二類叢集管理具有更多、更早的盈利空間；經過多輪融資後的Docker Docker對盈利願望比較強烈，因為容器本身開源很難掙錢，都是不掏錢的客戶，所以希望打入企業級的容器叢集管理市場來盈利。可是Swarm等一系列舉動被視為捆綁競爭，非但沒有讓人對其技術刮目相看，反而損還他與生態圈內其他廠商的關係。在今年7月底，GoogleKubernetes佈道師 Kelsey Hightower 和Docker的CTO Solomon Hykes在Twitter上發生了激烈爭論，爭論的主題是要不要用RunC或其他容器來取代Docker引擎以及OCI的意義。

被迫妥協：共同研發的RunC意味著什麼？

Docker一開始就一家獨大，並且並不是一種開放的態姿態在做，所以很早之前Google就投資了CoreOS來做競爭的容器--Rocket。那時是三家鼎立：Docker/Rocket/Warden，為了避免慘烈的競爭，大家終於統一意見，決定成立OCI做統一的容器執行時---RunC，OCI成立後加入了大約50家廠商。出於對Docker封閉化商業式發展的擔心，OCI商討出這種方案：以RunC為核心重新構建生態圈，並且通過外掛來弱化容器在CaaS生態圈的重要性。

OCI負責的RunC是非常小的執行核，其目的在於提供一個乾淨簡單的執行環境，他就是負責隔離CPU、記憶體、網路等形成一個執行環境，可以看作一個小的作業系統：現在OCI只負責這些，尚未擴大到更大的範圍，其實這樣是小而美的，這樣的是業界所最需要的。

當然， RunC的生態發展就會侷限在企業級別應用中，並因此具有不同的發展目標：RunC不是要提供多少種工具，而是要非常穩定。接下來需要做的是可能是新增完善一些功能，比如將Docker映象導進來，與各種外掛更好地結合（動態化即插即用），熱啟動和遷移。這些功能是企業需要的，但是對開發者沒什麼作用。以熱遷移為例，從一臺虛擬機器遷移到另外一臺虛擬機器，但是開發者可能本來就一臺機器並沒有這個需要。

因為RunC是Docker的一個子集，所以單純從程式碼量上來講，RunC只佔Docker的百分之幾。

相比而言，Docker有豐富工具，更貼近於開發者。這也是為什麼很多個人開發者並不知道RunC，因為RunC的使用者都是Mesos、K8S和Cloud Foundry這類的CaaS廠商。

在RunC早期，Docker是主要貢獻者（在我看來，如果Docker不參與RunC的發展就意味著和容器生態圈決裂）；後來隨著各大廠商對RunC大幅貢獻程式碼，RunC的程式碼貢獻者越來越多樣化,Docker所佔比例在持續下降。通過不斷迭代，RunC一定會越來越成熟，它已經在生產環境中開始積累技術了，Cloud Foundry已經有不少全球重量級客戶在用內建RunC容器，經歷的很多坑的bug修補已經回饋到RunC原始碼中去了。

Docker的執行核心雖然是從1.11支援RunC的，但是Docker的心態是很複雜的：一方面作為OCI成員必須支援RunC，但是另一方面他會擔心RunC對Docker的替代的威脅。

危機解讀： 適合Docker公司的路在何方？

坦率而言，我認為Docker進軍編排界並沒有優勢，因為他缺乏企業級基因。

Docker更適合在容器本身的技術，今年Docker力推Swarm，把資源花在了叢集管理上，這其實並不是Docker技術的初心。當時Docker迅速流行是因為簡單易用，而後來走卻想把太多東西塞到Docker中。

在從目前適用場景選擇來看，一般而言，使用Docker Swarm的都是小企業的小規模應用，而大企業採用的都是Mesos、K8S或Cloud Foundry。（當然有極少的案例採用了Docker的Swarm，但是從比例而言這並不具普遍性）。因為最初的設計來源就不一樣，前者是從開發者角度設計，而Mesos、K8S和Cloud Foundry是從企業中來，有很多企業運維的實戰積累。

Docker也就是小几百人的公司，並不算巨頭公司，做企業級市場比較吃力，而做中小企業或是個人使用者市場這種思路更適合Docker的盈利模式。在我看來，不論國內國外，做企業級市場一定需要很多銷售去和企業使用者打交道聊需求，專案實施的時候往往要根據客戶的需求做定製，要知道每個企業使用者的需求是不一樣的，沒有辦法進行完全統一的標準化，那定製化的需求就需要一定規模的人力投入，每個專案都需要一定的人員資源投入，小公司很難做這種投入。在我看來，小作坊做企業使用者還是面臨很大的挑戰。

從企業級需求來看，比如企業一個考慮就是，一定要前後版本相容，否則就無法升級。而這恰恰是Docker不care，比如個人使用者可以隨時重啟機器，開發者在遇到問題可以重啟，在企業級的思路不是這樣的。Docker的思路並不是做企業級IT應用系統的思路，所以如果應用到企業級應用中一定會遇到問題。至於很多網際網路公司在應用Docker，很多網際網路公司也是在摸索，包括自己做Docker叢集管理的不少，但自己做Docker叢集管理的基本都開始開始轉向K8s、Cloud Foundry、Mesos這些專業的容器叢集管理軟體了，這是很明顯的趨勢，那麼這些網際網路企業當初花資源做的叢集管理基本就是被廢棄，即使現在沒轉的遲早要轉型到CF(Cloud Foundry)/K8s/Mesos。對於企業客戶來說，這種試錯是得不償失的，因為企業客戶沒有這麼多人去研究開發容器叢集管理軟體。但對網際網路公司來說，這個試錯是可以接受的，畢竟養這麼多工程師其中有一部分就是通過不斷的、或大或小的試錯而優化技術的。

Docker為什麼最初發展那麼快，因為是面向開發者，個人使用者或者中小企業，這是他興旺起來的市場。起步於個人消費者市場，卻又想立刻切入企業級市場必然會有很多水土不服，這種背離最初的起源的做法並不是很明智，我認為面向個人消費者其實才是Docker的固有基因。

那怎樣才是Docker更好的盈利模式呢？在我看來，Docker可以在映象倉庫上發力，做成類似蘋果AppStore的模式。Docker的優勢在於他有映象的入口(網際網路最關注的幾個價值點之一)，他應該把映象市場運營好，第三方在使用映象的時候進行付費。比如MySQL映象，網上不說一萬種也有一千種；但是哪個映象好用還真考驗使用者，如果使用者用的不好，也沒有反應並改進的渠道，其實這樣也不利於MySQL映象的持續發展，如果Docker能夠對自己倉庫市場的高質量MySQL映象收費，然後分成給做MySQL映象的公司，做MySQL映象的公司也可以根據客戶的反饋進行不斷優化，做到生產可用；那麼使用者應該是樂意付租金費用的，畢竟自己花費成本做一個生產可用的mysql映象成本不低，這有很大的經濟價值。Docker可以與MySQL等廠商進行利潤分成的模式擴充套件，就比較容易盈利了。

迷途知返：Docker公司重拾初心？

經過激烈的碰撞，現在Docker又迴歸到自己擅長的老本行中，將視線從編排界收回到容器技術。

1 Containerd的開源

12月13日，Docker 開源了Containerd( https://containerd.io )，它是為RunC提供介面並進行映象的管理。非常有意思的是Docker沒有把Containerd貢獻給Apache/Linux之類的基金會，或是直接貢獻給RunC，而是單獨開源，這個態度很是微妙，體現了對RunC一定的防範，目前有AWS、Google，IBM、Microsoft和阿里雲等作為初始成員，會為專案提供貢獻和維護人員。 我對這個舉措解讀為Docker對容器技術的迴歸，並且是對16年爭論的折中，他希望生態更加開放，更良性的發展，降低業界對Docker封閉的擔心，同時也是通過Containerd作為橋樑，讓大家更多地關注回Docker，抵消因為生態分裂對Docker帶來的不利影響。

在我看來，這其實也不失為一種對RunC的堤防措施，讓大家在使用RunC同時也不忘記Docker；開源的舉措也可以一定程度緩和關係（不過，我認為Docker並不會把Containerd交給RunC方運營）。

2 DataCenter“錢”途未卜

今年年初的時候做了DDC（Docker Data Center），其目的是為了向客戶收費。但是，目前無法找到這個專案的營收數字，單從DDC和Docker開源部分來說，沒有太大的差別，商業價值還無法確認。

3 與阿里雲合作 的全面合作

Docker選擇重量級的公司合作其實是一個明智的選擇，雖然這對做Docker映象倉庫公有服務的小公司確實不是好訊息。大公司的好處有人力和財力，而且Docker的商務版(DDC)未來要放在國內公有云上，阿里有這樣的基礎設施，可以在初期承受大量客戶免費試用的投入，在IaaS公有云生產級別也更可靠。

當然，有人歡喜有人憂，此番合作還意味著：Container as a Service公有云的市場就已經定型了，做Docker映象倉庫公有市場對創業公司關閉了。

4 Swarm還會繼續，但前景不明

Docker還會把Swarm繼續支援下去，但是編排領域的有很多細分的市場，Swarm的發展目標應該會是小規模的叢集；而且Docker的發展重心還是會回到容器本身，因為只有精專容器本身技術，才會凸顯Docker獨特的優勢。做編排的話，從社群熱度、貢獻人數、釋出頻率可以看出，Swarm應該是會被其他競爭對手的光環所淹沒。

Docker重新考慮在做的就是揚長避短：既然短處不能補成長處，那麼就需要回歸繼續發揚長處。

避免競爭誤入歧途，容器生態仍有藍海

上文提到了Docker與阿里雲合作對國內一些創業公司造成了影響。我還想談談我對容器創業的一些建議：首先我不認為在Docker之上進行定製出CaaS是有市場做法，創業公司如果一定要侷限於Docker創業，可以考慮在Docker生態圈中，還有那些技術空白點，然後專攻一點成為特色（這是國外容器創業公司常見的做法，Docker也收購了很多此類的優秀公司）。

那麼容器生態的創業還有哪些藍海領域呢？除了上文提到的容器類技術和編排集類，其實還有外掛技術，這可以看做是兩者的交集部分。外掛技術是很多樣化的，比如網路、儲存，並且有很大的發展潛力。容器的各類外掛在2017年將會有較大、較快的發展，這塊目前還屬於拓荒地帶，經常可以看到技術進展，比如儲存外掛就超過10類，而且很不成熟，如果能做統一化或是成熟後、簡化，都可以成為很有價值的技術。以網路外掛為例，Docker有CNM標準，CoreOS、Mesos、Cloud Foundry有CNI標準，當然這兩種標準從技術上講還是有很多不相容的地方，接下來的發展是相容還是統一，還是一強一弱導致弱勢方自然淘汰，需要走一步看一步。而至於儲存，目前主要由很多儲存廠商主導，根據自己的儲存特性研發的儲存外掛，種類多且複雜，在何種情況下使用何種外掛很考驗使用者對儲存外掛的理解能力。這些外圍的外掛還有較大的發展空間。

容器叢集也還有很大的發展空間，叢集的概念和應用叢集微服務化剛剛興起，在實際生產中會發現還有很多問題需要解決：比如功能尚不完善、可靠性和穩定性有待提高。

那外掛為什麼目前還不是OCI標準所關注的呢？OCI目前關注的是RunC，以一個更小的核心給業界；而外掛是RunC補充，提供了很好擴充套件方式：RunC作為執行環境，很多環境是不需要外掛就可以執行，比如大部分的Java/Web微服務應用，反倒是傳統應用容器化，需要用到外掛，但這類應用並不是容器化的最主流應用,是典型的1：9現象。就是90%的容器應用不需要外掛，10%的應用需要外掛，但是外掛帶來相當大的複雜性。應用容器化只須在需要哪種功能時就使用哪種相應的外掛即可。不過目前各個廠商對外掛的定義和理解並不完全一樣，除去共識的網路、儲存等外掛，其他的尚模糊。比如Docker對外掛有自己的理解，哪些是外掛，是否放到執行環境裡面；Mesos對外掛的解讀範圍就更廣，所以將外掛標準化的想法在我看來還是不太容易。

但是，對於網路外掛，業界認識都比較統一，因為是普遍需求，並且應用的多是VPN隧道技術。如果對這類外掛進行統一標準化，可以便於相互之間的通用。

另外，為什麼不建議小型創業公司考慮企業級的完整版CaaS？和Docker的情況類似，這需要有企業技術經驗積累、規模化人力和財力的持續投入。舉個例子，在某次競標，一家銀行在招標，當時的要求就是廠商可以自我證明可以存活三年，說明企業客戶對創業公司能否存活三年還是有疑慮的。

Docker興起，推動了PaaS的推廣

Docker到來前，PaaS主要在企業級市場，並不為公眾所知。PaaS分成公有云和私有云市場。國內公有PaaS雲市場的很多廠商基本上成為了先烈，主要問題在持續投資無法實現正向現金流，因為彼時PaaS主要面向開發者，向開發者收費有難度，而向開發者/中小企業提供IaaS的市場則發展比較好。不同的是，國外最早Heroku 、Salesforce等在做公有云的PaaS比較成功，在比較長時間的實踐中積累了很多PaaS的模型和經驗，後來Cloud Foundry當時也吸取了當時兩者很多很好的實踐經驗。

Docker的流行促進了大家對PaaS的認知，當然也有了CaaS的興起（如果進行更嚴格的定義的話，Docker是屬於CaaS的），把PaaS從企業級市場的認知擴充套件到了開發者市場。很多人是先接受並理解了Docker，才開始關注思考PaaS。這是因為PaaS只是針對企業級使用者，很難形成普遍的知名度；而Docker是面向開發者的，開發者使用了Docker之後向團隊推薦，團隊再向上層同步資訊，是一種自下而上的傳播。

私有云市場的PaaS最早是網際網路公司在無意識的做，後來Pivotal進入市場，逐步定義了PaaS完整的架構，我們最早的商業客戶是在2013年底，那時Pivotal需要向客戶從0開始講解私有云的概念，而現在對於技術fans的客戶，只需要說PaaS是在Docker的基礎上做了那些技術工作即可。

放眼未來，PaaS和CaaS可以各自輝煌

PaaS和CaaS兩者有重合的部分，但是也有不同的側重：CaaS是提供一個容器，裡面是跑應用跑資料庫等都可以；而PaaS更關注的是應用，要對應用進行監控，要有應用框架、通用的應用功能如Session集中管理、日誌服務、路由服務等。

PaaS通過構建包來一鍵部署應用，這樣的做法極大的簡化了應用的安裝部署，也是遵循DevOps的理念。相反，Docker讓開發者去寫複雜的指令碼部署應用，比如目前DockerFile和Docker Compose，這對於開發者而言很痛苦乃至不可行的環節，這要求的不是業務編碼技能，而是對應用伺服器、對作業系統指令碼的程式設計技能。CaaS不限於應用平臺，它也不專注於解決應用平臺問題，所以它也不善於解決應用平臺的問題。

和CaaS不同， PaaS（Heroku、Cloud Foundry等）把應用相關的複雜度遮蔽，只需一鍵部署應用即可執行起來，無需關注應用環境的安裝環節，還有應用故障自動恢復、自動彈性伸縮、灰度釋出等使得應用運維可以全自動化。回到Docker而言，其實它對DevOps仍然有一定難度：Dockerfile/Compose的書寫一般是運維人員在做的事情，而Docker映象打好了需要交給開發人員，並沒有辦法做的很完美，很多地方沒有辦法完全固定，比如開發人員發現需要更改一個應用伺服器的埠這麼簡單的一件事情，這可能就涉及到一系列的指令碼的改寫，但這個事情到底是運維人員來做還是開發人員來做？運維人員來做那就不是DevOps了，如果開發人員來做，開發人員又很難具備運維人員的腳步程式設計技巧。而這一點Heroku和Cloud Foundry已經注意到了，並通過構建包徹底分離了運維人員和開發人員的分工。

我們看PaaS/CaaS的區別和各自的市場，PaaS的思路基於應用平臺，而CaaS並不限於應用平臺，因此它也並不能理解應用平臺的問題；所以兩者面對的市場還不太一樣，如果著眼於應用平臺那PaaS比較好，如果是希望把各種資源管理起來，當做虛機使用，通過容器實現，那CaaS比較好。

關於Docker和微服務

我認為將Docker等同於微服務是一個誤導性的看法。 微服務由兩個組成部分：執行環境（運行於容器中是很好的執行環境的選擇），開發框架（比如服務動態註冊、發現和呼叫等）。業內很多人只重視到了第一部分，而忽略了第二部分，比如Docker微服務化最常見的就是微服務的動態發現和呼叫則幾乎完全依靠第三方平臺來實現，如ZooKeeper、Consul等，但是這些工具的缺點是當叢集達到一定量之後就會出現不穩定的問題，而且平臺要適應各種程式碼需求有困難，我認為程式的事情歸程式來解決，而不是平臺。最佳實踐是採用程式框架從根本上解決問題，比如Netflix就進行了徹底的改造，他們的服務註冊、發現、治理、限流都是通過程式框架(也即後來的Spring Cloud)來實現的，經受了大規模的應用考驗。用平臺解決程式碼層面問題是有缺陷的，因為平臺解決的是平臺問題，不能包攬程式碼的工作；程式碼框架是解決程式碼的問題：服務註冊發現更適合在程式碼層面實現。

當然，微服務還有一個更關鍵的問題：如何對服務進行合理的分解和定義，不是說巨石應用隨便按模組拆分就可以了。經常會有人問，微服務對業務進行升級以後多個模組如何一起部署，問這個問題就是微服務沒有做好，學了微服務的形，沒有學到微服務的實質，最終微服務的效果也會大打折扣。問這個問題的根源在於微服務解耦的不好，沒有遵循微服務分解的方法論。如果微服務分解的好，那很大程度上是可以單獨部署而不會影響其他模組。

微服務做好了以後怎麼運維？故障發現、自動恢復，根據業務請求量的彈性伸縮等等這些工作，要麼通過PaaS去自動實現，要麼自主研發實現，但是這樣工作量很大。最終，微服務的價值在於讓開發人員只關注業務邏輯程式碼，不用關注非功能性相關的技術問題，這些技術問題交由微服務框架和執行環境來解決，而且微服務最終要能通過平臺實現運維自動化，就是未來的熱點“NoOps”，目前的ServerLess，Serverless不是目的，目標是NoOps。前幾年談NoOps，大家總覺得太遙遠，其實PaaS+微服務，使得NoOps越來越近。

下一個技術熱點： 資料微服務

容器是2015年最大的熱點，但是2016年容器的熱度在下降；2016年的熱點是微服務；2017年我認為是資料的微服務化。

為何認定是技術熱點？

之所以認為資料服務在PaaS、CaaS上的框架這個會成為新的熱點，是因為：首先這個技術是微服務的延續，而且是必然的延續，微服務已經解決了執行環境—容器的問題，又解決了框架的問題—Spring  Cloud和Spring Boot，下一步就是資料的問題了，而且資料服務化還沒有完全成熟。其實一個技術成為熱點的時候就是它的對應技術方案即將成熟又未成熟之時，容器和微服務成為業界注意力中心的時候都是這樣，也就是大家對它將懂未懂，最需要了解的時候，這種狀態就是技術熱點狀態。

以今年火爆的微服務為例，SpringBoot 很早就開始有研發；2014年以產品形式出現，但是當年月下載量是十萬級別，而今年單月的下載量就可以上千萬，兩年不到增長百倍，這就是熱點。根據資料服務化的相關開源專案在社群的反饋和貢獻量來看，現在也快達到了同樣的臨界點。

並且，建立大資料應用仍很痛

現在做大資料應用，需要裝很複雜的大資料環境。如果將其服務化，只需要點選建立即可，使用者不必關心後面 的GreenPlum、Hadoop等是怎麼安裝部署的。Hadoop那麼多元件，一個個安裝太麻煩了。

目前我們做的資料服務化的技術儲備包括大資料服務化、資料服務化、流資料服務化，這三類技術正在逐步達到生產可用.。因為大家做完應用之後就開始考慮資料怎麼辦，資料按照傳統方式來做是肯定沒有問題的，但是應用微服務之後，要求資料要和微服務應用對應，原來的巨石應用分拆為微服務了，那原來的大一統的大型資料庫，也要根據微服務進行拆分，拆分之後要分析資料是用傳統的SQL資料庫，還是新的NoSQL，或是快取加持久化。所以我認為這個就是將來熱點。以Spring Data為例，它負責資料抽象，至於最後落到哪類資料庫MySQL、Oracle甚至是NoSQL類的MongoDB的技術細節，開發者不必關心，到部署的時候再繫結，這就要求資料能夠服務化。

資料服務化具體的實現可能還是先從主流網際網路應用資料庫(比如MySQL， PostgreSQL)開始，然後逐漸覆蓋各種實現，比如Redis實現、MongoDB實現等。在解決完功能問題之後，要解決效能問題、安全問題，整個就會變成一個很大的熱點；最開始還是先面向開發者慢慢擴充套件到企業層面。

未來之路

在最開始，業內容易把雲和大資料搞混，認為Hadoop就是雲；後來慢慢理解其實是兩種涇渭分明不同的技術。而現在，大資料的進一步發展又離不開雲端計算能力：大資料處理最後給哪個應用使用，如何獲得大資料資訊價值以及提供給誰，需要經過應用平臺把大資料的能力體現出去。從這個應用的角度來看，我認為大資料應用需要落在PaaS上。另外，雲有很好的彈效能力，所以雲可以更好地支援大資料的彈性計算。

不過這新結合的難度要大於之前的熱點技術容器和微服務，如果說這後兩者解決的是點問題，那大資料和PaaS的結合則是面的問題，PaaS本身就是個很大的面。點點結合比較容易，但是面和麵結合難度就會比較大，我估計需要3-5年或者更長時間才能逐步發展成熟。