Sam Lambert 是兼容 MySQL 的无服务器数据库提供商PlanetScale的首席执行官。在加入 PlanetScale（当时担任首席产品官）之前，他是 GitHub 的工程副总裁。
在这次采访中，Lambert 讨论了许多与云原生软件交付模型相关的话题，包括好的 serverless 是什么样的，谁应该运行 Kubernetes，以及“cloud-prem”的出现——一种结合了 on 优势的部署模型。 -prem 软件和 SaaS 产品。他还分享了他成为非创始人 CEO 的经历，以及他对何时以及如何从工程转向管理的建议。
未来：您已经描述了 PlanetScale 正在做什么——至少它不是纯 SaaS 产品——“云预置”计算。你如何定义这个词？
SAM LAMBERT： Cloud-prem是一种新模型——基本上是本地的云原生解决方案。传统上，公司必须要么拥有本地解决方案，要么拥有云解决方案，而跨越两者传统上是非常困难的。在 GitHub，我们面临着运行 github.com 和将 GitHub Enterprise 作为本地解决方案销售的压力。使用云产品，我们必须能够持续推动和交付。在此基础上进行发布是一项非常艰巨的任务，并且为两者构建架构意味着我们没有像我们本可以做的那样交付本地解决方案；这是非常艰巨的。
当我们来到 PlanetScale 时，我们决定只做云计算，但当然，您不能只使用数据库产品或具有严格合规要求的产品来做到这一点。因此，使用云预置，我们基本上将产品的数据平面部署到由用户管理的 VPC 中，在那里他们使用我们的控制平面来编排它并由我们管理。本质上感觉就像您只是在使用常规的基于云的 SaaS 产品，但数据驻留在您的帐户中。您的安全团队可以对其进行审核，并且他们感到在其基础架构范围内拥有它是安全和值得信赖的，而不必自己修补、发布和管理本地软件。
还有另一个额外的好处，例如，如果您是大客户，并且与亚马逊有很好的协商价格，您仍然可以支付该价格并将您在亚马逊的承诺支出保留在您的账户中。
你得到什么样的回击？那里有一些顽固的 SaaS 和本地商店……
我们可以为您提供纯 SaaS，我们将数据托管在我们的帐户中，人们对此完全满意。真正的阻力是如果人们只想要本地。但云预置模式真正开始引起共鸣。我们让受监管的公司使用该产品，因为他们看到了将数据保存在本地的双重好处，因此安全性或合规性很高兴，但也不必管理它。
这就是为什么这个模型如此独特和真实的时刻：因为它解决了不是公司不想在本地做的问题——而且它基本上是一个旧的、死的模型——但仍然主要满足要求那个本地会。
但是，是的，你有时还是会遇到阻力。有些公司只是不信任 SaaS 软件，但云正在迅速消除这一点。就像，您无法决定 Amazon 何时或如何更新 S3 并使 S3 变得更好，它只是发生了。这一切都是为了与许多客户建立信任，相信你是为他们管理特定工作的最佳公司，并帮助他们更适应这一点。
当您发布本地软件时，您无法构建最佳的开发人员体验。你无法持续改进。您无法管理质量、可用性、正常运行时间——所有这些都是体验的一部分。
开发人员可能对他们使用的数据库非常固执己见。 Cloud-prem 部署模型如何与开发人员体验相关联？
这更像是部署模型取消了阻止程序。当您发布本地软件时，您无法构建最佳的开发人员体验。你无法持续改进。您无法管理质量、可用性、正常运行时间——所有这些都是体验的一部分。如果您不自己管理服务，那么很难创造出如此高水平的体验。
当然，仅 SaaS 的一个主要障碍是某些用户需要将数据保持在他们的控制之下。本地部署的主要障碍可能是可扩展性。因此，云预置模型更像是一种机制，可以摆脱这些障碍，让每个人都能两全其美。
Kubernetes 在您的部署模型中扮演什么角色？您认为 Kubernetes 在云预置部署等总体上应该扮演什么角色？
Kubernetes 允许我们以非常标准化的方式部署到客户环境中，它看起来与我们内部运行的 Kubernetes 集群相同。在架构上，我们也是基于 Vitess，它在 Kubernetes 上运行并在 Borg 上开发，Borg 是谷歌 Kubernetes 的前身。所以，从本质上讲，它是非常自我修复的。如果你丢失了 pod 或者你丢失了基础设施，它会自我修复；故障转移不是您必须手动考虑的事情。
在我们的模型中，用户不必运行我们部署的 Kubernetes 集群。我们不做部署到现有 Kubernetes 集群的模型，一些本地供应商这样做是为了让它更容易。老实说，我怀疑这是否更容易。
大多数人不需要运行 Kubernetes。对于基础设施提供商来说，它是一个很好的后端，但我认为它不一定是大多数公司的正确部署机制。我认为很多人都走上了这条路，但发现这样做的价值很小或没有价值。
如果您将文件上传到 Dropbox，他们问您：“您希望我们保留多少台服务器以保持高可用性？”你会说，“这不是我付钱给你的吗？”
在您看来，是否有一定程度的规模开始变得有意义？还是一个特定的用例，比如运行一个内部平台团队？
如果您正在做我们所做的事情，您想要简化基础架构并拥有像 Kubernetes 这样灵活的东西，那么它很棒。但是这种级别的灵活性是如此开放，以至于如果你只是在建立一个电子商务公司，比如说，一个试图托管一个网站的公司，你不需要后端的 Kubernetes 来做这件事。
它被广泛采用，我认为很多人尝试构建这些内部平台，他们认为 Kubernetes 是一种拥有简单内部基础设施的方式。事实并非如此。最终用户体验还远远不够。人们应该将云用于最适合的事情，并让云和像我们这样的人运行 Kubernetes，以简化我们的工作。
但肯定有一点，一个组织有足够大的足迹来证明在内部运行像 Kubernetes 这样的东西是合理的，对吧？就像你在 GitHub 做的那样？
如果您有很多主机要管理——我们说的是数千台机器，而不是很多公司——并且您想要更能自我修复或可以利用大量机器的基础架构，它可以帮助您拥有处理这些事情的灵活性。
我认为每个公司的问题，无论技术选择是什么，都应该是：这对我们的客户来说是否与众不同？通过我们运行和管理此基础架构，最终用户的故事或要求是否会变得更好？如果答案是否定的，那么您根本不应该使用任何技术。
就像，现在基本上没有人可以证明运行自己的 Git 托管是合理的。不花低得离谱的钱让 GitHub 或 GitLab 为你做这件事真是太疯狂了。这是一个确定的论点；自己做没有任何好处。总的来说，随着无服务器和公正技术变得更好，这条线对每个人来说都是无处不在的。你只是不会建立一个比像我们这样的服务提供商更好的内部数据库团队或运营团队。
即使你这样做了，用户怎么知道？它将为您的用户群做什么？很少——99.9% 的时间，他们不关心你的技术堆栈。每家公司几乎都应该为自己的用户做一些事情，并尽可能多地利用托管基础设施。
安全性是一个用户体验问题，它非常基础。如果你让你的用户很难做正确的事情，就很难保证安全。
您如何看待安全和数据隐私问题的演变，尤其是对于 SaaS 提供商而言？
每个人都关心安全。作为一家托管人们数据的公司，我们必须非常认真地对待这一点。我看到的一个趋势是，公司比以往更快地获得合规认证。现在您必须立即获得SOC 2 认证，否则您将无法玩游戏。 （如果您想好好阅读，Fly.io 写了一篇关于 SOC 2的博文，值得一看。）
而且，总的来说，公司非常热衷于某些现在已成为赌注的功能，例如单点登录身份验证、审计日志记录和适当的可撤销访问令牌。
例如，现在，如果您不小心将数据库凭据检入公共 GitHub 存储库，我们会立即撤销它们，这样人们就无法访问您的数据库。这就是曾经发生过的事情——人们会将他们的 AWS 凭证推送到一个开源存储库中，然后他们的账户突然被用于比特币挖掘，他们已经花费了数万美元的账单，或者他们的数据是在互联网上
归根结底，我的热门观点是安全是一个用户体验问题，它是非常基础的。如果你让你的用户很难做正确的事情，就很难保证安全。如果您将安全设置为非默认设置，以及人们必须考虑和配置的内容，他们就更有可能犯错误。因此，例如，您不能以非加密方式连接到 PlanetScale – 您不能.人们想要它不是因为他们想要懒惰或者他们想要以某种方式做事。我们只是不让它成为可能。结果是没有人可以搞砸并通过互联网以纯文本形式发送他们的数据。这又是用户体验的一部分。
对于每一个 [云提供商服务]——亚马逊上有数百个——都有五家热门的年轻初创公司与之竞争。关心这么多用户和用例并保持规模化将变得非常困难。
你之前提到过无服务器。您对无服务器的工作定义是什么？
我描述它的方式是，好的无服务器产品应该只公开你为了完成工作而绝对需要控制的内容。如果您将文件上传到 Dropbox，他们问您：“您希望我们保留多少台服务器以保持高可用性？”你会说，“这不是我付钱给你的吗？”这是云的承诺吗？云应该不仅仅是添加 vCPU 和内存，而是在云中。
Serverless 说：“对用户而言，价值的单位是什么？用户想做什么？”它不会强迫他们做更多的事情。所以，对我来说，这是一个朝着简单和更好的产品设计方向发展的乐观运动。
您现在如何评估贵公司与云提供商之间的关系？ “敌人”是一个公平的描述吗？
这很有趣，因为我们在某些方面竞争，但我们也为他们的平台带来了更多的使用。对于运行我们托管的云预置版本的客户，我们与亚马逊代表合作，这样人们就不会离开去谷歌；他们留在亚马逊，他们使用我们的软件。所以销售代表仍然有大量的消费，我们得到了我们对整个交易的看法，这很棒。我认为他们会慢慢倒退，让像我们这样的公司成为最终用户体验。最终他们仍然赢了，因为他们仍在以越来越大的数量销售服务器。
但我们正处于这个有趣的中间阶段，他们不仅仅是大型零售商。他们仍然在某些产品上与我们竞争，但这变得越来越难，因为现在，对于他们的每一项服务——亚马逊上有数百个服务——都有五家炙手可热的年轻初创公司与之竞争。关心这么多用户和用例并保持规模化将变得非常困难。
如果你是那种不会一直试图爬上梯子的经理——只是按照你说的去做，你在做的时候是合议的，你帮助人们取胜，你推动人们向前 – 你自然会被带到更大的房间。
无关：你一开始就不是 PlanetScale 的 CEO。你从 CPO 到 CEO 的转变是如何发生的？
当我加入时，公司的做法有点不同。我们正在做托管 Vitess，这是我们拥有的旧产品。我决定要构建一个以 Vitess 为核心的出色数据库产品，其中 Vitess 是底层引擎，但不是最终产品。所以我们有点扔掉了旧产品，建造了这个新产品，它变得非常成功。然后我从我以前的公司 GitHub 和我认识的人那里雇佣了很多人。
那时，很多公司和文化都是与我一起工作的人——再次一起工作——所以文化和产品的双重转变是通过我想做的事情来实现的。最后一个合乎逻辑的事情是在该愿景下调整一切。这就是我成为首席执行官的原因。
这是一个简单的过渡，非常非常快地完成并尘埃落定。我的意思是，我们的创始人很棒。他们创办了这家公司，他们建立了这家公司，然后像许多创始人一样把它交给了公司。一些公司应该早点这样做。
你在 GitHub 的晋升也很快，从 DBA 升到了工程副总裁。对于成功进行这些类型的过渡，以及决定进入管理层是否合适，您有什么建议？
首先，如果你所在的公司需要成为经理才能产生影响，那你就错了公司。我认为很多人离开个人贡献者的角色去当经理只是为了留在房间里，这很糟糕。
我的建议是，如果你深切关心人并关心伟大的人可以取得的成果，那么就成为一名经理。你可能会走得太远，你只是一个人事经理，你不太关心工作。我认为你最终希望看到伟大的事物被建成，你通过伟大的文化和赋予人们权力来做到这一点。所以，如果你关心这些事情并且可以建立这些事情，那就成为一名经理。
我真的很在乎那些东西。我以工程师的身份加入 GitHub，我在那里产生了影响，我喜欢它。而且我知道，要扩大规模，为了我们继续做伟大的工程，我们需要伟大的管理。我想与优秀的工程师一起建立一种高绩效的文化。所以我开始这样做，我们有很多变化。公司在成长，但我只是一直与我认识的人一起工作，这些人做得很好，并且从那里成长起来。
你总是被要求做更多。如果你是那种不会一直试图爬上梯子的经理——只是按照你说的去做，你在做的时候是合议的，你帮助人们取胜，你推动人们向前 – 你自然会被带到更大的房间。这只是在一段时间内发生的。然后最终，是的，我在那里作为副总裁管理了一个大型团队，因为我总是做业务所必需的事情并坚持下去，努力工作并赋予人们权力。
我最自豪的事情是有多少人从 GitHub 来到 PlanetScale，因为他们知道这一点。你知道我的意思？他们不必这样做。对我来说，那是一个迹象，表明我可以始终如一地做我所说的作为领导者要做的事情。人们为此而来。
顺便说一句：很多时候，经理会毁了公司。我们写了一份管理宣言，阐述了我们对这个角色的感受。
如果你不能接受你的错误会扰乱人们的职业生涯，并且人们真正依赖你的想法，那么[管理]不适合你。
如果您是一名希望过渡到管理层的 IC，第一步是什么？
我认为你必须开始学习从社会学角度思考团队和周围人的动态，以及如何影响人们作为一个团队一起工作的方式。例如，成为一名技术领导者比仅仅编写最好的代码有更多的社会动力。您必须考虑我们所依赖的事物、我们所依赖的人，以及我们如何塑造我们的组织以反映我们将要做的工作——而不必深入了解人们的想法和感受并实际管理他们.所以一个好的方法是尝试和领导一个有很多跨职能工作和依赖关系的项目，并且需要人们一起运作良好，看看你是否有能力激励人们作为一个团队完成他们的工作。
如果你能成功地做到这一点，那么你就可以开始学习与人真正合作并成为他们的经理所需的技能。因为这是一个很难的角色；这是奴役的角色。人们把他们的事业交给你，这是你必须非常认真对待的事情。如果你不能接受你的错误会影响人们的事业，人们真的依赖你的想法，那么它不适合你。
如果您认为自己可以做到并希望帮助人们成为更好的自己，请深入研究。
Cloud-Prem 和 Climbing the Engineering Ladder 上的 PlanetScale CEO后首次出现在Future上。
原文： https://future.com/planetscale-cloud-prem-engineering-management/