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和指标。