上周，RedMonk的行业分析师和朋友（特别是James Governor）写了一篇博客文章，详细介绍了Spotify对Backstage的使用， Backstage是面向云基础架构的内部开发人员门户。
尽管总体上对Duckbill Group以及我本人都有足够的称赞，有点脸红，但我仍然觉得这是一种“错误的方向”建议。本周早些时候，一份协议文章标题为“为什么Spotify喜欢被锁定在Google Cloud中”，而且变得越来越明显，我需要更加深入地阐明自己的观点。
什么是Backstage
Backstage自我描述为构建开发人员门户的开放平台。换句话说，它提供了一种特定于公司的方式来实现围绕云基础架构的控件，并且它还具有插件功能以支持新功能。它来自Spotify本身，并且多年来一直是开源的。
实际上，它是构建自助式内部工具的入口，使工程师能够以预先批准的方式获得符合法规，法规和工程要求的现成架构，以便与云供应商合作。
在理想情况下，Backstage不只是推出IaaS工具。他们正在推出比这更高级的东西：除了诸如容器，负载平衡器和其他“基础”组件之类的低级原语之外，还有：“这是我们默认配置的nginx；这是为应用程序支持的Ruby on Rails版本；这是CloudFront配置可以使内容在更快运行。”
我认为这是错误的方向。作为一个数据点：Backstage是一个我从未见过在任何地方部署的项目。
开发者门户的问题？
构建内部 in-house工具来总管云服务会存在一些问题：
他们的第一个（也是最自私的）是，它使公司的工程师失去了发展可重复使用技能的机会。如果您成为处理由雇主建立的内部开发人员门户的专家，那么基本上在地球上任何其他公司中都无法为您提供满意的服务。（banq注：意思你没有办法跳槽了）
其次，开发人员门户网站固有地落后于基础服务的功能。如果AWS，GCP或任何人增强了服务，则由开发人员门户网站的维护者来更新和反映更改。
门户将过多地依赖于其“插件驱动”模型，这听起来像是一种礼貌的方式来表达“欢迎Pull请求”，而这反过来又是一种礼貌的方式：告诉人们自行制造和建造它。
如果您仅通过开发者门户查看IaaS容器，VM，存储和负载平衡器的配置也许就可以了，但是，当您将其与CloudFlare域，PagerDuty警报以及更高级别的差异化服务结合使用时，它看起来就很奇怪。
第三种问题是：无法体现Kubernetes好处，是的，绝对如此。它已经广泛部署，您可以找到很多人来为您运行它，仅仅因为它对于底层云提供商而言看起来是非常奇怪的，因为它是具有非常奇怪的行为模式的整体式应用程序，并不意味着它完全没有优点。