前不久，和一個朋友討論了一些關於企業雲平臺的問題。我們所討論的問題包括企業雲平臺的定位（上資源型平臺還是PaaS平臺？和公司的數字化戰略是什麼關係？）、技術選型（他們有VMware虛擬化平臺，現在要上雲平臺，是上OpenStack雲還是Kubernetes雲？）、落地方式（誰來買、誰來建、誰來運營、誰來用、誰來統籌協調等）等。朋友的團隊是研發團隊的一部分，已經在做 CI/CD 的一些嘗試，也有自己搭建一個基於Kubernetes的容器雲平臺，現在想進行推廣，不想一開始就遇到很多的問題。朋友感嘆他們單位IDC事業部的不配合，他們不接受容器雲平臺落到IDC；還感嘆到其他研發團隊的不配合，他們開發的應用不落到這個平臺；還感嘆公司領導想推動上雲，但是一直沒提出上雲戰略，因為很多原因，一直想招聘的技術負責人也沒到位，還沒想好來了後放在哪個層面，負責哪些事情。這個平臺，僅僅在前期階段，居然就牽扯到那麼多部門之間的利益關係，實在是有些超乎他當初的想象。 

上週的某個下午，肖力和我去找陳沙克聊天。在現場觀摩了他們正在實際使用的CI/CD流程後，我們有長達幾個小時的討論。 

兩次討論的問題，有很多的重合。我意識到，容器雲平臺、CI/CD、微服務等這些新的理念和技術已經被越來越多的企業所接受，但是，容器雲平臺的落地，似乎比想象中的要困難得多。本文在總結這些交流內容的基礎上，結合自己的一些理解和思考，試圖來對這個問題進行一些梳理。一家之言，僅供參考。

一些前提

本文中的一些名詞的含義和範圍如下：

• 企業：代表非網際網路大多數企業，不包括網際網路公司，以及非常大型的公司。

• 容器雲：指基於Kubernetes或Openshift的容器雲平臺。

• 企業IDC部門（資料中心部門）：企業中管理和運營企業IDC基礎設施以及雲平臺的部門。

• 企業業務開發中心：企業各業務應用系統開發團隊，通常有多個，分散在各業務單位之中。

• 當前容器雲平臺在企業落地的狀態：還處於早期階段，主要是利用容器雲平臺來執行新開發的網際網路應用，平臺規模往往不是很大，一般不超過50臺物理伺服器節點，在其上執行的企業應用數目大都在一兩百之內。

• 企業的IT狀態：大多都擁有 VMware + SAN 虛擬化環境，部分有OpenStack或者其它私有云環境，大部分企業尚不具有統一的基礎雲平臺。 

當前企業容器雲平臺的主要應用場景 

目前，企業主要的容器雲平臺需求是執行新開發的網際網路應用。這些應用的主要需求包括：

1. 需要快速上線和迭代，需求變化快，上線週期短。

2. 面向C類使用者，應用有彈性伸縮需求，比如在大促銷的時候。

3. 往往都是新開發的，部分採用微服務架構。 

當前以資源為中心的容器雲落地模式 

當前，企業要上容器雲平臺的話，採購和運營主體往往為IDC事業部。主要原因包括：

• 企業IDC事業部作為一個獨立的事業部，正在管理著企業的IDC和基礎雲平臺，因此企業領導層認為該事業部就應該是容器雲平臺負責單位。

• 把容器雲平臺看著以資源為中心的平臺，而企業IT資源一直是IDC事業部在管理和運營。

• 和IDC事業部相比，企業業務開發中心是分散的，並沒有統一的開發中心，因為也就無法與供應商簽署合同。 

這麼做會導致一系列問題。 

一方面，對企業（甲方）來說：

1. IDC 事業部為容器雲平臺的採購和運營方，但不是使用方，因此往往不瞭解該平臺的需求。其結果就是在採購的時候，不得不提供非常大的需求，為避免犯錯而求大求全。比如，要求能夠支撐2000臺物理機節點，要求支援複雜的網路環境，要求支援複雜的儲存環境，要求各種整合和環境打通等。但是，實際上，根據前面的討論，在早期階段，這些需求過大過全，往往造成不必要的浪費，並且導致真正應該被關注的主要矛盾反而被忽視，而且後期要改動該平臺的話代價將會非常大。

2. IDC事業部運營容器雲平臺的主要方式是賣容器，按照資源（容器和儲存）收費。因此，運管平臺也是以資源為中心的，比如提供映象倉庫、卷、服務編排、程式碼打包、應用商店、日誌和告警等功能。

3. IDC 事業部採購的容器雲平臺，其目標是作為執行在容器中的應用的執行平臺，這就要求業務開發部門能面向該平臺進行開發。但是，因為部門之間的部門牆和利益關係，很多時候這個雲平臺得不到業務開發部門的支援和配合，從而導致雲平臺閒置。

4. IDC事業部有可能與容器雲平臺存在一定程度的利益衝突。有了容器雲平臺之後，因為容器相比虛機和物理機的資源節省，IDC事業部能夠賣出去的資源可能會有減少；同時，容器雲平臺要求對IDC的基礎架構（比如網路架構）進行一些調整，這會破壞當前的穩定狀態；導致一些新需求，比如需要新的運維人員等。這些問題在某種程度上會削減IDC事業部做這事情的動力。

5. 企業業務開發部門，受到整個環境下CI/CD、敏捷、DevOps、微服務等新概念的持續薰陶，往往又有開發和執行新型的基於容器的應用的想法和動力。但是，IDC事業部主導購買的容器雲平臺，因為購買前沒能充分與業務開發團隊溝通需求，導致該平臺又無法滿足開發部門的要求。同時，由於平臺一開始就做得很大，再要做修改就已經很困難了。結果就是業務系統開發團隊得不到想要的容器雲平臺。 

另一方面，對容器雲平臺供應商（乙方）來說，這種模式的問題包括：

1. 很難在早期階段就從IDC事業部獲取到真正的容器雲平臺需求，導致有力無處使；相反，卻獲取到大量的不必要的需求，不得不投入大量精力去滿足這些需求。

2. 費力搭起來的容器雲平臺不被甲方的業務開發團隊認可，說平臺怎麼這麼爛，功能怎麼這麼差，總之就是各種不滿意。這反過來又會導致甲方對乙方的不認可。

3. 平臺賣不出好的價錢。容器雲平臺，同質化嚴重，競爭激烈，導致沒法賣出好的價錢。

以應用為中心的容器雲落地模式 

企業容器雲平臺的構建，不能單單只是容器雲平臺，而應該放在企業數字化轉型的大框架內在公司層面進行。  

上圖所要表達的一箇中心點是，要從公司/集團CIO層面對容器雲平臺進行統籌規劃：

• 確定容器雲平臺的定位。是與IaaS平臺類似的資源型平臺，還是公司的PaaS平臺？以及容器雲平臺在公司的數字化轉型戰略處於什麼位置？

• 確定各利益相關方，包括誰主導（CIO還是其它組織？）、誰是使用者、有哪些需求、誰落地（採購和部署）、誰運維運營等（IDC團隊，還是獨立的雲平臺團隊？）。

• 確定組織結構是否需要調整。

• 確定容器雲平臺上來後的各有關方面新的考核方式。 

結果：

• 從公司層面對容器雲平臺進行統籌管理。

• 容器雲平臺不能以資源為中心，而要以應用為中心，要覆蓋到應用的全生命週期。

• IDC事業部不再是容器雲平臺的主導方，而變成了落地的實施單位。

• 各業務開發團隊變成了容器雲平臺的主要需求提供方以及使用方。他們是平臺真正的使用者。 

這會帶來一些好處：

• 在採購前就能明確容器雲平臺的定位和需求，能做到有的放矢。根據實際需求，企業的容器雲平臺從小到大，週期性迭代，按需增長。

• 業務開發團隊將會獲得他們想要的容器雲平臺，從而實現真正的CI/CD，實現企業數字化轉型的目標之一，即快速釋出應用並進行迭代。

• IDC事業部有足夠的時間來消化容器雲平臺，而不是一開始一下子就收到一個巨型的雲平臺。

• 對企業來說，把容器雲平臺納入到企業數字化轉型戰略之中，其價值將會被放大。

• 對容器雲廠商來說，企業的數字化轉型是一個更大的蛋糕，而不只是在容器雲平臺的紅海中拼刺刀。 

以應用為中心的 CI/CD 流程 

上面說過，當下的企業容器雲，著眼於資源，而不是應用。從CI/CD角度，過於著眼於CD，也就是應用在平臺上的部署和執行。市面上的大部分的容器雲平臺，都支援各種部署方式，比如支援映象部署、支援從原始碼倉庫打包等。同時，著眼於彈性伸縮、網路架構、儲存支援等等。這些東西是有價值的，但是，在發展的初期階段，這些方面的需求其實倒沒那麼強烈，利用開源專案就能滿足實際絕大部分的需求了。同時，這部分是開源社群的重點方向，因此，雲平臺供應商最好是在社群的協作框架下來做這些方面的工作。 

下圖是沙克之前分享過的他們單位正在使用的CI/CD 流程圖：

在這裡，我也藉此機會感謝沙克和他的團隊，他們一直在無私地毫無保留地把好的東西分享出來。 

這圖我覺得有點複雜，因此把它做了一個分層，也許有助於理解： 

細節不再重複，只有以下幾點說明：

1. 該流程已經在沙克所在的單位進行推廣，有幾個較大的研發團隊已經在全部使用該流程。

2. 對業務應用開發團隊來說，跟之前相比，只有兩個改動：（1）把配置從程式碼中分離 （2）把日誌按要求輸出到統一的日誌平臺而不是寫到本地。

3. 該流程還處於不斷完善之中。基本的CI/CD 流程已經完全走通，外掛式的功能模組在逐步新增之中。

4. 基本上各種應用都可以容器化，換一種方式說，還沒有發現不能容器化的應用。當然了，由於這項工作開展時間還不太長，現在還只是把優先順序高的業務應用系統放到了容器雲平臺上。比如資料庫和快取這樣的服務，還是放在私有云環境中。

5. 容器雲平臺對底層資源有相當大的節省。

6. 現在他們面臨的一個挑戰是，如何把這套東西推廣到集團其它的開發中心，甚至集團外的使用者。 

對企業來說 

1. 不能以看待IaaS的以資源為中心的視角看待容器雲平臺。IaaS 平臺，實質上是資源型平臺，重點是將計算、網路和儲存的雲化，並以雲資源形式提供給租戶。它的出現，算不上質變，而更多的是一個量變的過程。而容器雲平臺的出現，應該被看著質變，它帶來的不止是能夠提供容器的資源平臺。這裡的質變，指的是容器雲平臺所能引起的質變，包括應用研發、執行、運維方式的革新，新應用為企業數字化轉型帶來的價值，對於企業業務中臺的推動等。因此，需要從整個公司的高度來看待容器雲平臺，也要從全公司範圍內來運營容器雲平臺。這就是前面圖中，為什麼要企業CIO來領導的原因。這應該是一個常設單位，而不應該是專案組那種做完了就撤了的那種單位。

2. 從虛擬化環境到容器雲環境之前，私有云環境階段（OpenStack私有云或其它私有云）並不是必經階段。容器雲環境可以執行在虛擬化環境中，甚至物理機環境中。

3. 正視容器雲平臺落地之困難。很多企業中，業務方和IDC事業部之間的距離很大，包括組織結構上和團隊人員之間的物理距離上。特別是一些大型企業，往往都有一個獨立的IT公司，為集團提供IT服務。過去，該公司提供的都是IT資源，因此往往有提供虛擬化或私有云環境，因此某種程度上可以看做集團的IDC中心。集團各業務開發中心分散在集團下屬的各個公司。這些開發中心和IDC中心之間，在組織結構、業務關係、物理距離等方面都距離遙遠。在這種情況下，容器雲平臺落地更是困難重重，甚至有時候會有容器雲平臺在IT子公司落地後閒置的情況發生。回憶當年，很多集團都是一紙紅標頭檔案，要求『必須使用虛擬機器，要使用物理機請報集團審批』，來推廣虛擬化或者私有云環境。現在，還能一紙紅標頭檔案，要求『應用必須上容器雲平臺、研發必須採用CI/CD模式』來推廣容器雲平臺嗎？我認為集團的CIO層面應該來好好考慮該問題。

4. 思考容器雲平臺相關團隊的考核模式。對IaaS這種資源型平臺，往往以規模、利潤、資源使用率、SLA等來考核，有些企業集團還會看上雲比率。但是對於容器雲平臺，除了這些以外，還要看它作為PaaS平臺產生了多少價值，比如有多少研發團隊採用了CI/CD流程，應用的單元測試比例是否有提高，應用開發週期是否有縮短等等。 

對容器雲平臺創業公司來說 

如果容器雲平臺創業公司要採用上述模式，那麼將面臨幾個挑戰：

1. 產品化困難。前述CI/CD流程中，涉及到非常多的元件和產品，流程上打通還較為容易，但是管理上是分散的。是否需要統一納管，能否做到統一納管，這是一個很大的產品和技術問題。

2. 構建真正能夠落地的CI/CD能力的困難。要提供能夠被客戶研發團隊願意接受的 CI/CD 諮詢能力和產品，需要有豐富的應用軟體開發和研發管理經驗作為基礎。而這些經驗，往往是底層雲平臺研發團隊所缺乏的。

3. 構建企業數字化轉型能力的困難。要從產品技術性質的雲平臺提供商，轉型為諮詢服務性質的企業數字化轉型能力提供商，這裡面有很大的鴻溝。也許，RedHat公司相對來說更具備這方面的潛力。我在寫這篇文章的時候，突然傳來IBM 340億美金收購紅帽的訊息，難道他們真想著把IBM的企業諮詢能力和RedHat 的容器雲平臺落地能力進行整合嗎？ 

而面對的機遇，則是從容器雲平臺的紅海中脫身，轉到企業數字化轉型的賦能者。這是一個更廣闊的世界，也有更多的機會等著去發現。

小結

對前面的主要觀點進行一下小結，主要歸納為以下幾點：

• 容器雲平臺的目標應該是以應用為中心的PaaS平臺，而不是以容器為中心的資源型CaaS平臺。

• 要從公司層面和高度來規劃和運營企業/集團的容器雲平臺，要把開發、運維、IDC團隊統統納入其中，不能指望一個團隊就能實現或推動應用的全生命週期管理轉型。

• 容器雲平臺的價值可以非常廣闊，就看如何想、和如何做。

• 企業的容器雲平臺應該是活的，而不是死的。它應從小到大，按需增長，而不是一上來就求大求全。

• 對容器雲平臺創業公司來說，需要思考如何做以應用為中心的雲平臺，以及如何賦能企業的數字化轉型。

謝謝您的閱讀，也歡迎您關注我的個人公眾號：