Spotify模型的統一運維開發者門戶Backstage是一種反模式 - lastweekinaws

什麼是Backstage
Backstage自我描述為構建開發人員門戶的開放平臺。換句話說，它提供了一種特定於公司的方式來實現圍繞雲基礎架構的控制元件，並且它還具有外掛功能以支援新功能。它來自Spotify本身，並且多年來一直是開源的。
實際上，它是構建自助式內部工具的入口，使工程師能夠以預先批准的方式獲得符合法規，法規和工程要求的現成架構，以便與雲供應商合作。
在理想情況下，Backstage不只是推出IaaS工具。他們正在推出比這更高階的東西：除了諸如容器，負載平衡器和其他“基礎”元件之類的低階原語之外，還有：“這是我們預設配置的nginx；這是為應用程式支援的Ruby on Rails版本；這是CloudFront配置可以使內容在更快執行。”
我認為這是錯誤的方向。作為一個資料點：Backstage是一個我從未見過在任何地方部署的專案。
  

開發者門戶的問題？
構建內部 in-house工具來總管雲服務會存在一些問題：
他們的第一個（也是最自私的）是，它使公司的工程師失去了發展可重複使用技能的機會。如果您成為處理由僱主建立的內部開發人員門戶的專家，那麼基本上在地球上任何其他公司中都無法為您提供滿意的服務。（banq注：意思你沒有辦法跳槽了）
其次，開發人員入口網站固有地落後於基礎服務的功能。如果AWS，GCP或任何人增強了服務，則由開發人員入口網站的維護者來更新和反映更改。
門戶將過多地依賴於其“外掛驅動”模型，這聽起來像是一種禮貌的方式來表達“歡迎Pull請求”，而這反過來又是一種禮貌的方式：告訴人們自行製造和建造它。
如果您僅透過開發者門戶檢視IaaS容器，VM，儲存和負載平衡器的配置也許就可以了，但是，當您將其與CloudFlare域，PagerDuty警報以及更高階別的差異化服務結合使用時，它看起來就很奇怪。
第三種問題是：無法體現Kubernetes好處，是的，絕對如此。它已經廣泛部署，您可以找到很多人來為您執行它，僅僅因為它對於底層雲提供商而言看起來是非常奇怪的，因為它是具有非常奇怪的行為模式的整體式應用程式，並不意味著它完全沒有優點。