在過去的25年多時間裡，我創建了軟體組件和分布式框架，建立並領導了相關團隊。近幾年我致力於推動 Adobe 服務開發、部署和管理系統的開發人員生產力。
抽象陷阱
在雲時代早期，Adobe 的每個團隊都有自己的雲帳戶、部署系統，其對應的成熟度也截然不同。很快我們就意識到需要對此進行標準化，這樣成本控制、合規性、安全性和可靠性等關鍵問題就能夠一次解決，且一勞永逸。
在2016年，Kubernetes 還處於早期階段，尚未有能力大規模支持 Adobe 的雲產品。當下最好的選擇是 Mesos，當然我們清楚地了解我們正處在一個不斷變化的環境中。因此我們沒有將用戶暴露給原始平台，而是創建了一個抽象——服務規範。這個服務規範描述了所有關於如何提供和部署服務的信息。然後，定製的內部軟體在在部署時將服務規範轉為必要的原語，平台就此起飛，迅速成長並為1000多個服務和開發人員提供支持。
但隨著規模和需求的增長，我們在 Mesos 之上的本土解決方案開始陷入困境。這時 Kubernetes 已經成熟，是時候改變了。我們構建了一些自定義遷移工具，並且能夠保證在不停機的情況下將所有正在運行的服務從 Mesos 集群遷移到 Kubernetes 集群，也就是我們的新後端是將服務規範轉換為 Kubernetes 配置，儘管出現了一些小問題，但總體一切正常。就此 Mesos 集群被關閉，成本也得以節約。
之後的幾年，情況變得不太樂觀。我們的服務規範以一種非常簡單的「黃金路徑」，支持近4000個適用於服務 REST API 或 Workers 的基本應用程式。但隨著越來越多的 Adobe 團隊開始尋求平台成本節約以及安全性、合規性和可靠性的保障，要求也越來越多樣化，漸漸超出抽象支持的模式。因此公司內部規模較大且技術較成熟的團隊開始繞開抽象，在我們的託管集群上構建自定義方案，充分利用 Kubernetes 的自由和強大功能。當然，他們也必須對部署系統承擔所有責任與風險，因此在安全性和可靠性方面增加了更多負擔。
隨著越來越多的團隊要求更高的自主權和更大的靈活性，我們開始意識到原來我們被困在抽象陷阱里了。我們的抽象不支持團隊部分使用，因此在定製解決方案時需要繞過抽象，也就是說我們提供了一個不可擴展的「全有或全無」解決方案。
定製解決方案逐漸成為負擔
隨著時間的推移，我們的定製解決方案變得越來越複雜，為了添加新功能並跟上 Kubernetes 的發展消耗了團隊越來越多的時間，我們幾乎沒有什麼空間進行創新了，也開始落後於新技術了。更糟糕的是我們沒有為可擴展性而構建。即使有好的想法，但如果我們無法確定優先級，讓用戶貢獻他們需要的更改也變得不切實際。
平台的大規模採用與資源消耗
從 Mesos 到 Kubernetes，再到接下來我們要做的平台，在每個階段我們都不得不與制度惰性和對變化的恐懼與牴觸作鬥爭。如何讓用戶參與進來，讓一個有效但果實的解決方案變為更好更先進的解決方案，同時又能夠解決他們對生產服務發生變化的風險產生的擔憂呢？
這便是需要了解企業內部，確定一些在當前系統中苦苦掙扎的關鍵參與者的時候了。也許這些參與者正在使用已有的系統和解決方案，但由於缺乏自由度，他們無法成長。明確受影響最多的團隊，以及主要負責公司關鍵業務需求的團隊是哪些，並與他們一起協作，以便更好地梳理痛點與需求。同時讓負責構建新解決方案的工程師加入這些團隊，綜合專業知識為團隊進行培訓，同時將收集的反饋和教訓回滾到產品中。當這些成功的經驗在整個公司內傳播開來，對採用新技術的擔憂和牴觸將能夠有效減弱。
這是一個好的開始，但這個模式不可持續，因為只能小範圍實施無法達到龐大的規模。由於企業內部的工程師數量有限，他們需要構建平台，而與業務團隊協作並給予支持會消耗他們大量的時間和精力。因此自助服務成為平台的關鍵。例如包含故障排除連結的智能錯誤消息，可以搜索可用文檔以回答問題的智能代理，為團隊解決問題的認可和獎勵機制，各個級別的自動化，等等。
培養「T型」開發人員
無論我們構建什麼解決方案，都需要主題專家（Subject Matter Expert, SME）來進行創建和維護，由此帶來的問題則是過度專業化。開發人員成為他們所負責組建的專家，無需擔心其他任何事情。這樣開發人員可以更專注於開發業務，但在平台環境中也帶來了很多問題。這類開發人員通常在自己關注的領域表現出非常高的生產力，但他們同樣有可能面臨與不太了解熟悉的系統集成的問題。如果這些開發人員離開崗位，他們所專注的業務就可能成為企業的單點故障。
我們通過三種方式解決了這個問題。首先通過培訓和日常使用我們自己的交付來確保團隊的每個成員都是平台的專家用戶，然後為每個成員分配一個支持輪換。最後我們鼓勵團隊內的流動，我們定期根據開發人員的個人意願和企業的需要在組件之間輪轉崗位。
當然開發人員需要集中精力完成工作，所以這些輪換不會進行得太頻繁，組件的轉移也不會時常發生。這樣我們就能夠培養「T型」人才，即開發人員在整個平台上具有廣泛的知識，且在數個組件上的了解具備深度。
完美≠進步
多年來我們一直在試圖兼顧短期勝利和長期規劃。尤其在開始一些新的、有風向的項目，隨著時間的推移，企業的處理態度往往會轉向謹慎，開始按流程展開項目，例如成立規劃小組，確保規範詳盡無遺，不斷進行審查......
事實上沒有什麼完美又神奇的解決方案。但我們發現，如果我們能發現什麼時候遇到問題停滯不前，並及時改變模式，就能取得很好的結果，不用過分追求規範上的詳盡和完美。帶幾個開發人員組織一個小團隊集中創新研發幾周，消除干擾，然後與選定的關鍵核心用戶密切合作來評估概念。如果順利的話，將信息反饋給團隊及其他成員，利用這些反饋和簡潔的「規範單頁」，確保研發的目標和願景是清晰的，接下來進行疊代並交付平台用戶所依賴的價值。
平台團隊也可能成為瓶頸
平台團隊的一個自然趨勢就是隨著時間的推移逐漸忽視用戶。當我們對用戶開始說「不」的時候，他們就會開始尋找其他的解決方案。而平台工程的關鍵特徵，那些為公司帶來的優勢——成本節約、合規性、安全性和可靠性，也都沒有意義了，平台團隊將成為瓶頸，這也將是平台消亡的方式。
因此我們通過與高層領導和主要用戶保持聯繫來避免這種情況，尤其是面對公司內新項目和關鍵業務時。我們確保平台是不斷發展的，以滿足關鍵用戶的需求，保證平台足夠通用，使開發人員的工作變得輕鬆和靈活，支持所有必需的用例。當然實現這點並不容易，我們需要不斷地創新和改進。
下一步是什麼
從一個好的想法開始，到大規模和持續的適應，這就是 Adobe 構建 IDP 的旅程。我們正處在一個轉折點，由於抽象的限制性，而用戶想要得更多，維護自定義解決方案正在消耗平台團隊的大量精力和時間。總結構建 IDP 之旅中的經驗與教訓，我們認識到抽象是好的，但不靈活的抽象可能是一個陷阱。在內部構建解決方案允許完全自由，但這種自由是以持續維護來兜底的。我們依舊在尋找一個區別於固定的「黃金路徑」解決方案和原始 Kubernetes 的新解決方案。
我們正在使用 Helm 圖表的輕度抽象來替換服務規範的重度抽象，並將我們的定製組件套件換為 Argo，我們在努力解決可擴展性問題。我們讓關鍵用戶參與到開發過程中，結合開源和企業內部資源，再次構建自定義轉換工具，將舊服務規範轉換為 Helm 圖表和 Argo 模板，讓用戶可以隨意定義這些模板。
我們的下一個挑戰是通過與雲提供商、監控解決方案、可觀察性、分布式跟蹤等更緊密的集成，將開發人員的生產力提升到另一個水平。我們開始將 Adobe 所有不同的內部產品集成到 IDP 中。有了這一切，我們將以更低的成本提供更好的平台，為我們的用戶提供更高的靈活性和更低的摩擦。
參考連結：
https://thenewstack.io/adobes-internal-developer-platform-journey-and-lessons/