岱军 云云众生s
隨著建置和維護內部開發者平台的複雜性，還有其他人覺得鐘擺即將落下嗎？
譯自What Comes after Internal Developer Platforms?，作者 Valerie Slaughter。
事物往往是循環發展的。 我們總是在一個極端和另一個極端之間搖擺，對之前發生的事情做出反應——並與之區分開來。 從廣義的歷史意義和發展來看，這是正確的。
你可以將開發工具的歷史改寫為集中化和分散化的循環——不斷平衡標準化和自主性、可擴展性和速度的鬥爭。 就在我們似乎已經找到解決方案的時候，鐘擺又擺向了另一個方向。
平台團隊的興起已被充分記錄，內部開發者平台的管理越來越成為一項核心功能。 但隨著這些系統的複雜性不斷增加，建造和維護它們的成本抵消了提供它們的好處，是否有人覺得鐘擺即將落下？
內部開發者平台的興起
在容器出現之前，有VMware，我們沉迷於為開發者建立自助式平台，以便他們能夠以最小的方式與基礎設施進行互動。 我們可以直接要求我們需要的虛擬機，並立即開始開發。
當基礎設施即程式碼出現時，我們分解了這些虛擬機器並轉向微服務。 我們決定不使用這個單一的平台，而是使用一個分散的平台來分離關注點，這將使我們能夠更好地擴展。 每個團隊都可以在自己的城邦內工作。 當事情無法正常運作時，DevOps 文化有助於團隊彼此溝通。
但這也開始變得難以控制。 容器變得越來越小，複雜性也越來越大。 現在，由於人性，我們正在做我們一直在做的事情：一些截然不同的事情。 每次我們達到某個複雜性的臨界點時，我們都會再次改變策略。 分散化並沒有像我們希望的那樣奏效；我們需要一個更集中的模式。
內部開發者平台標誌著對這種集中化開發視圖的回歸。 我們正在建立自助式平台，希望開發者不必與維運人員交談。
但我們遇到了同樣的陷阱——只是把豌豆從盤子的這一邊挪到另一邊。 複雜性從未真正消失。
內部開發者平台的風險
原則上，內部開發者平台應該透過將所有隨容器而來的操作工具集中到一個地方來減輕開發者的認知負擔。 但這種集中化真的有效嗎？ 為你的開發者提供一個中央平台會帶來巨大的風險。
過度工程
分析師說，「去建立一個平台。」但像這樣的建議的問題在於，它們是針對像 Netflix 這樣的公司提出的。 大多數公司根本沒有 Netflix 這樣的規模，他們永遠不會遇到像 Netflix 這樣的問題，但他們無論如何都被要求解決這些問題。
資源黑洞
一個全新的平台團隊可能花費兩年時間和數百萬美元為開發者建立一個新的內部產品：內部開發者平台。 但沒有保證，一旦建置完成，這個新產品就能為人們運作。
在你花費所有這些金錢、時間、汗水和淚水之前，你怎麼知道這個平台是否會產生價值？
工具孤島
企業解決方案是複雜的命題。 針對軟體開發生命週期的每個階段的工具越來越專業化，這使得特定的組織角色更容易，但對於使用自己專業工具的其他角色的協作幾乎沒有幫助。 每個團隊最終都會陷入工具孤島。
DevOps 背後的最初想法是透過調整組織結構和改善溝通來解決這種孤島問題。 內部開發者平台被設想為一種萬無一失的方式，讓開發者無摩擦地交付應用程序，標誌著遠離這種溝通和協作。 在 2024 年版本的「將其拋過牆」中，牆位於平台團隊和開發人員之間，沒有人確切知道另一邊發生了什麼。
我們需要促進一般溝通的工具，而不僅僅是圍繞工具的溝通。 讓我們承認，利害關係人利用不同的必需技能，生活在不同的世界。 與其在這些利害關係人之間尋找最小公分母，不如透過賦予他們專注於自己擅長的能力來最大化他們的能力。
接下來的步驟是什麼？
如果我們不是在集中化和分散化、工具孤島和統治所有工具的工具之間來回切換，而是促進工具之間的對話，會怎麼樣？ 如果我們為構成複雜解決方案的每個主題專家提供一個描述、部署和測試其工作範圍的通用框架，會怎麼樣？
這樣的解決方案將是 IDP 全有或全無方法的輕量級替代方案，而不會完全分散化。
在Garden，我們致力於幫助團隊以更模組化的方式工作，使他們能夠獲得他人的工作，以便根據全局測試自己的工作。 我們相信，接下來將出現處理複雜性而不是將其抽像或將其踢給其他團隊的工具。