容器雲平臺企業落地之向左走和向右走

 

前不久，和一個朋友討論了一些關於企業雲平臺的問題。咱們所討論的問題包括企業雲平臺的定位（上資源型平臺仍是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團隊通通歸入其中，不能期望一個團隊就能實現或推進應用的全生命週期管理轉型。

• 容器雲平臺的價值能夠很是廣闊，就看如何想、和如何作。

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

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

 

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