Spotify模型：什麼是面向運維基礎設施的開發者門戶Backstage？ - redmonk

RedMonk的行業分析師James Governor寫了一篇部落格文章，詳細介紹了Spotify對Backstage的使用：

Backstage是Spotify公司內部的開發人員門戶，Spotify是一家以工程為主導的公司。它也是一家以產品為主導的公司。因此，當它決定需要更好地處理其雲端計算支出時，便決定構建一種旨在供工程師使用的內部產品。結果就是Cost Insights，這是Spotify的Backstage開發人員門戶的外掛。這個想法是激勵工程師和工程團隊對與其製造的產品相關的成本承擔更多責任。建模成本已成為工程流程的一部分，而不是由財務團隊管理的獨立流程。

通過幫助工程師就資源分配做出更好的決策，Spotify將年度雲支出削減了數百萬美元。為什麼這麼重要？答案很簡單。基礎架構成本超過了使用者獲取速度，因此Spotify開始著手改變這條曲線，以更好地協調工程和業務目標。

Spotify的方法取得了成功，現在可以幫助其他遇到相同問題的公司。因此，Spotify於2020年10月開放了Cost Cost Insights開源專案，這是其與Backstage開展的更廣泛的開源和社群工作的一部分。

Spotify當然並不孤單。隨著組織將越來越多的工作負載遷移到雲中並在其中構建新的應用程式和服務，他們發現成本的蔓延是非常現實的。服務所有權是一個問題–誰負責賬單並降低成本？

Backstage

Backstage是Spotify公司內部的開發人員門戶。該公司的整個軟體交付供應鏈都通過Backstage進行管理-使用該平臺管理所有元件，資料，管道和服務，從構思到生產，包括監控和可觀察性。核心思想是為所有基礎架構工具，服務和文件提供統一的UI。Backstage是公司完成所有工程任務的前端。開發人員和操作流程都整合在一個控制檯中。Backstage是圍繞服務目錄構建的，該服務目錄使團隊能夠跟蹤支援他們正在構建的服務和產品的基礎結構。

後臺的核心用例包括：

• 建立一個新的微服務
• 在從審查到生產的拉動請求後
• 集中技術文件
• 審查團隊的移動功能的效能

無論是啟動Kubernetes叢集還是供應管道，Backstage都會抽象出很多複雜性。例如，– Spotify在引擎蓋下使用Jenkins，但是工程師不需要知道：他們只使用GitHub Enterprise和Backstage。

Backstage是構建開發人員門戶和管理軟體交付的平臺。

Spotify正在開放其自己的開發人員體驗（DX）基礎結構的這些元件的資源，以供工程界使用。鑑於許多組織都將Spotify的文化和流程視為理想的事物（即備受吹捧的“ Spotify模型”），因此人們會採用他們的工具是有道理的。我們已經看過Netflix、以及諸如Chaos Monkey，Spinnaker和Zuul之類的開源工具。就Backstage計劃而言，可以說比Netflix和Chaos Monkey的計劃走得更遠。

Backstage技術

Backstage是一個現代堆疊，主要使用帶有React前端的Typescript編寫。前端程式碼是用React編寫的，它定義了平臺的外掛架構。它使用Yarn程式包管理器和Lerna monorepo庫。程式碼格式化是使用Prettier進行的，而ESLint是用於linting的。作為一個現代化的堆疊，API閘道器當然是基於GraphQL的。

在部署方面，Backpot在支援Kubernetes環境（尤其是GKE）方面做得很紮實，這正是Spotify在內部使用的。對於文件，Spotify在MKDocs中採用了“文件即編碼”方法。

成本

Backstage已經成為Spotify工程師和工程團隊工作方式的核心，這一事實使其成為Cost Insights的天然歸宿。Spotify希望在一個工程師已經花費大量時間的地方進行成本優化，而不是試圖鼓勵他們使用其他第三方系統。

Backstage也是引導Cost Insights的地方，因為它基於服務目錄模型，並且已經提供了服務圖。希望利用此功能的第三方組織將必須進行一些前期工作建模，並將其內部API和服務對映到自己的產品和服務，但是構建這種服務圖對於任何組織都是有用的練習。

Cost Insights還支援標籤。工程師可以標記雲提供商的資源，以便它們與自己的內部條款，元件和服務名稱匹配，而不必依賴於雲提供商本身的賬單資訊。

這裡一個有用的方面是，在組織中，經常無法在計費方面正確表示多個團隊使用的共享基礎結構服務。一個團隊最終為該服務付費，而不是對其進行適當分配。後臺建模有助於內部退款。

什麼是FinOps？

Cost Insights不適用於一般企業。它的明確定位是供Spotify等大型公司使用：供其2k +微服務和4k資料管道，可幫助將數字歸因於特定的團隊，產品和服務。

Spotify還定期與同級雲公司（超大規模雲提供商的最大客戶）分享有關大規模運營，技術和支出方面的最佳實踐的註釋。它還使用術語FinOps（雲財務管理的簡寫）。該FinOps基金會是由Linux基金會執行。

FinOps的論點很有趣，因為Spotify及其同行與傳統企業的需求之間存在很大差異。即使是最數字化的企業，也沒有像Netflix或Uber那樣使用任何容量。

有許多FinOps供應商提供雲財務管理。Cloudability，CloudHealth和ParkMyCloud是知名的供應商。當然，您擁有Amazon自己的工具AWS Cost Explorer。

FinOps供應商通常是從財務人員而不是工程師的角度進入世界的。由於Spotify希望減少支出，因此它的第一個計劃-在以成本為中心的以工程為中心的計劃之前-已自上而下，重點是更好地預測和預先預訂GCP資源。

並非每個人都喜歡“ FinOps”運動。Duckbill Group的聯合創始人Corey Quinn認為FinOps不必要地使事情複雜化，而平時開發人員的良好做法例如，在不使用它們時將其關閉！卻是最好的前進方式。

但是應該使工程師能夠更好地瞭解他們的總服務成本，這沒有壞處：

Spotify在該領域的最早努力之一是將標籤應用到Spotify可以使用的術語和語言的每個雲資源上，而不是在雲提供商的標籤上。這意味著當工程師檢視此工具時，他們可以立即看到他們在日常工作中所瞭解的內容，而不是試圖弄清楚它對GCP的意義。

這些資料非常細緻-按雲產品顯示許可證，因此對於Google Data Flow或資料處理，開發人員可以看到按管道細分的成本，或者對於Google Compute Engine，開發人員可以看到Spotify服務名稱。然後可以將該資訊與不同的業務指標進行關聯並進行配置，例如，每日活躍使用者或每月訂戶。該平臺是可擴充套件的，因為Spotify當然希望第三方使用者擁有自己的KPI和指標。