從應用的承載和部署方式這一角度看，一共經(jīng)歷了傳統(tǒng)的物理機架構、虛擬化架構、和現(xiàn)在的容器化三種架構。但是，容器并不是一種虛擬化技術，它與虛擬機有實質(zhì)性區(qū)別。

雖然把云分為IaaS、PaaS 和 SaaS 已經(jīng)好多年了，但是，它們只有的差別，一直是想得出但摸不到。對我個人來說，只有在搞了OpenStack 后才算了解了一些IaaS，只有在用了 OpenShift 后才算了解了一些PaaS。這兩個產(chǎn)品，對我都有云啟蒙性的幫助。

容器云平臺 CaaS 到底在左邊還是在右邊，這是一個問題，而且討論了不少年。至少對我來說，我之前是習慣性地把它歸到左邊，因為把容器類比為虛擬機。但是現(xiàn)在，我認為它更應該歸到右邊，成為企業(yè)PaaS平臺的支撐平臺。

過去的兩三年，容器相關的東西非常火熱。和所有新生事物一樣，一開始也是雜亂無章。

開源項目上，從 Docker，Swarm，Mesos，到 Kubernetes，再到 OpenShift，各種以容器為基礎的技術和產(chǎn)品層出不窮。

技術使用選型上，大家對于怎么用容器也是各有千秋。以阿里為例，他們主推的是富容器Pounch Container，而大家普遍采用的是 Docker 容器，還有 OpenStack 社區(qū)力推的 Kata。關于阿里的 Pounch Container，我個人很是疑問，他們是想成為主流呢，還是會被主流淹沒呢？會不會重走一遍用KVM 替代 Xen 的路子呢？

而對傳統(tǒng)企業(yè)來說，雖然越來越多的企業(yè)對它在感興趣，但是容器云落地更是問題多多，我這里列出的只是我接觸過的一些比較典型的問題。

我認為人們在為新事物做選擇題的時候，往往會用老的思維模式。以容器云平臺為例，就比較自然地把它歸類到已經(jīng)熟悉了的虛擬化和IaaS這一類的資源型平臺。這種做法就會產(chǎn)生很多問題。我認為這是一種錯位。

要解決這些問題，我認為需要將容器云平臺提升到 PaaS 層面。這里面有兩點需要提一下：

一是企業(yè)CIO在這里面的關鍵作用。當然了，在有些企業(yè)是別的類似的角色。只有這個角色，才能統(tǒng)一地將企業(yè)的開發(fā)和運維統(tǒng)一納入考慮范圍。

二是咨詢方案供應商?，F(xiàn)在，隨著新的技術的層出不窮，有些企業(yè)已經(jīng)有了一些無所適從，既想用，又不知道怎么用。這時候，咨詢公司就有了用武之地。

對企業(yè)用戶來說，他們更看重的是 PaaS 部分的功能，因為這些功能能直接對軟件開發(fā)和公司業(yè)務產(chǎn)生價值；對基于 Kubernetes 或 OpenShift 做產(chǎn)品化的公司來說，他們也應該更加聚焦 PaaS 部分。而 CaaS 部分，我認為，應該由相應的社區(qū)來主導。

找到了問題癥結和解決方法，那回答問題就相對容易了。

我之前看過一份麥肯錫關于企業(yè)數(shù)字化轉型的一個報告。報告里面提到，科技公司的兩個關鍵所在，就是流程標準化和工具賦能。那結合 PaaS 平臺能給用戶帶來的優(yōu)勢，其實正好，PaaS 平臺給企業(yè)所帶來的，正好就是流程標準化，包括開發(fā)流程、軟件架構、應用管理等，以及充分利用各種工具和平臺所帶來的工具賦能。

普遍認為，傳統(tǒng)企業(yè)數(shù)字化轉型需要經(jīng)歷三個階段，分別是 云IT，云 DT，和云 DI 三個階段。 這和將云分為 IaaS、PaaS 和 SaaS 三個層面有些巧合。
而在云IT階段，可以大概地認為是IaaS 階段，它的任務是向企業(yè)提供彈性云資源。 
云DT階段，是 PaaS 在企業(yè)中起關鍵作用的階段。PaaS 能帶來IT基礎設施、應用架構、開發(fā)流程、組織結構的互聯(lián)網(wǎng)化。 
云DI階段，是SaaS服務發(fā)揮關鍵作用的階段。AI 作為這一階段的主要驅動力之一，將以SaaS的形式，被嵌入到各種業(yè)務系統(tǒng)之中，來驅動業(yè)務創(chuàng)新。

現(xiàn)在和過去的混合云，我想把他們稱為混合云1.0，因為主要是網(wǎng)絡和存儲打通，但是在應用層面沒有打通。沒打通是有原因的，那是因為沒法打通，有很多原因，其中一條是因為格式不同?，F(xiàn)在有了容器云PaaS 之后，以容器為應用的統(tǒng)一載體，那打通就相對容易了。

另外，隨著混合云和多云概念的火熱，云管理平臺（CMP）的熱度似乎一下子上來了。我認為，在當前存在多種不同IT環(huán)境的時期，CMP 的價值是明顯的。但是，隨著容器云部署在各種IT環(huán)境之上，它自己就會承擔起部分CMP的功能，到那個時候，CMP 主要就會是PaaS平臺的CMP了。

階段1：孤島式 IT 環(huán)境。問題是資源浪費；不能滿足有快速需求的業(yè)務。

階段2：能解決階段1 的問題，但產(chǎn)生了新的問題，那就是無法滿足互聯(lián)網(wǎng)業(yè)務要求。當傳統(tǒng)行業(yè)不再滿足于在本行業(yè)的領先地位，希望能夠對接到互聯(lián)網(wǎng)業(yè)務的時候，上面的模式就會出現(xiàn)新的痛點。對接互聯(lián)網(wǎng)所面臨的最大的問題，就是巨大的用戶量所帶來的請求量和數(shù)據(jù)量，會是原來的N倍，能不能撐得住，大家都心里沒底。例如有的客戶推出互聯(lián)網(wǎng)理財秒殺搶購，原來的架構無法承載近百倍的瞬間流量。
階段3：解決之道

落地是一個非常復雜的問題，甚至都不完全是技術問題。它牽扯到IT架構、應用架構、組織架構多個方面。這不單單是一個技術問題，更是一個組織問題。在推動過程中，更加能夠感覺到康威定律的作用，需要更高層次管理者的介入，方能夠推動這些在企業(yè)的落地。

微服務和容器化的改造，更加容易發(fā)生在一個扁平化的組織里面，由一個能夠體會到基層技術細節(jié)的痛的CIO，高瞻遠矚地推動這件事情。這也是為什么微服務的落地一般率先落地在互聯(lián)網(wǎng)公司，因為互聯(lián)網(wǎng)公司的組織架構很平臺，哪怕是高層，也離一線非常的近，了解一線的痛。另一個原因是互聯(lián)網(wǎng)業(yè)務強大的驅動力。

在一些相對先進的企業(yè)，會在運維組和開發(fā)組之間，有個中間件組，或者叫做架構組，來負責推動微服務化改造的事情，架構組就既需要負責勸說業(yè)務開發(fā)實施微服務化，也要勸說運維組實施容器化，如果架構組的權威性不足，推動往往也會比較困難。

備注：這里有引用網(wǎng)易云劉超的一些觀點，特此感謝。

目標很明確，也有有價值，但是道路的困難大家都知道，那么還是從第一步做起吧。

一、OpenShift 作為 PaaS 平臺為紅帽帶來了很高的溢價。其實，從功能而論，OpenShift 相比 Kubernetes 并沒有新增多少新的功能。但是，它第一次打造了面向DevOps的PaaS平臺的產(chǎn)品，這是具有開創(chuàng)性的。就像新打開一扇大門一樣，門并沒有多少價值，但是門后的風景才是真正的價值。

二、根據(jù)前面的分析，PaaS 平臺在企業(yè)的落地需要有咨詢商這一角色的存在，而無疑IBM深諳這個領域。因此我對紅帽的PaaS產(chǎn)品和IBM的咨詢服務能力會怎么結合充滿期待。

三、IBM發(fā)的公告里面特意提到了混合云，不知道IBM 會不會利用 OpenShift 來實現(xiàn)我前面畫的那種混合云2.0。

另外，有時候我會想，為什么只有紅帽能推出OpenShift 這種PaaS平臺呢？我認為這和只有 Google 能推出 Kubernetes 是一樣的，那就是公司的基因。正是因為他們自己長期使用容器，長期實踐DevOps，才能比較自然地做出大家普遍能接受的產(chǎn)品。