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

云原生

云原生基金會關于云原生的定義如下：

云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。

這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，云原生技術使工程師能夠輕松地對系統作出頻繁和可預測的重大變更。

可以看到云原生的目的是“夠構建容錯性好、易于管理和便于觀察的松耦合系統”，而采用的方法包括“容器、服務網格、微服務、不可變基礎設施和聲明式API”，而這一些還有個前提，需要是在“在公有云、私有云和混合云等新型動態環境中”。

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

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

圖片

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

不過，任何事情想做好，都不僅僅是技術的問題，許多云原生踐行者，尤其是在傳統企業實踐的同僚一定對此深有體會。云原生聚焦于技術，并沒有太多的意識形態因素，但不知不覺中技術改變了人的協作關系，由此引發的問題需要有別的方法來解決。

DevOps

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

DevOps 是一套實踐、工具和文化理念，可以實現軟件開發團隊和 IT 團隊之間的流程自動化和集成。它強調團隊賦能、跨團隊溝通和協作以及技術自動化。

DevOps 運動始于 2007 年左右，當時軟件開發和 IT 運營社區開始擔憂傳統的軟件開發模式。在此模式下，編寫代碼的開發人員與部署和支持代碼的運營人員會獨立工作。DevOps 這一術語由“開發”和“運營”兩個詞構成，它反映了將這些領域整合為一個持續流程的過程。

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

盡管敏捷開發方法已興起，但多年來，開發團隊和運營團隊仍然處于孤立狀態。DevOps 是協作工具和實踐的進一步發展，以更快速地發布更優質的軟件。

關于 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 解決的問題是“敏捷開發”的不同角色的豎井問題，而不僅僅是運維和開發兩個組織的溝通協調問題。此外，”敏捷開發“這個詞也隱含的說明 DevOps 的前提是敏捷開發，即使不是，也可能如 ThoughtWorks 網站上所提到的需要考量這些因素：

而且，DevOps 并不是打從一開始就適合每個組織——組織可能必須要做出一些改變。應時刻將康威定律銘記于心——這是一句格言，指出組織所設計的系統反映了組織自身的溝通結構。這意味著，如果您使用一個大型單體應用程序來運行絕大多數業務關鍵應用程序，那么 DevOps 可能不適合您的組織。DevOps 最適合那些能夠將工作分解成一個團隊可以擁有的若干離散小塊的組織。

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

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

但是對于大多數組織來說，未必有著這樣高能的開發人員，由”Dev“人員推動的”Ops“可能并不專業，再加上高高的部門墻，推動 DevOps 阻力非常大。

面對 DevOps 在傳統企業的這種不適，許多廠商也推出了改良版的 DevOps 理念。或者打著 DevOps 的旗號推出了許多 DevOps 產品，這些產品回避了 DevOps 中”麻煩“的部分，聚焦于工具，或多或少發揮了一些作用，尤其是在開發團隊中，但是往往沒有把能力延伸到運維階段。

還有許多組織，成立了一個專門的 ”DevOps 團隊“，負責DevOps工具和實踐的開展。這樣可以，但是這與開發團隊把控自己運維的原則有一些背離。

面對企業級研發的現狀，需要有一個新的指導方法來解決 DevOps 的問題。

平臺工程

DevOps 運動已經有了 15 年的歷史了，但對于大多數企業來說，并沒有實現全面的 DevOps，也沒有享受到其好處。這種自治的 DevOps 團隊不僅沒有改善組織的交付水平，反而帶來了許多安全問題。

另一方面，隨著云原生技術的發展，創建”平臺“不再是一件難事。一個圍繞平臺的社會技術管理實踐應運而生，這就是平臺工程。

根據 CNCF 平臺工程白皮書(翻譯)的說法：

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

可能用一張圖更清楚：

圖片

這里說的平臺，大家公認的是內部開發者平臺（Internal Developer Platform, IDP）。

這個平臺成為平臺團隊與應用團隊新的分工界面之所在。團隊之間的協作會調整為以下結構：

圖片

運維團隊的專家會變成賦能團隊，主要職責是將能力集成到平臺。原來許多手工的運維工作，已經在平臺上實現，而相關的人則可能要進入平臺研發團隊，負責將運維工作抽想到平臺。當然，可能也需要一個平臺產品經理把控平臺的方向，這可能是原來運維經理的角色。

平臺隱藏了包括 Kubernetes 的基礎設施的復雜性，也將最佳實踐封裝，因而研發團隊可以更輕松的按照業務需求構建自己的基礎設施環境，又不必擔心違反了安全規定，或者是沒有遵守最佳實踐。研發團隊可以通過平臺提供自助服務完成自己的大部分任務，可以為自己的應用”負責“，這與 DevOps 的原則相符。

那平臺工程中的”平臺“與之前的平臺的區別是什么？我覺得有幾個方面。

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

如果說 DevOps 是從敏捷開發向運維的延伸，那么平臺工程則是來自管理層對于 DevOps 的回應。就像以前的 ITIL 一樣，現在可以從組織架構的角度開始設計，而不必像 DevOps 那樣倒推改革。

三位一體的未來

現在我們再來看一下為什么是三位一體：

• 云原生技術為構建平臺提供了能力。對于大多數組織來說，在沒有云原生相關的技術之前，構建自己平臺的難度是非常大的，但現在云原生給許多組織近似的能力。
• DevOps 為協作提供了文化基礎。越來越多的案例證明，傳統的開發運維分工不利于高效的交付產品。鼓勵交流協作的 DevOps 文化已經成為了現代應用交付的基石，即使有了平臺，也需要不同的團隊保持相近的文化。
• 平臺工程則在組織層面給出了指導方針。平臺工程概念的推出，讓許多有相似想法的人有了共同的術語，可以為這個目標一起協作，從而實現整個行業的改變。

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

平臺工程是我們期望的一種狀態，云原生是我們達到這個狀態的工具，而要實現這個狀態，需要我們每個參與者永遠保持 DevOps 的協作精神，這就是三位一體。