我們生活在被軟件吞噬的世界，而在軟件構建領域，幾乎每年就會出現(xiàn)一波浪潮。今年，平臺工程仿佛成為了一個“新貴”，Gartner 10月發(fā)布的2023年十大戰(zhàn)略技術趨勢中，平臺工程就位列其中，它的目的在于為負責構建產品和服務的開發(fā)團隊提供所依賴的通用共享服務，從而讓開發(fā)更聚焦于開發(fā)，運維聚焦于運維。

平臺工程不是第一次嘗試解決構建和運行軟件方面的普遍難題，也幾乎肯定不會是最后一次。之前就有敏捷、DevOps、站點可靠性工程（SRE）和數(shù)字化轉型，目標宏偉，但結果好壞不一。軟件解決方案帶來了新問題，許多問題由急切的供應商通過提供帶來新問題的解決方案來解決。平臺工程試圖駕馭創(chuàng)新、采用、碎片化和停滯這個無休止的循環(huán)，從而滿足不斷進步的需求。

1.為什么開發(fā)不能DIY？

支持開發(fā)項目需要工具，同時保持工程師的高效工作。期望應用程序開發(fā)團隊運行所有東西不切實際。因此，很多企業(yè)團隊選擇組裝一套第三方服務和開源系統(tǒng)，并添加了其他非開發(fā)人員以保持系統(tǒng)運行。無論構建什么樣的應用程序，都在一個平臺上編寫它們。

需要一個起點來構建軟件。你可以采用數(shù)據(jù)庫、消息隊列、容器編排、操作系統(tǒng)和各種開發(fā)者工具等框架和工具來搭建應用程序運行的“堆?！被颦h(huán)境。但特例和偏好會破壞統(tǒng)一性，導致碎片化。因此需要在易維護性和靈活性之間保持微妙的平衡，從而在保持簡單易懂的整體環(huán)境的同時又能讓每個團隊發(fā)揮所長。

2.DevOps

劃分構建和維護軟件系統(tǒng)方面任務的簡單二分法是分為開發(fā)（Dev）和運營（Ops）。開發(fā)為客戶構建新的特性和功能，運營確保它們在發(fā)布后正確運行。

DevOps試圖奉行“誰構建，誰運維”的理念，從而消除這種分裂。這種理念認為，通過將運營所有權交給帶來軟件錯誤的人（開發(fā)者），自然激勵會迫使組織正視技術債務，一開始就構建更好的軟件。

實踐上的挑戰(zhàn)在于，DevOps已成為介于Dev和Ops之間的第三個孤島，處理雙方都不想做或不能做的事情。盡管有觀點認為“DevOps工程師”一開始就不該存在，但這個角色還是迅速流行起來。它指代這類人：處理搭建持續(xù)集成/持續(xù)交付（CI/CD）系統(tǒng)、將基礎架構配置為代碼、為新應用程序配置云環(huán)境以及竭力跟上Dev和Ops任何一方面不斷出現(xiàn)的變化。

3.站點可靠性工程

SRE概念理論上聽起來不錯，在適當規(guī)模和類型的組織中非常有效。達到足夠的規(guī)模和復雜性后，確?？煽啃员旧砭统闪艘豁椞魬?zhàn)。這個角色常常處理重復的操作任務，并通過采用或構建新的交付和生產力工具和流程來不斷識別和消除“臟活”，從而使公司的整體系統(tǒng)逐漸更具競爭力。

實際上，許多組織在實現(xiàn)SRE的承諾時遇到了挫折。有時只是重新命名運營團隊，而不改變技能組合或實施可以減少臟活的項目；或者給SRE團隊進行改變的余地太小。費用上升（因為更高技能和分配預防性容量的成本高達四倍），而且投資回報多半值得懷疑。

4.數(shù)字化轉型

對于試圖在日益網絡化的環(huán)境下站穩(wěn)腳跟的老企業(yè)來說，數(shù)字化轉型概念可能是個宏偉的目標，聽起來就像將舊的家庭視頻轉換成MPEG文件，或掃描紙質合同、改用DocuSign。管理顧問樂于領導這些昂貴、緩慢又痛苦的項目，將組織帶入云計算時代。代價高昂的數(shù)據(jù)泄露增添了暫時的動力，與全球系統(tǒng)集成商簽署的多年協(xié)議也是如此。不過，數(shù)字化轉型的最大外在驅動力是疫情，這最終迫使每個人都想方設法使用二維碼來點菜。

5.平臺來了

“平臺”這個詞幾乎意味著任何東西。首先，平臺意味著可以在其上面構建產品。平臺隨時可供使用。除非組織可以將平臺用于多種用途，否則它只是產品的一部分。平臺為應用程序、工作負載、租戶、運營商、開發(fā)者和客戶（間接）提供服務。

大多數(shù)軟件架構現(xiàn)在以“服務”為導向，這也意味著平臺必須為服務而存在?？梢哉f平臺為在它上面構建產品的其他團隊提供服務。

每當我們試圖確定“平臺”的確切定義時，會開始聽起來像是營銷噱頭。我們可能談論“計算平臺”、“數(shù)字基礎設施平臺”，甚至是“云平臺”。我們談論的平臺涵蓋一些既模糊又具體的東西：人員、流程、工具、文檔、知識、升級路徑、供應商合同、SLA、期望、計劃和成本結構，這些使組織持續(xù)關注平臺。

我建議進行以下測試以確定我們是否到底在談論平臺：

• 平臺提供有價值的服務
• 平臺符合可重用接口
• 平臺需要工作負載才有價值
• 平臺間接支持最終用戶
• 平臺提高生產力
• 平臺得到資助和維護
• 平臺為可靠性、安全性和性能設定了標準
• 平臺使得做一些事情變得容易，做其他事情更困難（有意或無意）
• 平臺必須謹慎改變，以避免連鎖反應
• 平臺可能包括手動任務、工單、運行手冊和知識

平臺通常包括的幾類組件如下：

• 基礎計算、網絡和存儲
• 處理定制或隨機請求的工單系統(tǒng)
• 身份、身份驗證和授權服務
• 準備就緒核對清單
• 安全掃描
• 監(jiān)控、可觀測性和報告
• SLA
• 各種數(shù)據(jù)庫
• 消息隊列
• 災難恢復和故障切換
• 郵件服務器（這有多方便？）
• Kubernetes

如果你的公司沒有一個平臺團隊，那么你們就還沒有平臺意識。也許你期望供應商為你做一切工作，或者數(shù)字化轉型顧問集成這些系統(tǒng)，以便無縫地運行，以降低風險、獲得很高的投資回報。

值得注意的是，平臺工程師已挺身而出。他們試圖將文檔編寫糟糕的工具、服務、開源項目、巧妙的改動、待辦列表和技術債務變成類似產品的東西。目標不是虛幻的（“生產力”或“可靠性”），而是務實的（“不妨構建人們想要使用的產品”）。

6.平臺即產品

貴公司內部的平臺好比推向市場的產品。你想構建貴組織想要使用的東西，因此用戶會游說管理層，以確保資源持續(xù)不斷。所以你需要關注負責重大任務的大型團隊，你可以幫助他們加快行動、減少失敗并高效運行。你必須了解內部客戶的優(yōu)先事項、痛點、建立規(guī)模經濟的機會以及可持續(xù)的商業(yè)模式。你需要使平臺易于采用，同時還考慮當前情況的實際限制。

平臺采用產品理念可帶來與采用 DevOps、SRE、數(shù)字化轉型或敏捷全然不同的結果。現(xiàn)在有了人們想要使用的東西：平臺，它可以減輕他們的負擔，并讓他們專心致志。他們不必擔心云提供的所有細節(jié)，他們有一個基于平臺的限制和決定的受限菜單。當然，沒有人會純粹為了平臺而使用平臺；團隊必須贏得客戶的信任和認可，否則他們只能將工作量帶回家。

7.所有權理念

所有權可能根植于人類心理學，也可能是層次化管理結構的產物。在現(xiàn)實世界中，當你嘗試運作重大項目時，就要知道誰在做什么，并相信他們會繼續(xù)做下去。否則，整個組織會分崩離析。一旦沒人知道組織結構圖，紛爭、指責、冷漠和跳槽很快接踵而來。

谷歌的SRE并不負責可靠性，他們大多將自己視為內部可靠性顧問。谷歌SRE試圖幫助產品團隊在設計系統(tǒng)時做出正確的選擇。他們幫助設定服務水平目標（SLO），以確?？煽啃阅繕艘衙鞔_定義。也許最重要的是，他們推動團隊一貫采用來自整個谷歌技術基礎架構（可以稱之為平臺）的標準服務。SRE是平臺即產品的客戶成功團隊。

8、下一步是什么？

平臺工程潮流越來越盛。LinkedIn和Twitter上將“平臺”添加到頭銜中的人越來越多。CEO們將平臺工程師視為主要客戶。

當我試圖更好地了解當下的形勢時，我問了所有的SRE朋友他們對平臺工程有何看法。每個人都會懷疑這是新瓶裝舊酒，只是營銷噱頭。

不止一個SRE告訴我“實際上，我們是平臺團隊，而不是SRE團隊?！蔽艺J識的以前在性能工程、安全和數(shù)據(jù)管理方面工作的朋友和同事都已經向平臺工程轉型。

我最喜歡平臺工程的是所有權，最不喜歡的是平臺工程在定義方面的模糊性，諸如在“平臺是什么、不是什么”方面缺乏明確性。我對DevOps窮途末路和SRE一敗涂地的說法持保留態(tài)度。DevOps工程師的工作仍然需要完成，即使換了新名字。想象一下平臺團隊在你的公司聚在一起，接管其他產品、應用程序和IT團隊面臨的常見問題，結果會如何。

平臺不是一艘更快的船，而是上漲的潮水。

原文鏈接：

??https://dzone.com/articles/the-rising-tide-of-platform-engineering???