为什么 Spotify 喜欢被“锁定”在 Google Cloud 中？

Spotify 的工程副总裁泰森·辛格（ Tyson Singer ）认为跟  Google 捆绑没有什么问题

译者注：Spotify 是全球最大的音乐流媒体服务公司之一，截止至 2021 年 3 月，月活用户超过3.56 亿，付费用户 1.58 亿。5 年前，Spotify 决定  All-in GCP，即  Google Cloud Platform  谷歌云平台。

有些公司非常乐意绑定到单个云厂商，Spotify 是其中一个。

Spotify 可以说是 Google Cloud 最受瞩目的客户之一，五年前开始迁移到 Google，当时 Google 对公有云的长期投入都还受到部分人质疑。从那时起，Spotify 在 Google 的基础设施上搭建的音乐和播客服务翻了一番。关于使用云高级服务搭建应用的问题，他们放弃便利性和易用性，转向容易移植性。

Spotify 技术与平台副总裁泰森·辛格觉得这样很好，他负责管理 Spotify 服务的基础架构，月活3.56 亿用户。Spotify 的 2,000 多名开发人员和技术专业人员还拥有一个称为 Backstage 的秘密武器，这是一种内部开发的管理控制台，让开发人员通过统一的用户界面使用 Spotify 工具库中的数十种工具。在 CNCF 开源项目中可以找到 Backstage。

最近在媒体 Protocol 的采访中，辛格讨论了该公司将其资产与 Google Cloud “结婚”的决定，使用托管服务的利弊，以及“ ML Ops”为何成为他的下一个热门话题。

为了清晰起见，本次采访已被编辑和压缩。

几年前，Spotify 向 Google Cloud 进行了大规模迁移，情况如何？

我们全部用（ All-in ） GCP。那是几年前我们做的一个非常有意义的行动，使我们脱离了繁杂的日常工作，即基础设施管理，从而公司将精力集中在更高层次的事情上。我认为，我们所做的与您看到的许多公司有所不同。

因此，如果您要将我们与 Netflix 相比较，我们所做的是将全部精力集中在一个供应商上，而且我们当时还将全部精力放在那些高级托管服务上。这是把整个方法论加倍的一种方式，我们希望将更多的时间花在业务上，而将更少的时间花在基础架构上。对于领导基础架构组织的人来说，这是一件有趣的事情，但这是我真正认同的。

另一个驱动是速度。我们是一个以速度为导向的公司，我们的口号是赋能每个 Spotify 员工和我们所有的产品以速度、规模和安全。

为什么选择 Google ？

我们做了每个人在寻找云供应商时都做的常见的尽职调查。但是，真正让 Google 脱颖而出的是这几件事：

第一，他们在数据方面处于领先地位。我们意识到，按我们注入的数据量，需要一个能够处理如此复杂性和规模的数据，并使我们超越现有能力的合作伙伴。当时，我们拥有欧洲最大的 Hadoop 集群，但对于我们而言，它仍然受到很大的限制。

其次，我们需要一个在文化上适合我们的合作伙伴，并且与当时的其他一些可能选择相比，我们觉得我们（对云服务）确实可以产生影响。Google 肯定符合这两个条件，因为他们是新进入者，而且他们的工程团队具有很多与自主性和独立性相关的文化，并真正专注于卓越的工程。

这很有趣，因为即使从 Google 员工那里我也听说过，他们一直在努力的一件事是试图站在客户的角度，去理解并不是每个客户都需要 Google 那么大规模的方式来做他们的工作。但这听起来对您来说确实很有吸引力。

是也不是。就像在任何良好的合作关系中一样，我们有时确实也存在冲突。他们一直在学习如何站在客户的角度，他们的学习过程（可能不是用 Google 的方式），了解到还有其他各种出色的工程团队可能会做不同的方式，这是有道理的。

因此，这是一段美好的旅程。而且由于我们是他们的大客户，我们也能够帮助他们继续前行。

我想再谈一下托管服务问题，我认为这很有趣。一个月前，我采访了 Target 的 Mike McNamara，他的看法恰恰相反：我不需要任何托管服务，我想自己运营所有服务，我们知道我们必须投资于人员和技能才能做到这一点，但是我们想要这种灵活性。

您能谈谈这背后的哲学吗？围绕 Google 托管服务进行构建的优缺点真的会让您长期困扰吗？

故事的一部分最近发生了变化。回到我之前说过的两件事，那就是我们首先要优化速度。其次，我们受制于数据生态系统。

例如说 BigQuery，该产品的可访问性和可扩展性，以及自己构建此类产品的复杂性，都让使用托管服务具有巨大的吸引力。

实际上，针对上述情况，我们跟踪了整个公司中 BigQuery 的使用情况，以及员工人数（尤其是对数据处理不是很精通的技术员工）。我们看到了 BigQuery 使用量呈现疯狂的指数上升。就像是说，“好吧，是的，我们以更快的速度来提取业务洞察力。” 那对当时的我们来说最重要。

但是，随着我们更多地采用这些托管服务，效率问题就开始出现。从我要照顾的客户（其他 Spotify 员工）的角度来看，我们希望他们能用更高层的抽象服务，这样他们不需要深入了解基础架构的细节；我们正在研究和分层打造我们自己托管服务，以便获得更好的效率规模和更好的单位成本。

我澄清一下，这么说，您是在 GCP 之上构建自己的 Spotify 托管服务。而不是使用某些 Google 托管服务？

是的，非常对。我们还没全面铺开。我们目前是在我们认为确实会对我们的整体预算和支出的效果产生影响的地方这样做。

您能否谈谈一些您针对的目标领域？

数据处理是我们研究并正在构建的领域之一。对此我们对 Google 非常透明。我们也正在努力开发其他一些我不想公开分享的服务。但是[数据处理]可能是最主要的，因为我们也正在开源领域中做这个。

我们还要做的一件事是，从完全考虑速度，到现在我们公司已经有点“多余脂肪”了，我们需要考虑优化在云上的花费。这是真正改变工程文化和思维方式的过程，这种文化和观念集中在围绕性能和可伸缩性，可靠性，可观察性的许多重要方面。工程师喜欢从事的所有工作，但他们并没有把重点放在成本上。

因此，我们利用了一个已经花很多时间在上面的工具，就是我们的开发门户网站 Backstage，我们的工程师非常喜欢，并将插件添加到该生态系统。它是一个成本洞察插件，使我们能够在云计算发展中迈进一步，以便越来越多的工程师可以在对他们有意义的环境中了解他们的工程决策对公司底线的影响。

Backstage 看起来可以支持多云环境。您在构建它时是否想到了这一点？

我们真心希望 Backstage 项目成功，因为它对我们公司的运营至关重要。这是开发人员，数据科学家甚至有时是设计师要看的唯一一个平台：构建软件，管理软件，创建软件以及查找新软件。不管数据是什么，例如新的数据管道，新的后端服务或移动设备上的新功能，新的 ML 功能，都无关紧要。一切都在场景中。

因为这对于我们开发很重要，所以我们希望与全世界分享。我们希望它作为开发者门户获得广泛采用。因此，它不仅需要在 GCP 上工作，还必须在 AWS 上工作，并且必须在 [ Microsoft ] Azure 上工作。

但是就 Spotify 而言，您似乎不太热衷于自己部署多云？

不，不是很热衷。拥有单个云很简单，这为我们节省了很多麻烦和复杂性。

您最感兴奋的是现在哪种新的企业级技术，或者您认为哪些技术可能会对 Spotify 产生最大的影响？

我们已经投入了一段时间的领域之一是 ML Ops 或 ML 基础架构，并将我们解决方案的不同模块组合在一起。我看到越来越多的公司投入这一领域，但我觉得整个市场中的这个领域的服务还不够好。云提供商并没有很好地提供这个服务，并没有真正将支持整个生命周期绑在一起。我认为我们已经非常接近将其连接在一起了。但是我已经看到了很多投入，这实际上非常令人兴奋。

您怎么定义 ML Ops？

通常 ML 的难点是从训练模型到投入生产，并确保您可以执行所有其他人都习惯使用的各种标准软件来进行开发。能够进行 CI / CD，并可以在这些生态系统中反复进行实验。

利用我们的基础架构，将可持续地创建新模型，在我们的实验平台上运行它，然后看到指标，并能够组织所有这些且将其保持不变。这使新加入 Spotify 的员工能真正专注于目前的问题，进行先进的 ML 研究。这是我需要考虑的 ML Ops 的各个方面。