云原生、DevOps和平臺(tái)工程都是十分繁雜的概念，其邊界不斷延伸，有許多重合的部分。三者的出發(fā)點(diǎn)卻并不相同，卻可以形成有機(jī)的整體。

云原生

云原生基金會(huì)關(guān)于云原生的定義如下：

云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動(dòng)態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API。

這些技術(shù)能夠構(gòu)建容錯(cuò)性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動(dòng)化手段，云原生技術(shù)使工程師能夠輕松地對(duì)系統(tǒng)作出頻繁和可預(yù)測的重大變更。

可以看到云原生的目的是“夠構(gòu)建容錯(cuò)性好、易于管理和便于觀察的松耦合系統(tǒng)”，而采用的方法包括“容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API”，而這一些還有個(gè)前提，需要是在“在公有云、私有云和混合云等新型動(dòng)態(tài)環(huán)境中”。

這不像一個(gè)定義，倒是像一個(gè)“萬能”盒子，似乎可以容納任何“正確的”方法。不過這個(gè)定義與實(shí)際情況匹配，開發(fā)與運(yùn)維面對(duì)的問題很多，并沒有單一方法來解決。人們?cè)趯?shí)踐中可能發(fā)現(xiàn)某個(gè)工具很好用，然后漸漸發(fā)現(xiàn)其背后的思想是成功的關(guān)鍵，于是這個(gè)思想被挖掘出來成為一種方法論，然后衍生出更多的工具。一個(gè)很棒的例子就是 Kubernetes 的聲明式 API，以及其實(shí)現(xiàn)方式 Operator，許許多多的工具，都借用了這個(gè)思想，實(shí)現(xiàn)了自己的 Operator，共同組成了了一個(gè)松耦合的復(fù)雜的系統(tǒng)。這些方法最后成為了云原生的一個(gè)方法。

可以看出來，“云原生”只是告訴你這有一套方法很好。工具提供者可以用這個(gè)方法開發(fā)工具，最終用戶應(yīng)該用云原生的工具。但是基于這個(gè)思想的工具太多了，該如何選擇組合成了一個(gè)大問題，所以云原生基金會(huì)給大家展示了這樣一個(gè)圖景：

圖片

可怕，所以做好云原生的一個(gè)關(guān)鍵問題是如何選好工具，這就要求 CTO 和架構(gòu)師需要持續(xù)關(guān)注云原生解決方案，需要更多的同行溝通，這也是為什么我們的公眾號(hào)“云云眾生s”為什么要一直給大家介紹一些工具。

不過，任何事情想做好，都不僅僅是技術(shù)的問題，許多云原生踐行者，尤其是在傳統(tǒng)企業(yè)實(shí)踐的同僚一定對(duì)此深有體會(huì)。云原生聚焦于技術(shù)，并沒有太多的意識(shí)形態(tài)因素，但不知不覺中技術(shù)改變了人的協(xié)作關(guān)系，由此引發(fā)的問題需要有別的方法來解決。

DevOps

與云原生相比，DevOps 有著眾多存在差異的定義，先看看 Atlassian 的定義：

DevOps 是一套實(shí)踐、工具和文化理念，可以實(shí)現(xiàn)軟件開發(fā)團(tuán)隊(duì)和 IT 團(tuán)隊(duì)之間的流程自動(dòng)化和集成。它強(qiáng)調(diào)團(tuán)隊(duì)賦能、跨團(tuán)隊(duì)溝通和協(xié)作以及技術(shù)自動(dòng)化。

DevOps 運(yùn)動(dòng)始于 2007 年左右，當(dāng)時(shí)軟件開發(fā)和 IT 運(yùn)營社區(qū)開始擔(dān)憂傳統(tǒng)的軟件開發(fā)模式。在此模式下，編寫代碼的開發(fā)人員與部署和支持代碼的運(yùn)營人員會(huì)獨(dú)立工作。DevOps 這一術(shù)語由“開發(fā)”和“運(yùn)營”兩個(gè)詞構(gòu)成，它反映了將這些領(lǐng)域整合為一個(gè)持續(xù)流程的過程。

可以看到，相對(duì)于云原生比較關(guān)注方法和工具，DevOps 包含了“實(shí)踐、工具和文化理念”三個(gè)方面，但是其突出的價(jià)值觀是什么，可以從其起源追溯。Atlassian 在DevOps 歷史中寫到：

盡管敏捷開發(fā)方法已興起，但多年來，開發(fā)團(tuán)隊(duì)和運(yùn)營團(tuán)隊(duì)仍然處于孤立狀態(tài)。DevOps 是協(xié)作工具和實(shí)踐的進(jìn)一步發(fā)展，以更快速地發(fā)布更優(yōu)質(zhì)的軟件。

關(guān)于 DevOps 的起源，馬丁·福勒的Bliki中有以下描述：

Agile software development has broken down some of the silos between requirements analysis, testing and development. Deployment, operations and maintenance are other activities which have suffered a similar separation from the rest of the software development process. The DevOps movement is aimed at removing these silos and encouraging collaboration between development and operations.

按照此文的說法，DevOps 解決的問題是“敏捷開發(fā)”的不同角色的豎井問題，而不僅僅是運(yùn)維和開發(fā)兩個(gè)組織的溝通協(xié)調(diào)問題。此外，”敏捷開發(fā)“這個(gè)詞也隱含的說明 DevOps 的前提是敏捷開發(fā)，即使不是，也可能如 ThoughtWorks 網(wǎng)站上所提到的需要考量這些因素：

而且，DevOps 并不是打從一開始就適合每個(gè)組織——組織可能必須要做出一些改變。應(yīng)時(shí)刻將康威定律銘記于心——這是一句格言，指出組織所設(shè)計(jì)的系統(tǒng)反映了組織自身的溝通結(jié)構(gòu)。這意味著，如果您使用一個(gè)大型單體應(yīng)用程序來運(yùn)行絕大多數(shù)業(yè)務(wù)關(guān)鍵應(yīng)用程序，那么 DevOps 可能不適合您的組織。DevOps 最適合那些能夠?qū)⒐ぷ鞣纸獬梢粋€(gè)團(tuán)隊(duì)可以擁有的若干離散小塊的組織。

確實(shí)如此，并不是每個(gè)組織都能開展 DevOps。一個(gè)組織的部門墻越高，越難以實(shí)施 DevOps。

盡管不同的組織對(duì)于 DevOps 的定義有許多差異，但從前面的描述中，我們也能發(fā)現(xiàn) DevOps 是敏捷開發(fā)的延伸。較早采用 DevOps 的組織本身的部門墻不高，開發(fā)人員的眼界和能力都比較好，所以能夠快速的吸收運(yùn)維方面先進(jìn)的最佳實(shí)踐，DevOps 實(shí)踐也能實(shí)現(xiàn)比較好的效果。

但是對(duì)于大多數(shù)組織來說，未必有著這樣高能的開發(fā)人員，由”Dev“人員推動(dòng)的”O(jiān)ps“可能并不專業(yè)，再加上高高的部門墻，推動(dòng) DevOps 阻力非常大。

面對(duì) DevOps 在傳統(tǒng)企業(yè)的這種不適，許多廠商也推出了改良版的 DevOps 理念。或者打著 DevOps 的旗號(hào)推出了許多 DevOps 產(chǎn)品，這些產(chǎn)品回避了 DevOps 中”麻煩“的部分，聚焦于工具，或多或少發(fā)揮了一些作用，尤其是在開發(fā)團(tuán)隊(duì)中，但是往往沒有把能力延伸到運(yùn)維階段。

還有許多組織，成立了一個(gè)專門的 ”DevOps 團(tuán)隊(duì)“，負(fù)責(zé)DevOps工具和實(shí)踐的開展。這樣可以，但是這與開發(fā)團(tuán)隊(duì)把控自己運(yùn)維的原則有一些背離。

面對(duì)企業(yè)級(jí)研發(fā)的現(xiàn)狀，需要有一個(gè)新的指導(dǎo)方法來解決 DevOps 的問題。

平臺(tái)工程

DevOps 運(yùn)動(dòng)已經(jīng)有了 15 年的歷史了，但對(duì)于大多數(shù)企業(yè)來說，并沒有實(shí)現(xiàn)全面的 DevOps，也沒有享受到其好處。這種自治的 DevOps 團(tuán)隊(duì)不僅沒有改善組織的交付水平，反而帶來了許多安全問題。

另一方面，隨著云原生技術(shù)的發(fā)展，創(chuàng)建”平臺(tái)“不再是一件難事。一個(gè)圍繞平臺(tái)的社會(huì)技術(shù)管理實(shí)踐應(yīng)運(yùn)而生，這就是平臺(tái)工程。

根據(jù) CNCF 平臺(tái)工程白皮書(翻譯)的說法：

分布式計(jì)算中的平臺(tái)是為多種用途提供通用支持能力和服務(wù)的層。平臺(tái)為獲取、使用和管理這些功能和服務(wù)提供一致的用戶體驗(yàn)，包括 Web 門戶和頁面、特定于場景的代碼模板、可自動(dòng)化的 API 和命令行工具。

可能用一張圖更清楚：

圖片

這里說的平臺(tái)，大家公認(rèn)的是內(nèi)部開發(fā)者平臺(tái)（Internal Developer Platform, IDP）。

這個(gè)平臺(tái)成為平臺(tái)團(tuán)隊(duì)與應(yīng)用團(tuán)隊(duì)新的分工界面之所在。團(tuán)隊(duì)之間的協(xié)作會(huì)調(diào)整為以下結(jié)構(gòu)：

圖片

運(yùn)維團(tuán)隊(duì)的專家會(huì)變成賦能團(tuán)隊(duì)，主要職責(zé)是將能力集成到平臺(tái)。原來許多手工的運(yùn)維工作，已經(jīng)在平臺(tái)上實(shí)現(xiàn)，而相關(guān)的人則可能要進(jìn)入平臺(tái)研發(fā)團(tuán)隊(duì)，負(fù)責(zé)將運(yùn)維工作抽想到平臺(tái)。當(dāng)然，可能也需要一個(gè)平臺(tái)產(chǎn)品經(jīng)理把控平臺(tái)的方向，這可能是原來運(yùn)維經(jīng)理的角色。

平臺(tái)隱藏了包括 Kubernetes 的基礎(chǔ)設(shè)施的復(fù)雜性，也將最佳實(shí)踐封裝，因而研發(fā)團(tuán)隊(duì)可以更輕松的按照業(yè)務(wù)需求構(gòu)建自己的基礎(chǔ)設(shè)施環(huán)境，又不必?fù)?dān)心違反了安全規(guī)定，或者是沒有遵守最佳實(shí)踐。研發(fā)團(tuán)隊(duì)可以通過平臺(tái)提供自助服務(wù)完成自己的大部分任務(wù)，可以為自己的應(yīng)用”負(fù)責(zé)“，這與 DevOps 的原則相符。

那平臺(tái)工程中的”平臺(tái)“與之前的平臺(tái)的區(qū)別是什么？我覺得有幾個(gè)方面。

• 平臺(tái)的用戶不同。傳統(tǒng)的平臺(tái)的用戶可能是運(yùn)維團(tuán)隊(duì)，而內(nèi)部開發(fā)者平臺(tái)的用戶是開發(fā)者，也就是應(yīng)用團(tuán)隊(duì)。
• 兩個(gè)平臺(tái)的建設(shè)者不同。傳統(tǒng)的平臺(tái)往往是單獨(dú)的研發(fā)團(tuán)隊(duì)研發(fā)，這個(gè)團(tuán)隊(duì)最強(qiáng)的能力的是開發(fā)。這個(gè)模式的一個(gè)原因是之前的工具比較原始，需要較高的抽象才能運(yùn)行，對(duì)研發(fā)的要求更高。這個(gè)模式的一個(gè)問題是運(yùn)維知識(shí)與平臺(tái)的分離，作為平臺(tái)的使用者，他們的知識(shí)并不能很好的集成到平臺(tái)上。而內(nèi)部開發(fā)者平臺(tái)的則是偏向運(yùn)維的平臺(tái)團(tuán)隊(duì)建設(shè)，各類運(yùn)維專家更加清楚日常有哪些任務(wù)，可以更好的結(jié)合運(yùn)維專業(yè)知識(shí)。
• 平臺(tái)的建設(shè)思路不同。傳統(tǒng)的平臺(tái)往往是專注于能力封裝，也就是將以前各種運(yùn)維任務(wù)簡化。而內(nèi)部開發(fā)者平臺(tái)則更注重實(shí)際的研發(fā)流程，關(guān)注如何幫助開發(fā)者快速的實(shí)現(xiàn)自己的目標(biāo)。

如果說 DevOps 是從敏捷開發(fā)向運(yùn)維的延伸，那么平臺(tái)工程則是來自管理層對(duì)于 DevOps 的回應(yīng)。就像以前的 ITIL 一樣，現(xiàn)在可以從組織架構(gòu)的角度開始設(shè)計(jì)，而不必像 DevOps 那樣倒推改革。

三位一體的未來

現(xiàn)在我們?cè)賮砜匆幌聻槭裁词侨灰惑w：

• 云原生技術(shù)為構(gòu)建平臺(tái)提供了能力。對(duì)于大多數(shù)組織來說，在沒有云原生相關(guān)的技術(shù)之前，構(gòu)建自己平臺(tái)的難度是非常大的，但現(xiàn)在云原生給許多組織近似的能力。
• DevOps 為協(xié)作提供了文化基礎(chǔ)。越來越多的案例證明，傳統(tǒng)的開發(fā)運(yùn)維分工不利于高效的交付產(chǎn)品。鼓勵(lì)交流協(xié)作的 DevOps 文化已經(jīng)成為了現(xiàn)代應(yīng)用交付的基石，即使有了平臺(tái)，也需要不同的團(tuán)隊(duì)保持相近的文化。
• 平臺(tái)工程則在組織層面給出了指導(dǎo)方針。平臺(tái)工程概念的推出，讓許多有相似想法的人有了共同的術(shù)語，可以為這個(gè)目標(biāo)一起協(xié)作，從而實(shí)現(xiàn)整個(gè)行業(yè)的改變。

如前面所述，這三個(gè)概念有著許許多多不同的演繹，但是在本文我希望大家抓住各自的重點(diǎn)，能夠體會(huì)到三者對(duì)我們這個(gè)行業(yè)的意義。

平臺(tái)工程是我們期望的一種狀態(tài)，云原生是我們達(dá)到這個(gè)狀態(tài)的工具，而要實(shí)現(xiàn)這個(gè)狀態(tài)，需要我們每個(gè)參與者永遠(yuǎn)保持 DevOps 的協(xié)作精神，這就是三位一體。