如何構建內部開發者平臺？

Scott Carey ?Charles

成功建立了快速、穩定軟件發布DevOps文化的企業通常依靠內部開發者平臺（IDP）來部署代碼。那么什么是“IDP”，怎樣才能構建起來呢？

隨著云計算、容器化、DevOps和微服務架構成為現代應用程序開發的構建模塊，對于內部軟件開發部門來說，越來越重要的是需要一種簡單的方法來管理這些資源。

谷歌、Netflix和亞馬遜等很多精英工程企業認為，內部開發者平臺（IDP，Internal Developer Platforms）減輕了DevOps部門的運營負擔，同時為軟件開發人員抽象出了不必要的決策。

正如前總統奧巴馬只穿灰色或藍色西裝以減輕他的認知負擔一樣，使用良好內部開發者平臺的開發人員可以只關注自己的代碼和Git存儲庫，其他的則交給負責底層基礎設施的平臺。

什么是內部開發者平臺？

內部開發平臺就像雪花片，沒有兩個是一樣的。每個平臺因企業的堆棧、文化、代碼庫和工具集的不同而不同，這使得很難找到一致的定義。

正如ThoughtWorks工程主管Evan Bottcher所說，“很難用語言表示。‘平臺其實是一個非常模糊的術語，我們用來形容對提高大規模交付速度和效率非常重要的方法。”

Bottcher自己的定義（他更喜歡術語“數字平臺”而不是“內部平臺”）是：“自助服務API、工具、服務、知識和支持的基礎，被配置為備受關注的內部產品。”

對沖基金Two Sigma的平臺工程主管Camille Fournier認為，關鍵在于基礎設施的軟件方面。她在2020年關于這個話題的博客中寫道：“像K8s這樣的計算平臺、存儲系統、軟件開發工具和服務框架都是任務的一部分。”

一個好的內部開發者平臺應該抽象出基礎設施決策，支持自助服務環境構建，與現有的持續集成和交付（CI/CD）以及部署過程集成，并分配基于角色的訪問控制，所有這些都不需要開發人員學習YAML。

Humanitec公司的首席技術官Chris Stephenson曾在谷歌開發過內部平臺，他在博客中寫道：“一個有效的內部開發者平臺的關鍵點在于能夠把復雜的問題劃分好。每個人都有自己擅長處理的一部分復雜問題，而其他人完全可以忽略這些問題。”

Redmonk的首席分析師Stephen O'Grady說，在過去一年里，他看到“有一種明確的愿望，那就是把工具鏈中必要的部分整合到一個平臺上，開發人員可以在平臺上編寫應用程序，所有可能的復雜問題都被抽象出來了。”

內部開發者平臺的好處

Puppet和CircleCI最新的《DevOps狀態報告》將自助服務式內部平臺確定為使成熟的企業DevOps部門與眾不同的3個關鍵要素之一，其他兩個是自動進行變更管理和集成安全性。

一個功能完備的內部平臺應能夠降低現代軟件系統的復雜性，加快軟件部署周期，創建更穩定的版本，提高開發人員的滿意度和工作效率，同時降低運營負擔。

誰需要內部開發者平臺？

內部開發者平臺有兩個核心用戶組，每個用戶組都有自己的視角：平臺/運行/DevOps團隊和開發人員團隊。

平臺/運行/DevOps團隊配置平臺，為所需的基礎設施和工具創建API接口，并建立訪問與合規保護措施。平臺本身通常由單個產品所有者配置，或者在較大的企業中由專門的內部平臺團隊配置。

在表現最好的企業中，該團隊應該扮演產品所有者的角色，與開發人員協作以收集需求，緩解常見的痛點，并根據需要對平臺進行迭代，所有這些都基于一組關鍵的用戶指標。他們也應該善于在內部為平臺進行宣傳。

云咨詢公司Expert Thinking的首席技術官James Whinn表示：“這種產品思維方式是內部平臺成功的關鍵。沒有它，團隊可能會只專注于某些很酷的東西，而不一定能帶來業務價值。”

然后，開發人員將得到一個精簡版的平臺，該平臺將抽象出任何基礎設施決策，以便他們能夠專注于部署。

初創公司Humanitec成立于2018年，旨在幫助企業建立一個內部平臺，該公司首席執行官Kaspar von Grünberg認為：“對于DevOps團隊來說，它必須是靈活的，但是對于開發者來說，必須是不靈活的。所有定制功能都應該由DevOps團隊承擔，為不想考慮底層基礎設施的開發人員創造捷徑。”

但是這樣做，我們不是又把開發人員和運行人員分開了嗎？

Puppet的首席技術官Nigel Kersten指出，構建和使用內部平臺的團隊必須緊密聯系在一起，以確保每個人都朝著同一個方向前進，就像在同一個團隊一樣。如果把他們分開，將最終重蹈開發和運行人員老模式的覆轍。

IDP與PaaS

平臺即服務（PaaS）通常由供應商規定開發人員應怎樣工作，內部開發者平臺與之不同，它是基于開發人員團隊已經熟悉的工具和流程構建的，但抽象性和一致性更好。

正如谷歌技術專家Kelsey Hightower在2017年的推特上所說：“我認為大多數管理基礎設施的人只想要PaaS。唯一的要求是：必須由他們自己來構建。”

許多小企業借助于PaaS讓他們的工程團隊快速啟動和運行，其中包括Heroku（在2010年被Salesforce收購），或者OpenShift、Cloud Foundry，以及大型公有云供應商自己的工具等流行的選擇，但通常會發現這些工具難以靈活地進行擴展。

選擇IDP方法確實會讓工程師們在有機會構建自己的平臺時去冒險，或者更糟的是，他們試圖像亞馬遜或谷歌那樣運行，這會導致精力分散，帶來災難。

Fournier寫道：“即使那些大公司以開源軟件的形式提供解決方案，他們也經常對可用產品的周圍生態系統以及使用該產品的工程師的文化和需求進行各種各樣的假設，而這些假設可能不太適用于你的公司。說‘谷歌做到了，所以我們也應該這樣做，這不是好的產品管理方式。”

Puppet的Kersten是谷歌前SRE（譯者注：網站可靠性工程師，可簡稱運維工程師），他也有類似的看法：“我們已經看到很多大企業試圖采用小型自治團隊的模式，這種模式在亞馬遜很有效，因為他們有非常熟練的開發人員，但那里的一切都是作為服務構建的，它們不像傳統軟件那樣受到監管或者限制。不過，對其他企業而言，這會造成混亂和企業債務。”

怎樣開始采用內部開發者平臺

從整體部署過程轉變為持續交付過程是一項重大的文化變革，切不可低估。Bottcher寫道：“我認為，用‘自己建設，自己管理的心態來創辦一家小公司其實并不難，但要實現轉型則需要勇氣和遠見。”

Kersten已經看到太多的企業試圖將現有流程重新包裝為一個內部平臺，因為這是最流行的。他說：“我們看到的最不同的一種模式是將中心IT重新定義為平臺團隊，但不進行必要的技術和文化變革。隨著其越來越受歡迎，我們預計這種情況會越來越多。”

轉移到內部開發者平臺或者決定從頭開始構建，這很難推廣到更多的企業中——從說服管理層做出如此大的轉變，到讓開發人員適應一種他們無法完全控制的新工作方式。

Kersten說：“更大的問題是能夠理解用戶，并做出文化上的變革。”

他和其他很多專家的建議是：從小處著手。Expert Thinking的Whinn建議：“建立一個卓越中心，找出開發出的平臺能產生真正影響的應用情形。”即使為單個應用程序搭建測試環境并從中構建出所需的API，也可以幫助平臺團隊走上正確的道路。

在2019年的DevOps企業峰會上，Team Topologies的作者之一Matthew Skelton說，考慮這一問題的一種方法是將其視為最簡單的可用平臺，或者“明確平臺的哪些方面是重要的，一定不能超過必要的規模。我們需確保我們構建的任何東西都是有吸引力的，有很強的開發經驗，并將用戶視為我們需要與之交流的客戶，以便我們能夠理解他們的需求并滿足他們。”

Humanitec的von Grünberg說：“無論開發或者購買，都是一樣的：必須從底層開始。我們經常看到，企業會把一小群最好的工程師組織在一起，要求他們把相互隔離的工具鏈整合起來。然后，開始圍繞團隊可以使用的通用API來進行整合，并將結構引入到非結構化工具的海洋中。”

本文作者Scott Carey是IDG UK企業版的集團編輯，主要為InfoWorld撰稿。

原文網址

https：//www.infoworld.com/article/3610335/what-is-an-internal-developer-platform-paas-done-your-way.html