> 開發人員與運維人員是 IT 領域很重要的兩大人群，他們都會參與到各種業務系統的建設過程中去。DevOps 是近年間火爆起來的一種新理念，這種理念被很多人錯誤的解讀為“由開發人員（Dev）學習一大堆新的技能，從而掌握運維人員（Ops）該處理的事情”。然而能力越大，責任越大，當維持生產環境穩定為要位的運維責任落到開發人員的肩頭時，多數程式設計師發出了 [扯淡的DevOps，我們開發者根本不想做運維!](https://mp.weixin.qq.com/s/ZLIdcZOAAKHRl2KvRsxkGA) 的呼喊。那麼在雲原生時代，到底應該怎樣達成 DevOps 的體驗呢？我的觀點是由平臺工程來銜接這兩大人群，各自做好各自領域的事情。

## 令人“厭惡”的DevOps

首先，我非常希望你能先看一看引言中提到的 [扯淡的DevOps，我們開發者根本不想做運維!](https://mp.weixin.qq.com/s/ZLIdcZOAAKHRl2KvRsxkGA)  這篇文章。這篇文章從亞馬遜雲科技社群參與負責人 Emily Freeman 的一條推特入手，觀察了很多留言後，得出了文章標題這種類似咆哮一般的結論。從絕大多數回覆這條推特的  IT 從業者的口中，我聽到了對於將運維職責強加給開發人員這種 DevOps 體驗深惡痛絕。

開發人員對於 “誰構建，誰執行” 這種大義凜然的話表示無感，對於學習運維領域的新技能，亦或是將自己加入輪班支援人員的行列都感覺力不從心；運維人員的本職工作被剝離之後，則對本專業的前景惶惶不安，會害怕運維團隊的重新洗牌。

**開發與運維，的的確確是兩個不同的工種，有著類似“車床工與管道工”的區別。**

一些公司認為從表格中把大量的運維人員管轄的工作，一股腦的“左移”給開發人員就是 DevOps。在專業技能和日常工作領域帶來的缺口，可以透過開發人員的勤勞學習加以補足，然而在文化標籤領域的衝突，將會是導致開發人員厭惡這種 DevOps 體驗的根本原因。

##  DevOps 的真意與平臺工程

在我看來，DevOps 的真意是利用軟體工程思維，解決複雜且繁重的運維問題。真正適合做 DevOps 工作的人，是具備一定軟體工程能力的運維專家，在這裡，對運維能力的要求更重要。

**DevOps 工程師，可以透過設計或選擇一款平臺產品，來將複雜的運維工作抽象為產品化的運維特徵。從這個角度上講，開發人員將會是這個平臺產品的使用者，他們能夠在不瞭解複雜基礎設施的情況下，操作並維護應用程式。DevOps 工程師，應該是更懂開發人員需求的運維工程師**。

在追根溯源，找到了這條推特之後，我瞭解到了更多 IT 業內人士對 DevOps 的看法，從中找到了很多和我有共鳴的聲音。

> To me that's a sign we haven't made ops intuitive/easy enough for most devs to be able to handle it.
>
> 對我來說，這表明我們還沒有讓運維變得足夠直觀/簡單，以至於大多數開發人員都無法處理它。
>
> 																																—— @Liz Fong-Jones (方禮真)

> The "platform" should do the heavy lifting ops, lacking a real platform the ops team (DevOps/are/platform team) is the platform.  Devs can then focus on the application level operations of their apps using the knobs and levers provided by the platform.
>
> “平臺”應該做繁重的運維，缺乏真正的平臺時運維團隊就是平臺（DevOps/are/platform team）。然後，開發人員可以使用平臺提供的旋鈕和槓桿專注於其應用程式的應用程式級操作。
>
> 																																—— @pczarkowski

IT 行業近年來的發展趨勢，一直是不斷以平臺能力的提升，來解決複雜基礎設施的使用問題的。最開始，程式開發人員需要面對的是一臺物理伺服器，在缺乏運維能力的情況下，會由運維人員處理有關伺服器的一切，包括作業系統、網路配置等等。而到現在，程式開發人員已經很少需要跟伺服器打交道，甚至我見過的很多程式設計師並不掌握任何有關命令列的知識，就可以面向伺服器開發應用系統。這種轉變讓程式開發人員更加專注於業務程式碼本身，不必分神去做一些繁重且瑣碎的運維事務。帶來這種轉變的，是處於發展過程中的平臺工程，在讓基礎設施不斷變得簡單易用。

![1](https://static.goodrain.com/wechat/cloud-native-for-dev-ops/cloud-native-for-dev-ops-1.png)

最原始的裸機時代，並沒有開發運維之分。從底層基礎設施，一直到最頂層的業務系統都是同一批人在處理，這一批老程式設計師可以被稱為真正的全棧工程師。但毫無疑問，每一個開發人員，都希望能夠拋卻運維工作，更專注於自己開發的程式碼。

雲端計算時代的興起以虛擬化技術為基礎，軟體定義基礎設施變得炙手可熱起來。運維人員透過建設並維護一套 IaaS 雲平臺，將計算資源進行池化。開發人員按需申請自己需要的虛擬機器，從而得到一個作業系統介面來進行互動。與作業系統打交道，對開發人員依然是個巨大的挑戰，在 IT 領域，作業系統就像一座漂浮在海上的冰山，看似只露出冰山一角，然而其龐大的知識領域“身軀”都隱藏在海平面以下。和裸機時代相比較，開發人員和運維人員已經是兩個完全不同的群體，開發人員已經可以將自己的大部分精力放在業務系統上了。值得一提的是，對作業系統的掌控是不折不扣的運維領域技能。

容器技術以及 Kuberentes 的橫空出世，成為了雲端計算時代的分水嶺。軟體定義基礎設施的技術手段已經被髮揮到了極致，並且成為了現階段運維人員的標配技能。運維人員透過建設並維護一套 PaaS 雲平臺，終於將作業系統這一座最後的“大山”從開發人員的身上搬開。開發人員可以將更多的精力放在業務系統上了，除了他們依然需要學習容器技術和 Kubernetes ，至少他們要學會如何面向 Kubernetes 編寫業務系統所需的宣告式配置檔案。運維人員也透過 PaaS 雲平臺得到了自己想要的能力，容器技術和 Kubernetes 為他們帶來了彈性、便捷性的巨大提升。

跟隨時代的變遷，我得出了一個結論：**從開發人員與運維人員的關係上來看，IT 領域的演變，就是運維人員透過不斷向上接手開發人員眼中“跟開發無關的雜活”，來不斷為開發人員減負。開發人員在得到了解放後，可以將視角更多的聚焦在自己開發的業務系統上，釋放出自己的創造力。**

那麼跟隨結論中的趨勢，解放開發人員負擔的腳步絕對不會停止。DevOps 的工作，就是以開發人員為使用者群體，打造一套可以讓開發人員毫無障礙的使用基礎設施的“雲原生平臺“。

雲原生是一種面向雲設計應用的思想理念，充分發揮雲效能，組織內 IT 人員相互協作構建彈性可靠、松耦合、易管理、可觀測的雲應用系統，最終目標是提升軟體交付效率，降低運維複雜度。相比上文中提到的 PaaS 平臺，起碼要能夠避免開發人員去編寫複雜的 Kubernetes 宣告式配置檔案。

## 現有開源產品情況

在雲原生平臺領域，已經有不少專案在深耕。在這裡我列舉了三個各具特色的雲原生領域的平臺級產品：[Rancher](https://rancher.com/)、[KubeSphere](https://kubesphere.io/)、[Rainbond](https://www.rainbond.com/) ，後續的具體設計思路中，也會關注已有產品的實現。

這三款開源產品中，Rancher 是元祖級容器管理平臺，加入 SUSE 後，能夠明顯感覺在雲原生生態領域不斷髮力，Rancher 在各個層次可以整合的雲原生領域工具集已經非常豐富。Rancher 專注於幫助 DevOps 團隊面對多叢集情況下的運維和安全挑戰，從這一點來說，Rancher 更偏向於運維人員的使用體驗，而非面向開發人員提供更高的易用性。

KubeSphere 是來自青雲的 “面向雲原生應用的 容器混合雲”。除了對 Kubernetes 叢集內的各種資源的管理能力之外，Kubesphere 主打即插即用的外掛式生態擴充套件能力。

Rainbond 由北京好雨科技出品，從其介紹來看，它是一款主打易用性的雲原生多雲管理平臺。

## 降低業務部署難度

誠實地講，為現代開發語言開發而來的業務系統製作容器映象並不是什麼難以掌握的技能。但是不可否認的是，絕大多數 IT 從業人員依然會將製作映象這件事情歸為運維人員管理，而不是開發人員要關心的事情。

那麼 DevOps 工程師就有必要考慮，如何在開發人員對容器技術一無所知的情況下，使之可以直接從程式碼開始部署業務系統。

在這個方面，Heroku 是無可爭議的先行者。Heroku 是一個支援多種程式語言的雲平臺即服務產品。在2010年被 Salesforce.com 收購。 Heroku 作為最元祖的雲平臺之一，從2007年6月起開發，當時它僅支援 Ruby，但後來增加了對 Java、Node.js、Scala、Clojure、Python 以及 PHP 和 Perl 的支援。

開發人員在使用雲原生平臺時，只需要在介面中填寫程式碼倉庫的地址，對應的使用者名稱密碼等基礎資訊，就可以等待程式碼構建成為映象，並自由的執行在 Kubernetes 雲環境中去。

現有開源產品也在這方面給予了一定的支援：

|              |                           Rancher                            |                        KubeSphere                        | Rainbond                                                     |
| :----------: | :----------------------------------------------------------: | :------------------------------------------------------: | ------------------------------------------------------------ |
|   實現方式   | 透過整合 Epinio 專案，繼而深入整合了Paketo Buildpacks 來實現原始碼構建 |        提供定製化的基礎映象來結合使用者程式碼構建專案        | 基於 Heroku buildpack 定製的原始碼構建能力                     |
| 支援語言型別 |  Java、GraalVM、Golang、.NetCore、Nodejs、PHP、Ruby、Python  |                   Java、Nodejs、Python                   | Java、Golang、.NetCore、Nodejs、PHP、Python、Html靜態        |
|   使用體驗   |                   全部命令列操作，使用複雜                   | 圖形化操作，直接提供程式碼地址，構建產出映象，進而部署業務 | 圖形化操作，提供程式碼地址即可完成構建與部署，構建引數可配置，自由度高 |

更進一步的設計，是將程式碼的提交、檢測、部署等流程都整合到 CI/CD 流水線中去，開發人員只需要進行程式碼的提交，後續的流程會自動觸發完成，生成檢測報告，並完成程式碼的上線部署。而與之相關的第三方工具集，由 DevOps 團隊負責進行維護，開發人員可以充分的發揚拿來主義——拿來用就好。

在這方面 KubeSphere 做的更加全面，透過整合 Jenkins 實現了基於圖形化的流水線配置，這種方式對於以前就在使用 Jenkins 的團隊很友好。並且這種實現繼承了 Jenkins 生態原有的高自由度，可以更好的將其他第三方CI工具納入流程之中。

Rainbond 透過在構建流程中加入自制的自動觸發能力，也可以完成部分流水線工作。這種配置相對編寫 Jenkinsfile 來說更簡單一些，能夠滿足一些基本場景。然而其擴充套件性和自由度不足，能夠接納的第三方CI工具不夠豐富。

Rancher 並沒有在產品中整合 CI 方面的能力，在 CD 方面透過整合 fleet 專案來實現 GitOps ，使用的門檻較高。

![2](https://static.goodrain.com/wechat/cloud-native-for-dev-ops/cloud-native-for-dev-ops-2.png)

這樣的使用體驗還有一個優點，從始至終都不需要開發人員去編寫格式嚴苛的 Kubernetes 宣告式配置檔案。這對開發人員而言無疑是一個極大的利好，Kubernetes 雖好，但學習曲線非常陡峭。Kubernetes 預設透過 yaml 格式的宣告式配置檔案來部署業務系統，其中絕大多數的欄位定義都是運維特徵的體現，換句話說，絕大多數的欄位定義，都不應該是開發人員關注的事情。

DevOps 工程師應該抓住開發人員使用 Kubernetes 的痛點，避免其接觸複雜運維事務。雲原生平臺理應提供這種使用體驗，讓開發人員對 Kubernetes 完全無感知的情況下，完成業務系統的部署工作。換句話說，讓 Kubernetes 變得對開發人員“透明”。

從這個方面來說，透過對三款開源雲原生平臺的體驗，發現 Rancher 和 KubeSphere 雖說均可以基於圖形化介面來部署自己的業務元件，然而這些圖形化配置只是 yaml 宣告式配置檔案的 “翻譯”，對於 Kubernetes 不夠熟悉的使用者想要順利使用，還是有一定的門檻。Rainbond 這一點則做的非常不錯，部署業務時完全感受不到 Kubernetes 的存在，對於不熟悉 Kubernetes 的使用者而言非常友好。然而產品化定製的程度越高，跟隨 Kubernetes 前進的腳步就越難，上游 Kubernetes 不斷在推出新的功能特性，如何將新特性抽象成為使用者易於理解的功能將會是個挑戰。最新版本的 Rainbond 推出了 Kubernetes 屬性這一功能特性，允許使用者以 yaml 形式編輯 workload ，也是為打破自設的“天花板”。

## 降低操作基礎設施的難度

既然要設計一款平臺級的軟體產品，那麼就需要將複雜且不易被掌握的技術，抽象成為使用者易於理解的功能。DevOps 工程師設計的雲原生平臺產品，首要任務之一，是能夠降低開發人員使用基礎設施的門檻。這個章節主要討論的，是開發人員自行管理自己業務系統的運維特徵。

就拿儲存這件事來說，開發人員到底關注什麼呢？

圍繞儲存這個概念，我們可以說出一堆名詞，塊裝置、檔案系統、物件儲存、本地磁碟、磁碟陣列、NFS、Ceph等等。這些名詞毋庸置疑都與儲存相關，也的確會被各種業務系統所使用，但我相信，絕大多數的開發人員對這些名詞並不關心。

作為使用者，開發人員只關心一件事情，我所負責的業務系統，指定目錄中的資料需要被持久化的儲存下來。

大多數情況下，業務系統涉及到的儲存場景都應該是簡單的。在雲原生時代，我們甚至呼籲開發人員在開發業務系統的時候，應該儘量做到“無狀態化”，即在業務系統中，不存在限制例項橫向擴容的狀態資料，至少做到不同例項之間，資料可以共享。根據這一點，DevOps 工程師們完全可以為開發人員提供一個能夠適應大多數場景的預設儲存型別，各個雲廠商提供的 NAS 型別儲存是個很好的選擇。

使用複雜儲存的場景更多見於業務系統所呼叫的各種中介軟體中，比如資料庫需要高速穩定的塊裝置型別儲存，再比如大資料領域的“存算分離”場景下對接物件儲存等等。然而在大多數場景下，這些複雜中介軟體的維護並不是開發人員應該關心的事情。它們由專門的運維人員進行維護，開發人員只需要得到訪問它們的地址即可。

所以在這種簡單儲存場景下，開發人員最好可以僅僅填寫一下自己需要被持久化的目錄地址，由雲原生平臺來實現底層儲存的配置。對儲存基礎設施的操作，開發人員並不需要關心。

![3](https://static.goodrain.com/wechat/cloud-native-for-dev-ops/cloud-native-for-dev-ops-3.png)

從使用體驗上來說，Rancher 和 KubeSphere 可選擇的儲存型別很多，這是因為它們的產品生態優於 Rainbond ，比如 Rancher Lab 直接推出了輕量級的儲存解決方案 Longhorn，對於各大公有云廠商提供的儲存產品驅動也都有整合。 Rainbond 依然在易用性方面做的夠好，實現了上文中僅關注業務系統持久化目錄的使用體驗。然而僅對 NFS 型別的儲存支援比較完善，對於其他型別的儲存支援，需要在底層基礎設施中自建驅動，安裝起來不如前二者方便。

## 易於理解的應用模型

從工作負載層面上講，Kubernetes 只透過 Deployment、Statefulset 等抽象描述單個元件的特徵，然而多數情況下，開發人員開發出的業務系統會包含若干微服務元件。那麼如何對整個業務系統進行統一的管理就變成了一個問題。解決方案之一，就是透過雲原生應用平臺，在單個元件之上，抽象出應用這個概念。應用應該是由人為規定的一組服務元件（workload）組成，服務元件之間具有顯式或隱式的關聯呼叫關係，彼此之間有機組合成為一個整體，作為一套完整的業務系統對外提供服務。

開發人員可以將所有的服務元件視作一個整體來進行管理，而非機械的單獨管理每一個服務元件，這種操作體驗無疑會更簡單，也便於開發人員理解。對應用的管理可以包括統一的生命週期管理、統一的安裝升級解除安裝，靈活拼裝服務元件之間的呼叫關係，更合理的處理業務系統的交付流程。

目前 Kubernetes 領域內較為成熟的交付工具 Helm ，其設計也暗合此類模型，一條簡單的 `helm install xxx	` 命令，即可安裝起一大堆元件以及圍繞這些元件的配置。

![4](https://static.goodrain.com/wechat/cloud-native-for-dev-ops/cloud-native-for-dev-ops-4.png)

Rancher 並沒有實現自己的應用模型，其應用的安裝方式整合了 Helm ，並沒有體現出應用管理能力。

KubeSphere 則更進一步，在專案下的應用負載中提出了應用的概念。在應用中可以透過 Helm 或自建的形式部署服務，整合了微服務治理、單個元件的版本控制、路由管理、灰度釋出等能力。其對 Helm 模板的支援，使得其從理論上可以支援任何市面上已有的 Helm Chart 包的安裝部署。

Rainbond 的應用概念是最完善的，除了常規的生命週期操作、整個應用級的版本控制這樣的常規能力之外，還有些非常易用的自研功能，能夠簡化開發人員對自己應用的管理。比如基於泛解析域名機制實現的對外服務域名，點選開啟對外服務，就會生成一個公網可用的域名訪問自己的應用，這比一層一層的配置 Ingress 規則容易太多。又比如應用複製能力，可以批次的將整套應用複製到另一個工作空間，而不必重新手動搭一套。

應用模板是 KubeSphere 和 Rainbond 均提出的一個概念，應用模板存在的意義是可以將開發好的應用複製到不同的環境中去，是一種製備新一代製品並交付分發的技術。應用模板的基礎使用體驗，是可以快速方便的安裝整套應用系統，最好是一鍵化的體驗，KubeSphere 和 Rainbond 都提供了應用商店，供使用者快速安裝一些已經制作好的應用模板。應用模板更高層次的使用體驗，則是開發人員可以無任何技術負擔的開發出自己的應用模板，而不僅僅是從應用商店拉取別人製作好的應用模板。

## 易於掌控的微服務架構

微服務架構也是雲原生平臺不可缺少的一個元素。微服務架構旨在幫助開發人員建設高類聚、低耦合的現代應用系統，將以往煙囪式的業務系統架構，拆散成為一大堆彼此間更為獨立，包含自身功能特點的微服務模組。容器與相關編排技術的成熟，為微服務架構的落地打下了基礎。雲原生應用平臺，則為開發人員更簡單的入手微服務框架提供了可能。

雲原生平臺首選的微服務框架，應該是以 Istio、Linkerd 為代表的 Service Mesh 微服務框架， 也被稱為“服務網格”。相對於 Spring Cloud 、 Dubbo ，這種微服務框架提供了更高的自由度和適應性，開發人員不需要被某種開發語言或產品繫結，只需要迴歸網路程式設計即可將自己的業務系統連線成為一個整體。這裡要重點提出的是微服務架構對業務程式碼無侵入，只有無侵入的實現，才能最大限度降低開發人員花費精力學習其他領域知識的可能性。

DevOps 工程師可以透過設計雲原生平臺功能來進一步最佳化配置微服務的使用體驗，大膽設想一下，開發人員只需要在兩個服務元件之間拖動一條表徵微服務呼叫關係的線，就可以生成對應的微服務配置。這樣的操作體驗完全可以使註冊中心、控制平面這種微服務領域中複雜的概念對開發人員遮蔽。本質上講，維護註冊中心或者控制平面也是運維人員需要關心的工作。

![5](https://static.goodrain.com/wechat/cloud-native-for-dev-ops/cloud-native-for-dev-ops-5.png)

Rancher 由於其自身的定位，產品中沒有整合任何微服務相關的能力，使用者需要手動安裝 Istio 等微服務框架， 透過複雜的 yaml 配置，來引用微服務能力。

KubeSphere 和 Rainbond 都在應用層面預設整合了 Service Mesh 微服務框架，不同之處是前者整合了 Istio 方案，而後者的 Service Mesh 微服務框架是自研的。從使用體驗上來說， KubeSphere 產品化的包裝了 Istio，大幅度降低了 Istio 的使用體驗，但這不意味著使用者可以完全拋卻 Istio 這一層的概念，應用內部的拓撲依靠事先的配置來體現。Rainbond 自研的微服務框架易用性更高一些，已經實現了拖拉拽式的微服務拼裝模式，這一點還是很驚豔的。然而自己造的輪子過多，外部的其他方案有好的特性時想要快速整合接納，就需要在微服務規範的對接層次更上層樓，畢竟 Istio、Linkerd 這些 Service Mesh 微服務框架一統江湖的情況下，其他生態的結合都會以它們為標準，而非自研框架。目前 Rainbond 也提供整合方式接納了 Istio 治理模式，但還沒有得到大量使用者的使用驗證。

## 對運維人員友好

之前的探討，都是以開發人員為受眾去考量的，但我們不應該忘記維護著底層基礎設施正常工作的運維人員。任何軟體的穩定執行都只是暫時的，出問題只是一個時間問題。雲原生平臺本身作為開發人員的基礎設施，也需要被持續的維護。如何最佳化運維人員的管理體驗，也是在雲原生平臺設計過程中的重點。

當今時代，Kubernetes 的使用與維護、容器化技術都已經成為了運維人員的標誌性技能，對作業系統的掌控以及命令列工具的使用則是運維人員的看家本領。所以雲原生平臺在面向運維人員的設計中，不必要在易用性或圖形化上考慮過多，更多要考慮的是可靠性、安全性、底層基礎設施生態的相容性。

![6](https://static.goodrain.com/wechat/cloud-native-for-dev-ops/cloud-native-for-dev-ops-6.png)

Rancher 在運維層面的表現非常出眾。得益於其豐富的周邊生態，Rancher 在各個領域都得到了自家其他產品的原生支援。首當其衝的就是 RKE/RKE2/K3S 這幾個 kubernetes 發行版，降低了不同場景下 Kubernetes 的安裝難度。容器安全方面有 NeuVector 容器安全平臺負責全生命週期的管理。基礎設施方面有輕量級分散式塊裝置儲存系統 Longhorn。除了豐富的生態之外，Rancher 產品介面的設計尤其符合運維人員的喜好。個人體驗過程中認為 Kubectl Shell 非常驚豔，這是一個分屏式的命令列操作介面，運維人員可以一邊在下半分屏 Shell 互動分頁中敲命令，上半分屏中實時觀察操作結果。

KubeSphere 也比較適合運維人員維護和管理。尤其是在監控報警層面，KubeSphere 製作了大量符合自身產品理念的可觀測性圖表，體驗很不錯。對於叢集或節點的控制也做了圖形化的設計，便於運維人員掌控。生態方面，KubeSphere 背靠青雲，也在不斷髮展圍繞自身的雲原生專案，可以利用自家的驅動對接青雲的雲平臺、雲端儲存，以及負載均衡等基礎設施。其內建的可插拔式的元件管理系統，可以快速擴充套件出平臺級的其他能力。

Rainbond 對運維人員不太友好，甚至是一種“遺忘”了運維人員的設計理念。體驗之後發現所有的運維操作依然離不開登入伺服器這個前提。沒有提供圖形化亦或者命令列互動介面來操作叢集和節點。對接多叢集時，提供了圖形化安裝 Kubernetes 叢集繼而安裝 Rainbond 的能力，體驗還算不錯。產品生態相較 Rancher 不夠豐富，好在官方提供了很多文件支撐，來對接很多其他的雲原生生態產品。比如提供文件對接阿里雲ACK、華為雲CCE、騰訊雲TKE等雲基礎設施的安裝方式。

在使用者許可權管理方面，Rancher 、KubeSphere 沿用了 Kubernetes RBAC 這一套體系，Rainbond 依然有些特立獨行，許可權管理體系並沒有完全對照原生 Kubernetes RBAC 設計，甚至在使用 Rainbond 的時候，完全沒有感覺到有 RBAC 體系的存在。對接外部的身份管理系統時，KubeSphere 主推 LDAP 協議，而 Rainbond 使用了 Oauth2.0 協議的實現。

其他方面，諸如穩定性、行為審計、監控報警方面三款產品各自有實現，沒什麼太大的區別。

## 寫在最後

相對於招聘文武全才的“全棧式”開發人員搞定所有的 IT 事務，我更傾向於找到不同領域的專家來搞定各自領域的問題。在運維事務的領域裡，構建並維護一套功能齊備的雲原生平臺，能夠更好的解決 IT 業務系統從底層基礎設施到開發過程，最終到達生產上線的運維支援問題。這是對 DevOps 理念比較合理的一種落地方式。

文中重點提到了 Rancher 、KubeSphere、Rainbond 這三款雲原生平臺級產品各自不同的實現。

歸納起來，Rancher 更偏向運維人員使用，來管理企業內部的各類 Kubernetes 基礎設施。開發人員想要很好的使用 Rancher ，必須具備 Kubernetes 操作能力以及容器化技術。從這個角度來說，Rancher 的定位應該位於 PaaS 與雲原生平臺之間。

KubeSphere 和 Rainbond 都屬於以應用為中心的雲原生平臺產品，二者的設計思路不同之處見仁見智。 KubeSphere 以可插拔式框架納入了雲原生領域的其他專案為己所用，將這些專案的能力串聯起來為終端使用者提供一站式的使用體驗，然而這樣的使用體驗必然是有門檻的，每納入一個專案，終端使用者難免需要同時學習該專案和 KubeSphere 自身。Rainbond 的設計思路則更加的內聚，多數功能都自研。這樣做的好處是功能體系高度自我契合，終端使用者的使用體驗非常好，功能之間銜接關聯更符合人類思維，卻容易自我限定，提高了納入其他雲原生生態的門檻。

DevOps 團隊可以直接選擇既有的雲原生平臺級產品使用，也可以基於開源專案二次開發。更落地的方式是選擇其中多款進行混合部署，各取所長，以提到的三款產品為例，DevOps 團隊完全可以選擇 Rancher + KubeSphere 或 Rancher + Rainbond 的組合，它們之間並沒有衝突，向下對接基礎設施，管理叢集的安全性與合規性是 Rancher 最擅長的事情，向上為最終開發人員提高易用的雲原生平臺的使用體驗則交給 KubeSphere 或 Rainbond，最終的目標，是開發人員透過雲原生平臺的支援，從以往的運維工作之中解放出來，將精力更多的放在所開發的業務之上。

雲原生時代的DevOps平臺設計之道

相關文章