在過去的25年多時間里，我創(chuàng)建了軟件組件和分布式框架，建立并領導了相關團隊。近幾年我致力于推動 Adobe 服務開發(fā)、部署和管理系統(tǒng)的開發(fā)人員生產力。
?

抽象陷阱

在云時代早期，Adobe 的每個團隊都有自己的云賬戶、部署系統(tǒng)，其對應的成熟度也截然不同。很快我們就意識到需要對此進行標準化，這樣成本控制、合規(guī)性、安全性和可靠性等關鍵問題就能夠一次解決，且一勞永逸。
?

在2016年，Kubernetes 還處于早期階段，尚未有能力大規(guī)模支持 Adobe 的云產品。當下最好的選擇是 Mesos，當然我們清楚地了解我們正處在一個不斷變化的環(huán)境中。因此我們沒有將用戶暴露給原始平臺，而是創(chuàng)建了一個抽象——服務規(guī)范。這個服務規(guī)范描述了所有關于如何提供和部署服務的信息。然后，定制的內部軟件在在部署時將服務規(guī)范轉為必要的原語，平臺就此起飛，迅速成長并為1000多個服務和開發(fā)人員提供支持。
?

但隨著規(guī)模和需求的增長，我們在 Mesos 之上的本土解決方案開始陷入困境。這時 Kubernetes 已經成熟，是時候改變了。我們構建了一些自定義遷移工具，并且能夠保證在不停機的情況下將所有正在運行的服務從 Mesos 集群遷移到 Kubernetes 集群，也就是我們的新后端是將服務規(guī)范轉換為 Kubernetes 配置，盡管出現(xiàn)了一些小問題，但總體一切正常。就此 Mesos 集群被關閉，成本也得以節(jié)約。
?

之后的幾年，情況變得不太樂觀。我們的服務規(guī)范以一種非常簡單的“黃金路徑”，支持近4000個適用于服務 REST API 或 Workers 的基本應用程序。但隨著越來越多的 Adobe 團隊開始尋求平臺成本節(jié)約以及安全性、合規(guī)性和可靠性的保障，要求也越來越多樣化，漸漸超出抽象支持的模式。因此公司內部規(guī)模較大且技術較成熟的團隊開始繞開抽象，在我們的托管集群上構建自定義方案，充分利用 Kubernetes 的自由和強大功能。當然，他們也必須對部署系統(tǒng)承擔所有責任與風險，因此在安全性和可靠性方面增加了更多負擔。
?

隨著越來越多的團隊要求更高的自主權和更大的靈活性，我們開始意識到原來我們被困在抽象陷阱里了。我們的抽象不支持團隊部分使用，因此在定制解決方案時需要繞過抽象，也就是說我們提供了一個不可擴展的“全有或全無”解決方案。
?

定制解決方案逐漸成為負擔

隨著時間的推移，我們的定制解決方案變得越來越復雜，為了添加新功能并跟上 Kubernetes 的發(fā)展消耗了團隊越來越多的時間，我們幾乎沒有什么空間進行創(chuàng)新了，也開始落后于新技術了。更糟糕的是我們沒有為可擴展性而構建。即使有好的想法，但如果我們無法確定優(yōu)先級，讓用戶貢獻他們需要的更改也變得不切實際。

平臺的大規(guī)模采用與資源消耗

從 Mesos 到 Kubernetes，再到接下來我們要做的平臺，在每個階段我們都不得不與制度惰性和對變化的恐懼與抵觸作斗爭。如何讓用戶參與進來，讓一個有效但果實的解決方案變?yōu)楦酶冗M的解決方案，同時又能夠解決他們對生產服務發(fā)生變化的風險產生的擔憂呢？
?

這便是需要了解企業(yè)內部，確定一些在當前系統(tǒng)中苦苦掙扎的關鍵參與者的時候了。也許這些參與者正在使用已有的系統(tǒng)和解決方案，但由于缺乏自由度，他們無法成長。明確受影響最多的團隊，以及主要負責公司關鍵業(yè)務需求的團隊是哪些，并與他們一起協(xié)作，以便更好地梳理痛點與需求。同時讓負責構建新解決方案的工程師加入這些團隊，綜合專業(yè)知識為團隊進行培訓，同時將收集的反饋和教訓回滾到產品中。當這些成功的經驗在整個公司內傳播開來，對采用新技術的擔憂和抵觸將能夠有效減弱。
?

這是一個好的開始，但這個模式不可持續(xù)，因為只能小范圍實施無法達到龐大的規(guī)模。由于企業(yè)內部的工程師數(shù)量有限，他們需要構建平臺，而與業(yè)務團隊協(xié)作并給予支持會消耗他們大量的時間和精力。因此自助服務成為平臺的關鍵。例如包含故障排除鏈接的智能錯誤消息，可以搜索可用文檔以回答問題的智能代理，為團隊解決問題的認可和獎勵機制，各個級別的自動化，等等。
?

培養(yǎng)“T型”開發(fā)人員

無論我們構建什么解決方案，都需要主題專家（Subject Matter Expert, SME）來進行創(chuàng)建和維護，由此帶來的問題則是過度專業(yè)化。開發(fā)人員成為他們所負責組建的專家，無需擔心其他任何事情。這樣開發(fā)人員可以更專注于開發(fā)業(yè)務，但在平臺環(huán)境中也帶來了很多問題。這類開發(fā)人員通常在自己關注的領域表現(xiàn)出非常高的生產力，但他們同樣有可能面臨與不太了解熟悉的系統(tǒng)集成的問題。如果這些開發(fā)人員離開崗位，他們所專注的業(yè)務就可能成為企業(yè)的單點故障。
?

我們通過三種方式解決了這個問題。首先通過培訓和日常使用我們自己的交付來確保團隊的每個成員都是平臺的專家用戶，然后為每個成員分配一個支持輪換。最后我們鼓勵團隊內的流動，我們定期根據(jù)開發(fā)人員的個人意愿和企業(yè)的需要在組件之間輪轉崗位。
?

當然開發(fā)人員需要集中精力完成工作，所以這些輪換不會進行得太頻繁，組件的轉移也不會時常發(fā)生。這樣我們就能夠培養(yǎng)“T型”人才，即開發(fā)人員在整個平臺上具有廣泛的知識，且在數(shù)個組件上的了解具備深度。
?

完美≠進步

多年來我們一直在試圖兼顧短期勝利和長期規(guī)劃。尤其在開始一些新的、有風向的項目，隨著時間的推移，企業(yè)的處理態(tài)度往往會轉向謹慎，開始按流程展開項目，例如成立規(guī)劃小組，確保規(guī)范詳盡無遺，不斷進行審查......
?

事實上沒有什么完美又神奇的解決方案。但我們發(fā)現(xiàn)，如果我們能發(fā)現(xiàn)什么時候遇到問題停滯不前，并及時改變模式，就能取得很好的結果，不用過分追求規(guī)范上的詳盡和完美。帶幾個開發(fā)人員組織一個小團隊集中創(chuàng)新研發(fā)幾周，消除干擾，然后與選定的關鍵核心用戶密切合作來評估概念。如果順利的話，將信息反饋給團隊及其他成員，利用這些反饋和簡潔的“規(guī)范單頁”，確保研發(fā)的目標和愿景是清晰的，接下來進行迭代并交付平臺用戶所依賴的價值。
?

平臺團隊也可能成為瓶頸

平臺團隊的一個自然趨勢就是隨著時間的推移逐漸忽視用戶。當我們對用戶開始說“不”的時候，他們就會開始尋找其他的解決方案。而平臺工程的關鍵特征，那些為公司帶來的優(yōu)勢——成本節(jié)約、合規(guī)性、安全性和可靠性，也都沒有意義了，平臺團隊將成為瓶頸，這也將是平臺消亡的方式。
?

因此我們通過與高層領導和主要用戶保持聯(lián)系來避免這種情況，尤其是面對公司內新項目和關鍵業(yè)務時。我們確保平臺是不斷發(fā)展的，以滿足關鍵用戶的需求，保證平臺足夠通用，使開發(fā)人員的工作變得輕松和靈活，支持所有必需的用例。當然實現(xiàn)這點并不容易，我們需要不斷地創(chuàng)新和改進。
?

下一步是什么

從一個好的想法開始，到大規(guī)模和持續(xù)的適應，這就是 Adobe 構建 IDP 的旅程。我們正處在一個轉折點，由于抽象的限制性，而用戶想要得更多，維護自定義解決方案正在消耗平臺團隊的大量精力和時間?？偨Y構建 IDP 之旅中的經驗與教訓，我們認識到抽象是好的，但不靈活的抽象可能是一個陷阱。在內部構建解決方案允許完全自由，但這種自由是以持續(xù)維護來兜底的。我們依舊在尋找一個區(qū)別于固定的“黃金路徑”解決方案和原始 Kubernetes 的新解決方案。
?

我們正在使用 Helm 圖表的輕度抽象來替換服務規(guī)范的重度抽象，并將我們的定制組件套件換為 Argo，我們在努力解決可擴展性問題。我們讓關鍵用戶參與到開發(fā)過程中，結合開源和企業(yè)內部資源，再次構建自定義轉換工具，將舊服務規(guī)范轉換為 Helm 圖表和 Argo 模板，讓用戶可以隨意定義這些模板。
?

我們的下一個挑戰(zhàn)是通過與云提供商、監(jiān)控解決方案、可觀察性、分布式跟蹤等更緊密的集成，將開發(fā)人員的生產力提升到另一個水平。我們開始將 Adobe 所有不同的內部產品集成到 IDP 中。有了這一切，我們將以更低的成本提供更好的平臺，為我們的用戶提供更高的靈活性和更低的摩擦。
?

參考鏈接：
https://thenewstack.io/adobes-internal-developer-platform-journey-and-lessons/