我已經(jīng)當了幾年的平台工程師。我喜歡這(zhè)份工作，對(duì)此充滿了激情。

在本文中，我將(jiāng)讨論我的專業知識所帶來的好(hǎo)處。由于平台工程師的角色還(hái)比較新，所以對(duì)于這(zhè)個角色的需求和所提供的價值還(hái)沒(méi)有形成(chéng)廣泛的共識。假如你找三個人詢問他們對(duì)這(zhè)個問題的意見，你會(huì)得到四個答案——至少在細節方面(miàn)，我不會(huì)感到奇怪。另外，由于平台工程與基礎設施非常接近，不存在直接和明顯的價值可見性，想想前端工程，它就(jiù)可以顯示所提供的價值。

不管怎麼(me)說(shuō)，我真正的動機是要清楚自己對(duì)這(zhè)個問題的看法，而在這(zhè)個過(guò)程中，寫作幫助了我。

因爲我現在隻研究雲基礎設施，因此我所有的論點，以及對(duì)基礎設施資源的提及，都(dōu)應該放在這(zhè)個背景下來看；不過(guò)我猜測，很多論斷在更傳統的數據中心，甚至更寬泛的範圍應該都(dōu)可以成(chéng)立。

在我提出有價值的論點之前，我認爲明智的做法是先簡單回顧一下互聯網曆史。我所許諾的價值將(jiāng)會(huì)得到體現，這(zhè)不僅是爲了好(hǎo)玩，而且是爲了描繪一幅圖景。我當然是基于自己的個人經(jīng)曆，所以你的情況可能(néng)會(huì)不一樣。

雲計算簡史

雲計算是指計算機系統資源的按需可用性，尤其是數據存儲（雲存儲）和計算能(néng)力，而用戶無需直接主動管理。

 

——維基百科：雲計算詞條

随著(zhe)現代雲計算的出現，計算環境發(fā)生了一個重大變化：硬件現在有了一個按需的 API。實際上，并不是硬件，而是資源之前隻能(néng)通過(guò)硬件來表達。這(zhè)種(zhǒng)情況不是一朝一夕就(jiù)能(néng)發(fā)生的，沒(méi)有第一家廠商使用“雲”這(zhè)個詞，并且爲所有人都(dōu)指定了新的标準（即使有人可能(néng)會(huì)這(zhè)樣說(shuō)）。這(zhè)曾經(jīng)是，現在依然是，一個由必要性和需求驅動的過(guò)程。這(zhè)也不是一個進(jìn)程，而是多個進(jìn)程同時(shí)運行，并且以某種(zhǒng)程度向(xiàng)同一方向(xiàng)發(fā)展。

對(duì)于平台工程，我認爲兩(liǎng)個因果概念或技術尤其重要，它們是：

虛拟化。盡管這(zhè)一概念本身已經(jīng)存在了幾十年，而且很久以前就(jiù)被用來處理邊緣案例和大型企業解決方案，但是在我看來，第一個對(duì)更大的市場産生重大影響的實施是虛拟服務器。虛拟服務器允許數據中心的所有者將(jiāng)其昂貴的硬件分割爲更小的塊，以供自己使用，并使之更容易銷售給他人。對(duì)現有資源的有效利用更爲有效。但更重要的是，如果能(néng)夠在一個物理服務器中創建多個虛拟服務器，那麼(me)下一個邏輯步驟當然是自動執行這(zhè)個過(guò)程，然後(hòu)再進(jìn)一步：自動化的工具。基礎設施 API 應運而生。不隻是簡單地管理虛拟服務器，還(hái)包括網絡防火牆、CDN、數據庫等等，這(zhè)些都(dōu)是虛拟的，可以通過(guò) API 來實現。

容器化（與編排）：從嚴格意義上說(shuō)，容器化是虛拟化的一個具體實現。但我仍然認爲它應該有介紹自己的一段内容，因爲沒(méi)有技術能(néng)像容器化一樣，在基礎設施提供商和基礎設施用戶之間架起(qǐ)橋梁。封裝在容器内的應用使雙方在共同點上達成(chéng)一緻。隻有适合于容器，我們才能(néng)運行它。而且，從容器化基礎設施的角度來看，也需要編排：在隔離的環境下，大規模地運行标準化容器。

新範式

以上所提到的技術的廣泛應用（我相信還(hái)有其他因素）引起(qǐ)了許多思考，并導緻了一系列新的觀點和後(hòu)續業務的出現。在此，我要再次強調一些我認爲特别具有影響力并與背景相關的因素：

微服務：微服務是對(duì)應用設計和實現的一種(zhǒng)完全不同的觀點。這(zhè)使你可以將(jiāng)最複雜的應用視爲一組不同的、潛在的、相互連接的功能(néng)。這(zhè)一思路不僅适用于實現（構建“簡化”的微服務），還(hái)适用于組織（擁有整體中定義良好(hǎo)的部分），當然，對(duì)部署和執行也有直接的影響：單體設計通常具有對(duì)操作系統和硬件（資源）的大量高度特定需求，而封裝在容器中的微服務可以在更相同的基礎設施中工作，不是作爲一個整體，而是按照服務（部分）來擴展，以更小的爆炸半徑單獨失敗，等等。這(zhè)并不意味著(zhe)每個應用都(dōu)是（或者應該是）從一開(kāi)始就(jiù)被設計成(chéng)微服務，但它仍然創造了思維方式，推動了組織，并促進(jìn)了标準化。

寵物與牛：以前的服務器都(dōu)是有名字的，并且都(dōu)是單獨配置的。我曾經(jīng)在裸機上工作過(guò)，在將(jiāng)它們放進(jìn)機架之前，我親手貼上一張帶有名字的貼紙，我很清楚我可以創造的“寵物”。由于能(néng)夠訪問提供虛拟服務器或任何其他資源的 API，因此沒(méi)有辦法，也沒(méi)有必要跟上。現在，基礎設施用戶可以購買完全脫離物理的資源，根據需要自動擴展。結果，資源的可得性就(jiù)不那麼(me)重要了（它們隻是可得的）；我們考慮的是堆棧（資源），而非單個機器。資源就(jiù)是數字。牛，不是寵物。請參閱 Randy Bias 寫的内容，他將(jiāng)這(zhè)一類比總結得很完美。

基礎設施即代碼：應用很複雜。操作系統也很複雜。如果兩(liǎng)者都(dōu)是相關的，那就(jiù)會(huì)變得更複雜。過(guò)去，大多數人，包括我在内，都(dōu)是手動配置系統的。這(zhè)樣就(jiù)得到了系統的深刻理解，并且常常是獨特的理解。這(zhè)裡(lǐ)所謂的獨特，如在：低巴士因子（bus factor）；又如在：除了一個人外，沒(méi)有人知道(dào)這(zhè)個系統的情況。這(zhè)個問題的解決方案是配置管理，它允許維護人員以可複制、可測試、版本控制和标準化的文檔方式來描述整個設置。通過(guò)這(zhè)個系統，配置可以很容易地重建（相對(duì)而言），人爲錯誤因素大大減少，任何設置都(dōu)可以在較短時(shí)間内被他人理解（相對(duì)而言）。基礎設施即代碼（Infrastructure as Code，IaC）在基礎設施資源方面(miàn)也是如此。不再需要手動提供 / 配置 / 訂購特定服務或應用所需的資源，而是使用标準化、文檔化、簽入版本控制、代碼可查看、可測試和可複制的代碼來描述。

平台即服務：随著(zhe)基礎設施資源自動化日益普及，在上述基礎設施上運行的東西也可以輕松地獲得超級能(néng)力：可擴展性。也就(jiù)是說(shuō)，你隻需爲所需資源付費。或者從商業角度來看，你隻需爲你實際賣出的東西付費（粗略地說(shuō)）。牢記這(zhè)一點，我們就(jiù)不難理解爲什麼(me)如今幾乎所有的功能(néng)都(dōu)可以作爲服務來購買。我們可以把它想象成(chéng)一種(zhǒng)由基礎設施即服務（Infrastructure as a Service，IaaS）提供基礎的供應鏈。這(zhè)樣，平台即服務（Platform as a Service，PaaS）就(jiù)可以構建自己的服務，這(zhè)些服務包括計算運行時(shí)、數據庫、CDN 等等。通過(guò)這(zhè)種(zhǒng)方式，軟件即服務（Software as a Service，SaaS）的構建者可以將(jiāng)注意力集中在他們自己的領域：軟件構建，而不是深入到基礎設施層。而且人們還(hái)可以根據需要增加或減少需求。請注意，在撰寫本文時(shí)，維基百科上列出的“即服務”類型有 75 種(zhǒng)，因此我略去了一些。但重點是，市場已經(jīng)改變。諸如硬件、操作系統、服務操作之類的問題現在可以外包，按需購買。

所有這(zhè)些範式深深地糾纏在一起(qǐ)。你可以認爲“平台即服務”是“微服務”的結果，反之亦然。另外，如果沒(méi)有“基礎設施即代碼”，寵物與牛是幾乎不可能(néng)的，而後(hòu)者是前者所需要的。

什麼(me)是平台工程？

在讨論平台工程帶來的價值之前，我需要先說(shuō)明我所說(shuō)的是什麼(me)意思（或者不是什麼(me)意思）。也要記得，我的觀點是，角色就(jiù)像一頂帽子：你可以根據需要戴帽子。有些帽子是你經(jīng)常戴的，有些帽子是你比别人更喜歡的，而有些帽子你會(huì)藏起(qǐ)來，希望以後(hòu)不要把它拿出來。角色沒(méi)有明确的界限，也不與職位挂鈎。

平台化

我認爲可以肯定地說(shuō)，平台工程師參與平台的建設。由于平台這(zhè)一術語相當模糊，所以我將(jiāng)試著(zhe)在本文的範圍内解釋我的意思。讓我們從以下幾個方面(miàn)開(kāi)始：平台是一個定義良好(hǎo)的接口，它簡化了對(duì)資源的處理和訪問。

當然，在平台工程領域中，這(zhè)些資源都(dōu)是某種(zhǒng)基礎設施資源。從軟件開(kāi)發(fā)人員的角度來說(shuō)，門面(miàn)設計模式是我所能(néng)想到的最接近平台關鍵屬性的。在我看來，平台是由一個或多個“服務門面(miàn)（facade）”機器接口規範和文檔組成(chéng)的。這(zhè)一切都(dōu)是必要的，因爲平台的目的就(jiù)是自動化通用用例。

對(duì)于用戶來說(shuō)，平台基本上是透明的（比如，你不知道(dào)裡(lǐ)面(miàn)發(fā)生了什麼(me)），但我不确定這(zhè)是否一個要求——盡管在大多數情況下這(zhè)肯定是個好(hǎo)主意。

根據這(zhè)一定義，GitHub 就(jiù)是一個平台。AWS 也是一個平台，更确切地說(shuō)，它是一個平台中的平台。但任何單獨的、内部創建的解決方案都(dōu)是一個平台，它爲管理你的用例使用所需的基礎設施資源提供了簡化的接口。

平台化就(jiù)是要确定常見的用例（或模式），爲描述這(zhè)些用例的接口進(jìn)行建模，提供實現這(zhè)些用例的自動化解決方案，并將(jiāng)其文檔化，這(zhè)樣過(guò)程就(jiù)可以以最小的人工交互進(jìn)行使用。

平台工程就(jiù)是與平台化相關的學(xué)科。

與其他角色相比

盡管平台工程是一個新的角色，但它并非憑空而來，而是對(duì)現有的其他角色和職責進(jìn)行了專門劃分——與所有角色一樣。在我看來，以下幾點對(duì)平台工程有重大影響：

我認爲DevOps 工程師最接近平台工程的角色，他們專注于爲特定應用（基于雲基礎設施）提供解決方案。或者說(shuō)我這(zhè)樣認爲：畢竟 DevOps 是一種(zhǒng)生活方式。這(zhè)是一個非常接近于平台工程的東西。在我看來，主要的區别應該是視角和所得到的的規模。DevOps 工程師提倡“他們”的應用，而平台工程則關注大量或全部應用。DevOps 工程師處理特殊用例（構建一組特定應用運行的基礎設施），而平台工程處理普通用例（構建所有 / 大多數應用運行的平台）。DevOps 工程師對(duì)細節更感興趣，而平台工程則更關注共性。根據我的經(jīng)驗，這(zhè)兩(liǎng)者通常都(dōu)有需要，邊界非常模糊，而且經(jīng)常是同一個人“戴著(zhe)兩(liǎng)頂帽子”。

平台工程師角色的起(qǐ)源可能(néng)涉及到基礎設施工程師的角色，其重點是構建、部署和維護基礎設施。這(zhè)個角色接近于系統管理員、網絡工程師以及可能(néng)還(hái)有 DevOps。這(zhè)超出了雲的範疇，因爲它還(hái)涉及到數據中心。本文隻涉及雲相關的範圍。在這(zhè)個術語中，我認爲是“雲（基礎設施）工程師”，所以我就(jiù)是這(zhè)個意思。自然的，平台工程師從這(zhè)裡(lǐ)開(kāi)始，使用（雲) 基礎設施，并對(duì)基礎設施進(jìn)行全面(miàn)的思考。最大的不同在于，基礎設施工程師非常注重可操作性和可靠性，而平台工程則是注重可訪問性。

另外，後(hòu)端工程師也發(fā)揮了作用，他們專注于應用的數據訪問層。它的範圍很廣，有許多子專業，而且肯定接近 DevOps。其中一個核心問題是 API 的設計和實現，包括處理數據源、隊列等等。平台工程也做這(zhè)些，不過(guò)目的不同。後(hòu)端工程師是由平台工程創建的平台的“客戶”（公司内部），并在平台上構建自己的應用。

我曾說(shuō)過(guò)，邊界很難畫出來，可能(néng)會(huì)有更多的角色（比如網站可靠性工程），我想和他們比較一下，但是有時(shí)候我不得不停下來，希望這(zhè)個描繪的更清晰一些。

價值主張

最後(hòu)，我要談一下我的論點：平台工程的價值。

鑒于技術領域的變化，以及由此産生的新範式，我們可以清楚地看到：應用生态圈的複雜性正在增加。但這(zhè)并非因爲使用基礎設施或應用開(kāi)發(fā)方面(miàn)的複雜性增加所緻。事(shì)實上，基礎設施的事(shì)情已經(jīng)變得非常簡單了，有了基礎設施即代碼等，從我的角度來看，應用開(kāi)發(fā)也在易用性方面(miàn)取得了長(cháng)足的進(jìn)步。

那是什麼(me)呢？嗯，這(zhè)是巨大成(chéng)功的錯誤所在：我所強調的變化（以及其他變化）帶來了更多的可能(néng)性和機會(huì)。現在人人都(dōu)能(néng)很容易獲得可擴展性嗎？好(hǎo)吧，這(zhè)也意味著(zhe)現在每個人都(dōu)在關注這(zhè)個問題。正因爲如此，平台工程才起(qǐ)到關鍵作用：它通過(guò)降低用戶和應用開(kāi)發(fā)者的複雜性，幫助使這(zhè)些機會(huì)更容易獲得。

具體而言：

标準 PaaS 推銷方式

PaaS（Platform as a Service，平台即服務）的優勢主要在于它可以進(jìn)行更高級别的編程，而複雜性則大大降低。

 

——維基百科：平台即服務詞條

首先：我認爲這(zhè)應該是一般的作爲服務的推銷，而不是專門針對(duì) PaaS 的。比如。“平台即服務”的優勢主要在于，它可以在更高的級别上進(jìn)行使用，而複雜性則大大降低：你知道(dào)，發(fā)送電子郵件、流媒體電影。如果有其他選擇，所有更好(hǎo)的接口都(dōu)會(huì)大幅降低複雜性。

這(zhè)就(jiù)是平台工程可以完成(chéng)的工作：爲基礎設施資源創建更高級别的接口，這(zhè)些接口的設計是爲了使它們适合用例，然後(hòu)實現它們。隻不過(guò)不是爲任何終端用戶，就(jiù)像上面(miàn)一般的服務推銷所暗示的那樣，而是爲應用開(kāi)發(fā)者服務。标準化是免費的回報。

當然，平台工程師并非專爲 PaaS 提供商工作的（周圍沒(méi)有那麼(me)多），他們在各地搭建平台。大多數 PaaS 提供商面(miàn)向(xiàng)的是大衆市場。有很多公司因爲規模、安全、法律、遺留系統或者其他的原因不适合這(zhè)個産品。他們仍需要使用由開(kāi)發(fā)人員創建的基礎設施來運行服務。

DevOps 工程和平台工程在專注于應用層的開(kāi)發(fā)人員和提供用于運行應用的資源的基礎設施提供商之間架起(qǐ)了一座橋梁。DevOps 工程提供了一個解決方案，可以在雲基礎設施中運行一組小型、專業化的服務。平台工程以平台的形式提供解決方案，在雲基礎設施中運行更通用的服務。二者之間的邊界非常模糊，主要是規模和增長(cháng)的問題。

無論哪種(zhǒng)方式：這(zhè)使開(kāi)發(fā)人員能(néng)夠集中精力開(kāi)發(fā)應用，他們在這(zhè)方面(miàn)非常出色。依我看，你當然應該盡早開(kāi)始平台化，除非你不期待基礎設施的發(fā)展或變化。

價值：持久、高節奏的開(kāi)發(fā)進(jìn)度。

抵消技術債務

随著(zhe)事(shì)情的改變或發(fā)展，技術債務也随之增加。一直如此，除非你停滞不前。問題不在于如何完全阻止它，而在于如何減緩它，讓它變得可控，在你被迫停止之前不會(huì)增加。

許多因素導緻了技術債務的增加。當然，也有業務方面(miàn)的原因，因爲它們占據了優先地位，使人們幾乎沒(méi)有或根本沒(méi)有時(shí)間去調整基礎設施或軟件設計來抵消累積的技術債務。此外，還(hái)存在結構或架構方面(miàn)的原因。類似微服務這(zhè)樣的模式也是爲了從架構方面(miàn)解決這(zhè)個問題而産生的。

造成(chéng)技術債務快速增長(cháng)的一個主要因素是，同一問題有太多的解決方案。就(jiù)像其他的應用一樣，它們也有自己獨特的部署管道(dào)、服務運行時(shí)、數據庫設置或者是所有你能(néng)想到的東西。一座正在發(fā)展中的解決方案和模式的“動物園”，在此刻聽起(qǐ)來也許是不錯的主意，因爲它們解決了眼前的問題，但在未來卻會(huì)變成(chéng)一片難以處理的混亂，非常脆弱，在這(zhè)裡(lǐ)危險，不可觸碰，否則風險很大。

平台工程至少通過(guò)提供一個标準化的框架（服務的共同标準），在不同程度上抵消了這(zhè)最後(hòu)一個因素，以及其他因素。它還(hái)強制執行明确的邊界和接口，使你可以更容易地理解、發(fā)展和改變應用的前景，無論是現在還(hái)是將(jiāng)來。

與此密切相關的是，久而久之，遺留問題也在不斷積累。它還(hái)會(huì)轉化成(chéng)要求在某個時(shí)間償還(hái)的技術債務。盡管平台工程并不直接解決遺留問題，但它將(jiāng)這(zhè)些問題限定于組成(chéng)服務或應用的商定邊界之内。

最後(hòu)，平台工程孕育了像前面(miàn)提到的微服務這(zhè)樣的現代範式，它本身可以抵消技術債務。平台在這(zhè)方面(miàn)起(qǐ)到了支持和推動的作用。

價值：變革的敏捷性 / 不間斷的增長(cháng)。

爲變化做好(hǎo)準備

唯一不變的就(jiù)是變化。早在 2500 年前，人們就(jiù)已經(jīng)知道(dào)了這(zhè)一點，甚至對(duì)于現代的應用基礎設施而言，它仍然适用。然而，當變化到來的時(shí)候，我們仍然會(huì)感到驚奇。我在這(zhè)個生态圈工作了 20 年，從來沒(méi)有遇到過(guò)一個系統不會(huì)随時(shí)間而改變的情況。變化有許多形式。你可以做一些小事(shì)情，比如增加應用價值的新功能(néng)，也可以做一些根本性的改變，比如從物理數據中心遷移到雲基礎設施，或者重新構建整個應用。不管怎麼(me)說(shuō)：事(shì)情會(huì)發(fā)生變化，你需要做好(hǎo)準備，或者在變化來臨時(shí)支付高額的賬單。這(zhè)是必然的。

你猜對(duì)了，這(zhè)裡(lǐ)有一個共同的主題：平台工程是爲了拯救。怎麼(me)說(shuō)呢？它爲部署和運行你的應用提供了一個标準化的環境。重點在于“标準化”一詞。可以這(zhè)樣想，移動一百個應用，每一個都(dōu)有各自的部署和運行服務的方式，這(zhè)是非常困難的，甚至是可怕的。而移動一百個具有共同部署和運行服務方式的應用就(jiù)容易得多。毫無疑問，一個平台可以提供這(zhè)些共享的共性。

這(zhè)也意味著(zhe)：平台的早期。也許不是在打造 MVP 的時(shí)候，即使是我也不會(huì)提倡這(zhè)樣做，但是要确保時(shí)間足夠早，以使标準化工作不會(huì)太過(guò)痛苦，讓你對(duì)其視而不見。找出合适的時(shí)機并非易事(shì)，所以，要盡早進(jìn)入平台。

價值：靈活性（應用基礎設施中的靈活性轉化爲業務中的靈活性）。

作者介紹：

Ulrich Kautz，居住德國(guó)柏林，高級平台工程師，供職于 Scout24 Group。

原文鏈接：

https://ulrichkautz.com/posts/2021-03-11_value-of-platforming-engineering/