PlanetScale首席执行官谈云计算和攀登工程阶梯
Sam Lambert是PlanetScale的首席执行官，PlanetScale是一家兼容MySQL的无服务器数据库提供商。在加入PlanetScale（时任首席产品官）之前，他是GitHub的工程副总裁。
在这次采访中，Lambert讨论了许多与云原生软件交付模型相关的主题，包括什么是好的无服务器，谁应该运行Kubernetes，以及“cloud-prem”的出现——一种结合了on-prem软件和SaaS产品优势的部署模型。他还分享了自己成为非创始人首席执行官的经历，以及何时以及如何从工程转向管理的建议。
未来：您已经描述了PlanetScale正在做什么——至少它不是纯粹的SaaS产品——“云预处理”计算。你是如何定义这个术语的？
SAM LAMBERT：Cloud prem是一个新的模型——基本上是on prem的云原生解决方案。传统上，公司必须有一个预处理解决方案或云解决方案，而传统上很难兼顾两者。在GitHub，我们面临着运行GitHub.com和将GitHub Enterprise作为预处理解决方案进行销售的压力。有了云产品，我们必须能够不断地推动和交付。在此基础上削减发布是一项非常困难的任务，为两者构建架构意味着我们没有像本可以做的那样提供预处理解决方案；这是非常艰巨的任务。
当我们来到PlanetScale时，我们决定只做云计算，但当然，你不能只使用数据库产品或有严格合规要求的产品。因此，使用cloud-prem，我们本质上是将产品的数据平面部署到用户管理的专有网络中，用户使用我们的控制平面对其进行编排，我们对其进行管理。这本质上感觉就像你只是在使用常规的基于云的SaaS产品，但数据驻留在你的帐户中。您的安全团队可以对其进行审计，他们可以感受到将其放在基础设施范围内的安全性和信任，而不必自己修补、发布和管理预处理软件。
还有一个额外的好处，那就是如果你是一个大客户，与亚马逊的谈判价格很高，例如，你可以继续支付该价格，并将你在亚马逊的承诺支出保留在你的账户中。
你会受到什么样的抵制？有一些顽固的SaaS和在线商店…
我们可以为您提供纯SaaS，在那里我们将数据托管在我们的帐户中，人们对此完全满意。真正的阻力是，如果人们只是想要预先准备。但cloud-prem模型确实开始引起共鸣。我们让受监管的公司使用该产品，因为他们看到了将数据保存在本地的双重好处，因此安全性或合规性是令人满意的，但也不必管理它。
这就是为什么这个模型如此独特，令人敬畏，是一个真实的时刻：因为它解决了一个问题，即不是公司不想在prem上做这件事——基本上，它是一个过时的、过时的模型——但仍然基本上满足了在prem的要求。
但是，是的，你有时还是会遇到阻力。有些公司就是不信任SaaS软件，但云正在迅速消除这种信任。比如，你无法决定亚马逊何时或如何更新S3并使S3变得更好，这只是偶然发生的。这一切都是为了与很多客户建立信任，让他们相信你是为他们管理特定工作的最佳公司，并帮助他们更适应这一点。
当你使用prem软件时，你无法建立最好的开发人员体验。你不可能不断进步。你无法管理质量、可用性和正常运行时间——所有这些都是体验的一部分。
开发人员可能对他们使用的数据库非常固执己见。云预部署模型如何与开发人员体验对话？
这更像是部署模型去掉了阻塞器。当你使用prem软件时，你无法建立最好的开发人员体验。你不可能不断进步。你无法管理质量、可用性和正常运行时间——所有这些都是体验的一部分。如果你不自己管理服务，很难创造出如此高水平的体验。
当然，仅SaaS的一个主要障碍是一些用户需要将数据控制在自己的控制之下。on-prem的一个主要障碍可能是可扩展性。因此，云prem模型更像是一种机制，可以消除这些障碍，让每个人都两全其美。
Kubernetes在您的部署模型中扮演什么角色？你认为Kubernetes在云预部署中的总体角色是什么？
Kubernetes允许我们以非常标准化的方式部署到客户环境中，它看起来与我们内部运行的Kubernete集群相同。在架构上，我们也基于Vitess，它运行在Kubernetes上，是在谷歌Kubernete的前身Borg上开发的。因此，从本质上讲，它是非常自我修复的。如果你失去了吊舱或基础设施，它几乎可以自我治愈；故障切换不需要手动考虑。
在我们的模型中，用户不必运行我们部署的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说，“用户的价值单位是什么？用户想做什么？”除此之外，它不会强迫他们做任何事情。所以，对我来说，这是一场乐观的运动，朝着简单和更好的产品设计发展。
您现在将如何评估您的公司与云提供商之间的关系？“朋友”是一个公平的描述吗？
这很有趣，因为我们在某些方面进行竞争，但我们也为他们的平台带来了更多的使用。对于运行我们的托管云prem版本的客户，我们与亚马逊代表合作，这样人们就不会离开去谷歌；他们留在亚马逊上，使用我们的软件。所以销售代表仍然有大量的消费，我们得到了整个交易的结果，这很好。我认为他们会慢慢倒退，让像我们这样的公司成为最终用户体验。最终，他们仍在获胜，因为他们仍在以越来越大的销量销售服务器。
但我们正处于一个有趣的中间阶段，他们不仅仅是大型零售商。他们仍然在某些产品上与我们竞争，但这变得越来越困难，因为现在，他们的每一项服务——亚马逊上有数百项——都有五家热门的年轻初创公司与之竞争。要关心这么多用户和用例并保持其规模化将变得非常困难。
如果你是那种不总是试图爬梯子的经理，而是按照你说的去做，并且你在做的时候表现得很好，你帮助人们获胜，推动人们前进，你就会自然而然地被带到更大的房间里。
毫无疑问：你一开始就不是PlanetScale的首席执行官。你是如何从首席执行官转变为首席执行官的？
当我加入时，公司的做法有点不同。我们正在做托管Vitess，这是我们的老产品。我决定构建一个以Vitess为核心的令人惊叹的数据库产品，Vitess是底层引擎，但不是最终产品。所以我们扔掉了旧产品，建造了这个新产品，它变得非常成功。然后我从我以前的公司GitHub雇佣了很多人，还有我熟悉的人。
当时，很多公司和文化都是来和我一起工作的人——再次合作——所以文化和产品的双重转变是通过我想做的事情来实现的。最后一件合乎逻辑的事情是在这个愿景下调整一切。这就是我成为首席执行官的原因。
这是一个简单的过渡，完成得非常非常快。我的意思是，我们的创始人都很棒。他们创办了这家公司，建立了公司，然后像许多创始人一样放弃了它。有些公司应该早点这样做。
你在GitHub的晋升也很快，从DBA晋升为工程副总裁。对于成功地进行这些类型的转变，以及决定进入管理层是否正确，你有什么建议？
首先，如果你所在的公司需要成为一名经理才能发挥任何影响力，那么你就错在了一家公司。我认为很多人离开个人贡献者的角色去当经理，只是为了留在房间里，这太可怕了。
我的建议是，如果你非常关心别人，关心伟人能取得的成果，就要成为一名管理者。相反，你可能会走得太远，你只是一名人事经理，对工作不太关心。我认为你最终希望看到伟大的东西被建造起来，你通过伟大的文化和赋予人们权力来做到这一点。所以，如果你关心这些东西，并且能够建立这些东西，就成为一名管理者。
我真的很在乎那些事。我作为一名工程师加入了GitHub，我在那里产生了影响，我喜欢它。我知道，为了扩大规模，为了继续做出色的工程，我们需要出色的管理。我想与伟大的工程师一起建立一种高绩效的文化。所以我开始这么做，我们有很多改变。公司发展了，但我一直与我认识的做好事的人合作，并从那里成长起来。
你总是被要求做得更多。如果你是那种不总是试图爬梯子的经理，而是按照你说的去做，并且你在做的时候表现得很好，你帮助人们获胜，推动人们前进，你就会自然而然地被带到更大的房间里。这只是在一段时间内发生的。最后，是的，我作为副总裁在那里管理着一个庞大的团队，因为我总是做业务所必需的事情，并坚持下去，努力工作，赋予人们权力。
我最自豪的是，有多少人从GitHub来到PlanetScale，因为他们知道这一点。你知道我的意思吗？他们不必这么做。对我来说，这表明我已经表明，作为一名领导者，我可以始终如一地做我说过要做的事情。人们是为了这个而来的。
顺便说一句：管理者往往会毁掉公司。我们写了一份管理宣言，阐述了我们对这个角色的感受。
如果你不能处理这样一种想法，即你的错误会扰乱人们的职业生涯，人们真的依赖你，那么[管理]不适合你。
如果你是一名IC，希望过渡到管理层，第一步是什么？
我认为你必须开始学习从社会学角度思考团队和周围人的动态，以及你如何影响人们作为一个团队的合作方式。例如，成为一名技术领导者，不仅仅是编写最好的代码，还有更多的社会动力。你必须思考我们所依赖的东西，我们所依赖人，以及我们如何塑造我们的组织，以反映我们将要做的工作——而不必深入到人们的想法和感受中，并实际管理他们。因此，一个好的方法是尝试和领导一个有很多跨职能工作和依赖关系的项目，需要人们一起工作，看看你是否有能力激励人们作为一个团队完成他们的工作。
如果你能成功地做到这一点，那么你就可以开始学习与他人合作并成为他们的管理者所需的技能。因为这是一个艰难的角色；这是一种奴役的角色。人们把他们的事业交给你，这是你必须认真对待的事情。如果你不能接受这样的想法，即你的错误会扰乱人们的职业生涯，人们真的依赖你，那么这不适合你。
如果你认为你能做到，并且想帮助人们成为更好的自己，那就努力吧。