本文內容是我今天在一個雲原生論壇上演講的材料，加上一些備註，現在分享給大家。 

從應用的承載和部署方式這一角度看，一共經歷了傳統的物理機架構、虛擬化架構、和現在的容器化三種架構。但是，容器並不是一種虛擬化技術，它與虛擬機器有實質性區別。

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

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

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

開源專案上，從 Docker，Swarm，Mesos，到 Kubernetes，再到 OpenShift，各種以容器為基礎的技術和產品層出不窮。

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

而對傳統企業來說，雖然越來越多的企業對它在感興趣，但是容器雲落地更是問題多多，我這裡列出的只是我接觸過的一些比較典型的問題。

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

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

一是企業CIO在這裡面的關鍵作用。當然了，在有些企業是別的類似的角色。只有這個角色，才能統一地將企業的開發和運維統一納入考慮範圍。

二是諮詢方案供應商。現在，隨著新的技術的層出不窮，有些企業已經有了一些無所適從，既想用，又不知道怎麼用。這時候，諮詢公司就有了用武之地。

對企業使用者來說，他們更看重的是 PaaS 部分的功能，因為這些功能能直接對軟體開發和公司業務產生價值；對基於 Kubernetes 或 OpenShift 做產品化的公司來說，他們也應該更加聚焦 PaaS 部分。而 CaaS 部分，我認為，應該由相應的社群來主導。

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

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

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

現在和過去的混合雲，我想把他們稱為混合雲1.0，因為主要是網路和儲存打通，但是在應用層面沒有打通。沒打通是有原因的，那是因為沒法打通，有很多原因，其中一條是因為格式不同。現在有了容器雲PaaS 之後，以容器為應用的統一載體，那打通就相對容易了。

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

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

階段2：能解決階段1 的問題，但產生了新的問題，那就是無法滿足網際網路業務要求。當傳統行業不再滿足於在本行業的領先地位，希望能夠對接到網際網路業務的時候，上面的模式就會出現新的痛點。對接網際網路所面臨的最大的問題，就是巨大的使用者量所帶來的請求量和資料量，會是原來的N倍，能不能撐得住，大家都心裡沒底。例如有的客戶推出網際網路理財秒殺搶購，原來的架構無法承載近百倍的瞬間流量。
階段3：解決之道

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

微服務和容器化的改造，更加容易發生在一個扁平化的組織裡面，由一個能夠體會到基層技術細節的痛的CIO，高瞻遠矚地推動這件事情。這也是為什麼微服務的落地一般率先落地在網際網路公司，因為網際網路公司的組織架構很平臺，哪怕是高層，也離一線非常的近，瞭解一線的痛。另一個原因是網際網路業務強大的驅動力。

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

備註：這裡有採納網易雲劉超的一些觀點，特此感謝。

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

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

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

三、IBM發的公告裡面特意提到了混合雲，不知道IBM 會不會利用 OpenShift 來實現我前面畫的那種混合雲2.0。

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