暂无图片
暂无图片
2
暂无图片
暂无图片
暂无图片

专访 Cockroach 数据库 CEO Spencer Kimball

原创 通讯员 2022-11-22
941

Cockroach Labs 是一家野心勃勃的数据库公司,名字很有趣,在过去几年中不断壮大。它于 2014 年由三名前 Google 员工创立,早年成功渡过了险境,成为一家早期的数据库公司,客户需要信任他们的关键任务应用程序。随着时间的推移,它获得了巨大的发展势头,拥有一长串重要客户,最近的估值为 5B 美元。


部分原因是我们 FirstMark 是公司的骄傲投资者,多年来我们在 Data Driven NYC 上多次展示了 Cockroach Labs。


很高兴再次接待 CEO Spencer Kimball 并了解最新情况,以及建立一家成功的开源企业软件公司的经验教训。

我们介绍了很多非常有趣的事情,包括:

  • 公司的起源
  • 数据库市场从 SQL 到 NoSQL 再到 NewSQL 再到云的演变
  • 无服务器的当前机会
  • 开源许可证问题
  • 进入市场:社区主导,自下而上,自上而下?
  • 谁是企业软件公司的完美第一销售人员


采访纪要

马特图尔克(00:02):

好的,斯宾塞,欢迎回来。所以这实际上是我们第四次以 Cockroach 为特色。所以第一次实际上是在 2014 年 1 月,感觉很疯狂。

斯宾塞·金博尔(00:15):

真的是一月吗?我认为公司直到 2 月才开始运作。

马特图尔克(00:21):

好的。

斯宾塞·金博尔(00:22):

也许是在公司成立之前。

马特图尔克(00:24):

这是超级早。我是一个自豪的投资者。FirstMark 是 CockroachDB 的一位自豪的投资者,故事就是我如何爬进交易的,就像,“嘿,这实际上是纽约的一个数据社区,它是为真正的人来这里学习技术的。” 我想你很可怜我。就像,“哦,这家伙很努力,所以我们可以让他进来。” 所以我认为那是……

斯宾塞·金博尔(00:51):

不,当时很荣幸成为 DataDriven 的一员。我认为我们得到了一些非常有趣的线索,而且我们的产品还处于早期阶段。但只是来自社区中的人们的兴趣。所以这样做是非常值得的,如果这里有人正在创业,并且你有机会参与 DataDriven,我推荐它。

马特图尔克(01:11):

好的,很好的答案。谢谢你。那是 2014 年,然后你又回到了 2018 年,然后我们有 Nate Stewart,你的首席产品官兼董事会成员,他在网上大流行期间表现出色,所以这是一个四人组,这太棒了。也许如您所知,快速复习一下 Cockroach Labs 和 CockroachDB,您是如何开始它的,为什么开始它,产品有什么作用,所有这些好东西。

斯宾塞金博尔( 01:34 ):

CockroachDB 是一个关系数据库。对于那些不知道那是什么的人,想想 Oracle 的旗舰数据库,它可能是最著名的 IBM Db2,您可以在大型机上运行它。微软 SQL Server、Postgres、MySQL。所以这些都是关系数据库,我认为,如果你退后一步,这些都是操作数据库,所以它们是为你的用例保存所有元数据的数据库。所以你库存中的项目,如果你正在做库存管理,余额和借方以及账户中的东西,如果你正在做一些金融服务用例,那就是你放在运营数据库中的东西将其与 Snowflake 之类的分析数据库进行对比,或者这可能是最常见的数据库之一,但它们有很多。

(02:22):

有这么多数据库的原因是因为一切都需要数据库。世界上的每一个用例都有这些东西为其提供动力,并且该市场正在快速增长,因为人们正在构建新的用例。因此,竞争非常激烈,解决方案空间中也有很大的空间来寻找完美的能力组合来挑战极限。由于生态系统中的事物变化非常迅速,因此有很大的空间可以改进操作数据库的工作方式,特别是使用云来真正利用它来制作我们想要制作的所有产品或所有基础设施事物在功能方面更好,在性能方面更快,而且更便宜。我们确实努力做到这三件事,有些比其他的更好,但它总是在进行中。

马特图尔克(03:12):

你想双击过去的关系数据库 Oracle 的历史记录,而不是选择它们,将数据库记录到 NewSQL 吗?进化是什么?

斯宾塞金博尔(03:27):

哦。是的,在这些系统的演进过程中,你可以编织出许多不同的线索。我认为甲骨文可能是我们从那里开始的。它们当然不是这些关系操作数据库中的第一个,但它们确实在 90 年代和早期的赔率中变得方兴未艾。然后我认为 Cockroach 的故事真正开始的地方是当万维网开始崭露头角时,突然间出现了实际上比您所谓的企业用例更大的用例,在企业用例中,您拥有一定数量的客户公司,突然间你可以接触到世界上大多数拥有台式电脑的人,然后稍后再接触某种移动应用程序。

(04:12):

这实际上在现有操作数据库(如 Oracle 或 MySQL)可以提供的功能与用例需求之间拉开了差距。2002 年我在谷歌工作,我们率先使用他们的 AdWords 系统来解决这个问题,该系统很快就超出了单个 MySQL 实例的容量。所以他们开始添加更多的 MySQL 实例,他们将客户分配给他们拥有的 MySQL 实例,然后他们不得不将其加倍,再加倍,再加倍,这实际上开始产生各种其他问题。因此,谷歌开始在数据库方面进行创新。所以他们建立了 Bigtable。

(04:49):

Bigtable,真的,我认为你可以指出其中一个例子,在计算机科学中没有什么新鲜事,但它绝对是一个引入 NoSQL 概念的突出例子。所以谷歌实际上非常专注于制作一个非常可扩展的操作数据库,而 Bigtable 是他们的答案,他们的第一个答案。Bigtable 的有趣之处在于他们追求规模,他们放弃了关系数据库在其功能方面已经发展的所有东西,这些东西与仅仅使事情变得非常非常大没有直接关系。所以它没有事务,没有用于查询的关系语言,也没有很多可以帮助您管理复杂性的模式管理工具。

(05:34):

但这没关系,因为谷歌只需要变得非常非常大的东西。但即使在两年后,他们仍然说:“你知道吗?我们无法在没有事务的情况下构建应用程序用例。” 所以他们构建了一个叫做 Megastore 的东西,然后他们认为 Megastore 只是一个半成品,他们想从头开始重新设计,于是他们构建了一个叫做 Spanner 的东西。

(05:52):

Spanner 仍然是 Google 在内部构建并在 GCP 上提供的东西。真正启发 Cockroach 的是 Spanner。在谷歌工作了 10 年后,我和我的两位联合创始人离开了,建立了一家私人照片共享公司。我们从在谷歌主要做基础设施转变为思考,“你知道吗?我们想构建一些供人们使用,尤其是供我们使用的东西,”因为我们不喜欢公开分享东西,但我们想在与朋友周末旅行时分享我们所有的照片,这被称为取景器。我们没有找到适合它的产品市场。我认为 Snapchat 当时是另一种选择,我认为它可能比我认为的更成熟的更符合公众的脉搏,但可能过于复杂的解决方案。但我们确实希望为 Viewfinder 构建后端,以便它可以像 Google 的基础架构一样进行扩展。

(06:51):

这就是 Cockroach 的想法诞生的地方,因为我们意识到来自谷歌,谷歌在内部开创的那些功能在开源中是不可用的,至少现在还没有。所以Cockroach的想法诞生了,我们说,“你知道吗?类似 Spanner 的功能应该作为开源产品推向市场,供其他所有人使用。” 我们没有将它构建为 Viewfinder,因为我们试图构建一个私人照片共享应用程序和平台,但我们在那段旅程的两年后被 Square 收购,在 Square,我们看到了,“你知道吗?作为一些前谷歌工程师,这个问题比我们的初创公司要大得多。”

(07:30):

Square 也在与数据库作斗争,我们说过,如果你看看 Square 遇到的所有问题,当我们加入他们时,他们有大约 70 个面向外部的用例,他们正在努力解决的大部分问题都可以通过使用来解决像 Spanner 这样的东西。所以这真的让我们想起Cockroach的想法,我们在 Square 待了大约 14 个月,然后我们说,“你知道吗?根据我们看到的信号,以及你与在 Dropbox、Pinterest 和 Yelp 工作的人交谈,每个人都有这些问题,我们说我们确实需要追随这个梦想和这个雄心,并围绕它建立一家公司。” 那几乎就是我遇见你的时候。

马特图尔克(08:08):

是的。因此,CockroachDB 的基本前提是在可扩展性和事务可靠性方面做到最好。我猜今天的产品有什么作用?

斯宾塞金博尔(08:23):

是的,所以这实际上提出了一个问题,你们中的一些人可能会在脑海中打扰你。为什么我们称任何东西为 CockroachDB?它不完全是一种流行的昆虫。它真正围绕着生存能力,这是我们从一开始就试图构建到产品中的关键因素之一,也是激励谷歌的 Megastore 和谷歌的 Spanner 的因素之一。这是一个类似的想法,“嘿,在公共云中,情况有所不同。你的数据中心就在东海岸,你有很多数据中心可供选择,而且它们靠得很近,如果你能平衡它们之间的数据,你可能会失去整个数据中心,实际上不会错过任何一个节拍。没有事后分析,没有四处奔波试图让事情恢复在线,可能会丢失数据。事情可能会在几秒钟的延迟后继续进行。” 所以那真的很酷。我们内置了它。

(09:12):

我们开始解决的另一个大挑战是规模。所以我们真的希望能够支持巨大的用例,但你不一定知道你的用例是否会很大。一个很好的例子是,如果您正在尝试构建游戏,如果您使用无法正确扩展的错误后端基础架构构建游戏,那么如果您的游戏很受欢迎,那么您将遇到成功的灾难,因此您的事情只会一败涂地重新架构这样的事情不是你一夜之间就能完成的。所以你可能真的会失去游戏在早期阶段可能拥有的动力,而你真的想利用它。

(09:53):

我认为这对任何初创公司、任何 SaaS 用例、任何你正在构建的东西都是如此,如果你在总体上取得成功,你的数据需求将会很大。所以 Cockroach 确实是为扩展而构建的,可以从小处着手,然后可以变得非常、非常、非常大,比我提到的那些传统关系数据库之一大得多,例如 Oracle。这些确实有上限。

(10:14):

有趣的是,这些功能确实是我们在这八年旅程中的起点,我们已经意识到该架构支持其他非常有趣的功能。当我说架构时,思考 Cockroach 的方式是它是分布式的,有很多节点参与,这是它变得如此庞大的一部分,也是它能够生存的一部分。你失去了一个数据中心?好吧,还有其他正在运行的 Cockroach 节点具有一些在其他数据中心运行的冗余,这些节点可以弥补不足。我们还意识到,我们越来越多地与之交谈的公司是跨国公司,甚至是初创公司,但他们非常想招待可能加入他们或使用来自巴西、土耳其或日本的大型多人游戏平台的客户。您真的很想尝试支持那些更全球化的用例。所以我们意识到,“嘿,我们有一个分布式架构,我们应该能够在操作数据库中引入新功能来支持它。”

(11:16):

因此,如果您考虑像 Twitter 或 Quora 这样的东西,如果有人发布了一些东西,您希望它随处可见,并且理想情况下您希望它在世界范围内保持一致。同时,您可能拥有绝对不希望在全世界范围内复制的数据。您正在构建一个私人财富管理系统,您肯定希望将所有复制的数据保留在用户的合法管辖范围内。平衡这些事情,关注这些问题并让数据库从根本上支持它们是非常重要的,我们将讨论......我知道你打算问我关于 Cockroach 的其他一些甚至更新的功能,但我认为更大的这里的教训就是工作从未完成。

(12:00):

世界变化非常迅速。基础设施也必须改变,就像我们刚刚看到的那样,25 年来我一直在尝试解决数据库问题,你改进了数据库的最新技术水平,应用程序用例快速使用这些功能,然后你设计下一个版本的数据库,然后应用程序使用它并想要更多,它会一直持续下去,这是一场军备竞赛。

马特图尔克(12:26):

让我们开始讨论从 SQL 到 NoSQL 再到 NewSQL 的演变,以及 Cockroach 可能属于的类别。您似乎正在走向数据云的概念。云在哪里适合这个?然后是无服务器的下一步,但让我们谈谈数据云。

斯宾塞金博尔(12:51):

这些天您听到很多关于数据云的信息。我不确定它是什么。我对融合和数据基础架构的想法的一个观察是,构建一个用作操作数据库的基础架构非常非常困难。就像构建一个用作数据仓库或数据湖或某种分析系统的基础设施非常困难一样。我认为,为了成为最好的,你必须在你试图竞争的产品类别中有一个有点单一的线程焦点。否则你会成为所有行业的杰作而不是大师,我认为是人们所说的方式。所以我看到了一些产品的整合,但总的来说,每个产品类别的行业领导者将继续关注更窄的领域。

(13:41):

我之前提到过,云正在从根本上改变事物,并提供令人难以置信的机会以更快、更好、更便宜的方式再次做事。我们的认识是,云允许您几乎在任何地方以编程方式获取资源,甚至在几秒钟或几分钟内。这是对世界过去工作方式的根本改变,事实上,仍然拥有自己的数据中心的公司一直在为这个问题而苦苦挣扎,这可能需要几个月的时间才能获得新硬件或找到占地面积你的数据中心把它放进去你可以以此为基础。

(14:35):

我之前提到过,公有云有数据中心,多个数据中心位于单个区域和区域,遍布全球和各大洲。这也是一个根本性的大变化。而且公共云还有许多其他服务,您可以开始构建这些服务。因此,如果这里的每个人都知道 Snowflake,我的意思是,他们正在构建 S3 或谷歌云存储等云数据存储原语,这是一个巨大的好处。通过拥有使他们能够比必须在其产品中构建这些功能的早期系统更有效地做事的原语。所以我认为这就是事物的未来。您如何利用云并在生态系统中的其他人每次构建可能有用的东西时继续利用它?这是一个机会。

马特·图尔克 ( 15:27 ):

是的,所以一切都是无服务器的,我们谈到了分布式,你想谈谈无服务器吗?也许从定义开始,因为不是每个人都知道这意味着什么。

斯宾塞金博尔(15:39):

是的,无服务器在这一点上是一个超载的术语。它的介绍是……就像我说的,计算机科学中没有什么新鲜事我不知道第一次使用是什么,但我开始意识到的是 AWS 的 Lambda。正确的思考方式是它是一个无服务器执行层,因此您实际上可以在一个小片段中运行您的应用程序代码,一个基本上可以调用的函数,您不必运行一个永久拥有您的应用程序逻辑的服务器驻留在其上,随时可以查询。相反,会发生一个查询,它可能只是每周一个,可能是每秒一百个,可能是每秒 10,000 个,无论它是什么,无服务器的执行层,它在某处使用一些服务器容量来执行您的逻辑随需应变,它只对您使用的内容收费。

(16:35):

对于大多数人来说,这是对无服务器概念的最初介绍,而且是在执行层。但是每个执行层都必须处理数据,否则它不是一个非常有趣的应用程序用例。就像抵押贷款计算器一样,它不存储任何数据。你把小东西放进去,它就会吐出一些东西。这是一个非常简单的应用程序,但实际上每个应用程序都需要访问某个地方的数据库。

(16:56):

数据库在很大程度上被视为某个地方的常驻者,这是千真万确的。至少需要有一些东西来保存数据并使其可用。然而,无服务器的很多原则都适用于数据存储,特别是,你希望能够从很小的开始变得非常大,而不必担心你有多少节点,它们在哪里,节点有多大是,他们必须如何在操作系统等方面进行升级。换句话说,无服务器的想法使您摆脱了处理实际服务器以及与它们相关的所有事物的担忧。

(17:40):

此外,您真的希望能够为您使用的东西付费并随用随付,所以这是无服务器的另一个真正令人惊叹的功能,当然,它适用于数据库,或者至少它可以,这就是 Cockroach 带来的东西市场。所以这个想法就是,如果你想在开始时只存储一点点数据,例如,更少,那么如果你只有最小的节点可能运行你的数据库,你就有存储的能力。AWS 上可用的最小节点实际上仍然是一个潜在的更强大的数据库,其容量比您还没有任何用户的用例可能需要的容量大得多。假设你是一家初创公司,你正在努力使产品适应市场,你发布了你的第一个版本,但你还没有做太多广告或任何事情,上面只有朋友和家人。最好不要为永久运行数据库的常驻 VM 付费,但这是非无服务器版本。

(18:38):

对于无服务器,如果你只使用一点数据,这就是你要支付的全部费用,这是一种有趣的开始方式,但随后你就有了一种非常流畅的扩展方式,这样你就可以灵活地使用你需要的东西。当我们开始研究多区域的问题时,你有西欧的用户,美国的用户,也许东海岸和西海岸的用户是分开的,因为延迟很重要,你开始意识到服务所有这些客户,如果你有一个像我之前提到的游戏一样的用例,它还没有很多用户而且你真的不知道他们会出现在哪里,那么无服务器真的变得显而易见作为非常有用的东西。因为如果澳大利亚还不是你拥有用户的地方,那里只有 10 个用户,您不希望为位于澳大利亚且未使用的一堆资源付费。正确的?

(19:30):

借助无服务器,您可以拥有一个非常大的物理 Cockroach 集群,Cockroach Labs 将运行该集群,该集群在云中可用,并且所有客户都可以使用该物理基础设施,但只能使用一个分割物理基础设施的部分虚拟集群。因此,如果在澳大利亚只有一点点使用量,您就需要为一点点使用量付费。如果您的大部分使用都在北美,您可以根据需要扩展到那里。但同样,在整个全球足迹中,您只使用您需要的资源,并且您只需为您使用的资源付费。

马特·图尔克 ( 20:07 ):

你们什么时候推出无服务器产品的?

斯宾塞金博尔(20:09):

Serverless 是在 beta 中推出的,我不知道确切的月份,但现在已经一年多了。我们在今年 7 月发布了它的一般可用性版本。

马特图尔克(20:23):

所以你的主要客户之一,至少在公开场合是 Netflix。我认为用这个作为例子会很有趣。像 Netflix 这样的公司如何使用 Cockroach?

斯宾塞金博尔(20:36):

好吧,实际上这涉及到另一个有趣的点,我们有许多不同口味的 Cockroach,因为这实际上是我们公司发展过程中所必需的。我们开始时,Cockroach 是你自己运行的东西,我们称之为自托管,因为当我们开始时,这就是我们拥有的大多数大客户坚持要使用数据库的方式。这些是我们的运营数据库,这就是我们的想法,这就是……我们习惯于自己运行这些数据库。这是存储我们最有价值的皇冠上的珠宝,我们的运营用例的数据,如果你要使用新技术,我们将在我们的信息安全信封中与人员和流程一起运行它我们相信。所以我们有了那个自托管产品。

(21:25):

我们很快开始意识到新浪潮已经到来,而且即使对于那些现有的自托管客户来说,未来肯定也会使用作为托管服务的云产品。换句话说,AWS 向所有客户提供数据库的方式,因此我们开始构建该云产品。然后我们开始意识到无服务器将对此进行改进,因此我们开始构建无服务器产品。所以我们实际上至少有三大类我们的产品是如何提供给客户的。

(22:00):

你提到了 Netflix,Netflix 是这些自托管客户之一,这就是他们仍然希望运行数据库的方式,但他们正在朝着使用云的方向发展。所以一段时间内会出现混合现实,我认为,如果你放眼地平线,一切都会是云。我们确实支持一种非常灵活的部署 Cockroach 的方式。正如你们所想,Netflix 可能有数以千计的用例。我不确定有多少,我认为这可能是准确的,但他们提供了很多东西,其中一些东西很大,而另一些东西非常小,Cockroach 正在为他们解决许多不同的问题。

(22:38):

我认为最困难的问题,显然,规模是一个问题,而生存能力或业务连续性显然是另一个问题。所以这些是 Cockroach 的生计,但多区域也是一个主要问题,这也是 Cockroach 在市场上差异化的领域。我想他们最近在 YouTube 上做了一次演讲,所以这不是任何私人信息,但他们已经有数百个 Cockroach 集群,所以你可以看到在拥有大量需要这些功能的用例。

马特图尔克(23:15):

是的,基于自托管到云再到无服务器这一点,如果你今天要创办一家数据库公司,你会随着市场的发展而直接进入云吗?

斯宾塞·金博尔(23:27):

这真是个好问题。我想也许不会,但是我的上帝,如果你考虑过必须构建我们八年来构建的所有东西,我不知道我是否想创办这家公司。我说很难想象直接进入无服务器的原因,尽管出于我刚才提到的原因,这是您可以考虑这样做的唯一方法,但困难的原因是竞争激烈如果那是你跑步的唯一方式。如果你想至少在 2022 年赢得胜利,全球 2000 强就是客户,你真的必须拥有一种可以在各种不同配置下运行的产品,因为我认为,人们对采用只能在特定环境下工作的解决方案有理由犹豫单身时尚。

(24:18):

我并不是说这是不可能的,我同意你的看法,如果我们从今天开始,我们可能会直接转向无服务器,但我很高兴我们不必做出这样的选择,因为我们运行的事实是我们所做的许多不同的配置对高端市场极具吸引力,我认为,我还提到了规模弹性、多区域的差异化因素,这些对高端市场来说是非常重要的差异化因素。低端的情况更少,尽管你确实在未来五年、五到十年内将成为财富 500 强的新兴公司中看到它。他们中的许多人确实有这类用例,所以我们在这两个领域的公司分布很好,但世界上最大的公司是我们软件的主要候选者。

马特图尔克(25:13):

从一开始,我想您今天仍然是一家非常成功的开源公司,您认为世界也在发展吗?曾经有一段时间每个人都讨厌开源商业模式,然后转变为每个人都喜欢开源,而开源是唯一的方式。你认为它进化了吗?

斯宾塞金博尔(25:33):

是的,毫无疑问,它已经进化了。当我们开始时,我们采用了所谓的开放核心业务模型,所以这里的想法是您拥有一个真正广泛采用的开源产品。所以你得到了某种程度的无处不在。很多很多人都在使用它,因为嘿,它是开源的,下载起来非常非常容易使用。您不是预先为软件付费,您最终可能会为支持付费。这就是 Red Hat 的开源模式。但是开放核心模型的想法是,当你开始获得无处不在的采用时,开源产品将成为你所做的核心,你开始引入企业功能,这将是一个不同的许可证。

(26:30):

我认为,这种商业模式持续了大约四五年。当我们创办这家公司时,我认为这是一个很好的赌注,这是我们做这件事的正确方法,我们一直在这个赌注下运作,直到人们开始清楚地意识到开源商业模式受到威胁,特别是来自 AWS 的一些行动,所以他们真的追求 Elastic Search。我认为那是他们改变了开放核心业务模型的性质并使我认为您成功的可能性降低的原因。亚马逊所做的是他们说我们可以重新打包开放核心,将我们自己的企业东西放在它周围,并且我们已经为创建这个软件完成了大部分工作,我们将重新打包它。因此,除了现有的云平台,意味着我们将能够获得大量客户,因为所有东西都是集成的,它们都是同一个计费系统的一部分,所有身份访问管理一起工作。因此,您拥有云平台的所有优势以及开源产品的质量。因此,一旦人们开始与之搏斗,开放核心模型就变得不那么站得住脚了。

(27:57):

有趣的是,与此同时,真正将事物作为云服务提供的想法,首先也是最重要的,并且不太担心开源的想法也非常流行。再次因为亚马逊,我认为比任何公司都多。因此,他们既提供了一种商业模式的曙光,又真正开创了未来。而且我确实认为,如果你考虑这里的进展,你有闭源软件、开源软件,然后让我们说云服务,它们是有意义的,因为它们正在沿着成本更低的梯度发展。成本并不总是很容易用美元和美分来衡量,例如,它甚至可以用时间来衡量。实现价值的时间和在生产中运行某些东西所需的资源。你从闭源软件开始,实际购买和使用它的成本非常高,因为您实际上必须进行采购。所以你会和一些可能有相对较长流程的销售人员交谈,然后你必须经历法律纠纷,经历采购,最后他们会寄给你一堆印刷手册。并没有真正的在线社区,但这只是软件购买方式的主要模式。

(29:26):

你可以看到为什么颠覆的时机如此成熟。当开源出现时,很容易让社区快速试用软件来运行它。你实际上并没有预先支付软件费用,当然,你支付了硬件等费用。服务的想法实际上更进一步,不是因为这些想法是免费的,那是开源的一些好处,而是因为实际运行软件的过程不再是你必须学习如何做的事情。价值实现时间和第一天加上运营时间分别在两个维度上都减少了,对吧?

(30:05):

我认为我们看到的无服务器和我们的无服务器产品是免费的,因此它是永久免费的关系数据库集群,达到一定的利用率阈值。所以这就像我们认为在下一代基础设施价值主张中可用的是,你们都可以非常快速地获得软件,因为这只是一项服务,你们不必学习如何运行它。甚至还有一个免费层,从某种意义上说,它至少与开源一样免费,因为您总是需要为具有开源和支持的硬件付费。我认为同样的想法,你有云的转嫁成本,你也有支持。就像您正在前进一样,使用可用的基础设施成功实施用例所需的资源更少。这就像开源吞噬了软件世界,我认为云服务正在蚕食开源商业模式。这并不是说开源正在消失,我根本不相信那是真的。

马特图尔克(31:12):

所以你仍然会推荐开源作为大多数企业软件的战略?

斯宾塞金博尔(31:17):

这是一个很好的问题,因为人们一直在问我这个问题,他们在做初创公司,“我们应该开源还是不开源?” 我认为答案是,开源的其他核心优势对社区真的重要吗?因为有时它们是,我想说很难想象此时的关系数据库不是开源的,但情况可能就是这样。我确实认为你真的只需要看看什么是为客户提供价值的最佳方式,我认为这可以在没有开源代码的情况下很容易地完成。因此,开源的要求远不如我们创立 Cockroach 时那么强烈。

马特·图尔克 ( 32:02 ):

也许是我的最后一个问题或主题,因为那时我想公开提问。在进入市场方面吸取了哪些经验教训,特别是考虑到你们三位创始人都是超级技术人员,他们必须学习很多进入市场的知识,并且在从开源到开源的环境转变的背景下云和所有的东西。那你是怎么开始的?你是如何获得第一批客户的?什么起作用了?什么没有?然后,随着您向更多的销售组织发展,您是什么时候做的?你为什么要那么做?你是怎么做到的?

斯宾塞·金博尔(32:42):

这是个好问题。当我们开始 Cockroach Labs 时,我意识到我们可能是一家企业软件公司,这让我非常紧张,因为我以前从未真正处理过这个问题。例如,我在谷歌为谷歌工程师开发了软件,那是我更熟悉的心智模型,而且有可能有成百上千的客户需要支持的想法是我必须全神贯注的事情. 我会说,当你是首席技术布道者时,去与客户交谈是非常容易的,这是你应该尽早并经常做的事情,并试图找到那些设计合作伙伴。虽然很难推销,尤其是卖给更大的组织。

马特图尔克(33:58):

实际上,我们是否可以只双击该片段,因为这是一个经常出现的问题。你是年轻的创业公司,你是非常有技术含量的创始人,谁是你的第一个 AE?他们年轻,斜率高吗?他们有经验吗?他们是谁?

斯宾塞金博尔(34:13):

这是一个有趣的个人资料。您肯定不希望有人在规模较大的组织中工作过,并且真正了解如何管理销售人员、扩大团队规模、期望营销有一定数量的潜在客户、入站等等。在那些早期阶段,你需要一个真正擅长探索性销售活动的人,因为你不知道你可以为你的软件收取多少费用,但你肯定不知道什么消息会起作用,你的理想客户看起来是谁喜欢。你正试图弄清楚这些事情,所以你需要一个可以进入任何客户并真正倾听的人。

(34:52):

我的意思是,公平地说,这始终是您在销售活动中应该做的事情 我认为有些人真的很乐意在有人提到可能与您的产品有关的事情时竖起耳朵倾听,因为您只是还不知道那个动作到底是什么样子,你必须弄清楚它可能有很多东西。因此,有一位专门从事此工作的早期销售主管,但一旦该人开始弄清楚该动作是什么样子,您可能就需要更换他们,因为能够弄清楚的人通常不是可以指导其他销售人员并开始扩大组织规模并将该运动真正编纂成可以通过对更大的销售组织的支持来教授的东西的人。

马特·图尔克 ( 35:42 ):

然后快进到今天,您有更多自上而下的销售主导运动,或者您是否仍然从社区和一些自下而上的入站中获得果汁?它在规模上看起来像什么?

斯宾塞金博尔(36:00):

是的,它是许多不同事物的组合。我们肯定仍然得到开源提升,这很有趣。我们通过我们的无服务器平台越来越多地以产品为主导的增长运动来实现它,我们正在将一些原则和以产品为主导的增长扩展到高端市场,例如,产品体验如何,比方说一家真正的财富 10 大银行正在战略性地押注您的产品,并且正在银行内部推出。您希望该组织中的所有个人团队都能体验到以产品为主导的增长运动的好处。因此,如果一切都是自上而下和以销售为主导,那么这些原则就适用,很难扩展或扩展成本非常高,因此您确实想要平衡那些。但这取决于您的用例使用 CockroachDB 以及可能任何可操作的数据库,这是一种解决方案销售,

(37:01):

克服所有障碍和所有技术评估,甚至合同和其他事情可能非常困难,因为这是堆栈中非常重要的部分。如果它下降,一切都会下降,因此合同会变得更加令人担忧。所以你确实需要有合适的销售组织来完成销售。我只想说,在进入市场的过程中,这可能是我所获得的最违反直觉的学习,它应该会给处于这个旅程中的人们一些乐观的观点,但你会认为当某些事情发生时您的操作数据库确实出了问题,客户根本不会满意。事实上,他们可能会对你产生不满,因为你在一件非常关键的事情上让他们失望了,而Cockroach不应该倒下。

(38:01):

乍一看,您的运营数据库出现故障意味着您将流失客户。事实上,这不是真的。如果客户从来没有对您的软件有任何问题,您实际上更有可能流失客户,因为他们看着它,“我们为什么不只使用它的开源版本,这没有什么问题,我们不需要支持。我们付这么多钱是为了什么?这是一个非常昂贵的订单项。” 我们发现,当我们不鼓励事情以任何方式下降时,不,我们将每个客户的问题视为我们的失败并日以继夜地工作以解决它们。

(38:36):

但是,当您确实遇到问题时,正确的看待方式是这是一个机会。这是与客户建立实质性信任的机会。如果他们看到你在他们的问题所在的层面上与他们合作……你最关心的问题就是他们最关心的问题,那么这实际上会让你建立一个非常长期的信任关系,同时也是一个巨大的扩展机会,因为你是现在被视为他们可以长期依赖的合作伙伴。他们说所有这些危机都是机遇,我认为至少在基础设施方面,这是我过去八年来一直关注的问题,这是绝对正确的。并不是说你从不欢迎失败,而是你想把所有的精力都用来解决它。

马特图尔克( 39:26 ):

这是一个非常有趣的见解。我的最后一个问题是因为我认为它非常有趣并且与很多人在建立公司方面试图做的事情相关。为了在那种情况下支持客户,你做了什么,你做了什么?你带你的工程师并分配他们,或者你有一个技术性很强的客户成功团队?谁做这件事,它是如何工作的,他们在组织中向谁报告?

斯宾塞金博尔(39:54):

好吧,显然,所有这一切都在发展,就像我提到的,探索性的销售领导者,然后发展成为可以扩展组织并运行支持的人。故事的客户成功方面也在不断发展。一开始,实际上是数据库工程师,至少在我们的例子中,他们正在处理这些事情。因为我们没有客户成功团队。但是,哇,这是非常有趣的客户成功。我的意思是,当然,如果 Oracle 出现问题,您不会让首席 Oracle 数据库工程师夜以继日地处理您的问题。如果你这样做了,它可能会得到更明确的修复。这是你实际上可以带入早期销售对话的东西,嗯,“作为客户,你对我们来说非常重要。你是伙伴,您将影响我们的路线图,我们比任何其他供应商都更关心您的问题。” 你实际上可以卖掉它。

(40:43):

所以早期确实是,包括我在内,每个人都会在这些问题上,并会努力解决它们。但是当你雇佣你的第一个客户成功时,你的第一个……实际上我们首先雇佣的是技术支持,然后是客户成功,就升级而言,你必须小心,因为你做的越来越大。我认为,您希望继续让您的工程师在需要升级时比任何人都更了解产品。您还想创建一堵墙,这样他们就不会分心到无法按照路线图完成工作的地步,这也非常重要。所以那里有一个平衡,最终你要做的是越来越多地将解决方案推入知识库和产品本身。

(41:33):

特别是在可观察性方面,您希望看到有您开始认识到的错误类别或客户首先遇到的问题,您可以让您的技术支持和客户成功人员在您需要工程师做之前做些什么,因为现在他们在内部拥有工具,他们实际上可以比以前更清楚地看到一些东西。因为你实际上是在说,“你知道吗?如果我们将这个新东西构建到仪表板中,我们就可以非常透明地解决这一类问题。” 那太好了。

(42:03):

最终你想推动这一点,以便客户可以轻松诊断他们的问题,并有办法解决他们理解的问题。最终你想要做到这一点,这样你就可以消除一类问题,也许你正试图在某种程度上同时解决所有这些问题,但你会在那个循环中变得越来越好。它是任何产品开发周期中真正主要的投入之一。这不仅仅是新功能,而是如何让产品变得越来越坚固和可观察。

马特图尔克(42:33):

极好的。太好了,谢谢分享。好的,有问题吗?一个在这里。

演讲者 3(42:41):

我刚刚看到谷歌介绍了他们称之为 Web 0.3 的区块链节点引擎,就像一个数据库,可以用于 Web3 的大型应用程序使用我只是想知道这是否是你正在寻找的市场,因为它确实可以扩展?

斯宾塞金博尔(42:59):

这是一个有趣的问题,自从我要说的区块链问世以来我们就一直在问这个问题。现在,答案是否定的。我认为 Cockroach 绝对可以在 Web3 上下文中使用,而且我们实际上有许多公司正在尝试构建 Web3 类型的解决方案,这应该是完全去中心化的。但是正在建设的公司通常需要为客户提供自己的元数据,这就是使用 Cockroach 的地方。

(43:29):

随着关系型操作数据库的发展,Cockroach 相当分散。所以你实际上有能力,即使在你试图为你的更大的分散系统创建集中元数据的情况下,你可能仍然想要,例如,地理分区,这样你就可以真正保持数据接近客户和他们的法律管辖范围内等等。但我想说也许……我正在努力想出正确的表达方式。Web3 承诺的弱点就是通常情况下,即使对于这些去中心化的用例,您也需要一些中心化。我认为这才是 Cockroach 目前关注的重点,而不是试图将东西存储在区块链上。它们的使用方式略有不同。

马特图尔克(44:20):

别客气。好吧,还有一个问题。

演讲者 4(44:23):

你好?斯宾塞,谢谢你今天的演讲。所以Vendor lock in是企业在销售周期中尽量避免的事情之一。你怎么看待它,并与前景谈论它?而且,一旦您有了客户,您如何与他们谈论不要被锁定?同时你想锁定?那么,您如何在销售周期中以及在保留方面平衡两者呢?

斯宾塞金博尔(44:51):

是的,这是一个非常好的问题。它有很多方面。一是,好吧,我们是开源的,因此您不必继续使用我们的服务,甚至不必继续使用我们的支持。有一个出口,与此同时,当然,我们确实有一些企业功能,这可能就是您如何实际保持对您的业务有用的某种程度的锁定的答案。你必须不断创新,对吗?您确实需要保留一些您的价值主张。这只有在他们仍然是客户时才可用。所以有不同的方法可以做到这一点。

(45:30):

我们也,Cockroach 看起来像 Postgres,当然,Postgres 是一个被广泛采用的数据库,许多不是 Postgres 的数据库看起来像 Postgres。我们不是唯一的。我的意思是,谷歌拥有它们,还有其他初创公司,所以这是另一个答案。我认为最大的答案是,尤其是当你与大公司交谈时,他们并不担心 Cockroach Labs 的供应商锁定。我的意思是也许温和。

(45:57):

他们担心的是超大规模云供应商的供应商锁定。他们非常担心,减轻他们担忧的正确方法与其说是说服他们他们不会被锁定在您的系统中,不如说是说服他们如果他们使用您的系统,他们就不会去被锁定到任何特定的云供应商,即使他们有机会从云供应商遣返并运行他们自己的数据中心,如果他们变得足够大,这实际上在经济上变得有利,我们有许多这样的客户。所以这就像是房间里的大象,你想谈论它而不是你自己的供应商锁定,我认为你会得到更多的好处。

马特图尔克(46:35):

好吧,最后一个问题。

演讲者 5(46:38):

谢谢。我只有两个问题。谈谈……哦,抱歉。您能谈谈 MySQL 体系结构中的什么实际上限制了它的扩展能力吗?我只是想听听你对此的看法。是不是像图表一样没有得到原生支持,或者其他不允许你们在谷歌扩展的东西?

斯宾塞金博尔(47:05):

是的,所以 MySQL 是所谓的单体架构的一个例子。所以它实际上是在解决单个集成机器中可用的资源。所以你可以扩大这些机器的规模。是128核吗?我不知道今天 Oracle 和 Db2 的极限是什么,您实际上可能在远远超过云供应商中最大商品机架硬件容量的硬件上运行。你使用的是 IBM 大型机,而你使用的是 Cray 超级计算机或类似的东西,即使它们具有超级线性成本曲线,并且它们对它们可以达到的大小有明确的上限。

(47:49):

当您使用单体架构时,如果您开始分发,那么您实际上只能将一台机器或一组非常紧密耦合的机器扩展到多大。我认为,最好将 MySQL 描述为没有像 Oracle 或 Db2 那样真正关注扩展问题。当我们在 Google 构建 AdWords 时,那是在 2002 年,我猜是 2003 年,那时我们正在做那件事,我认为 MySQL 的内部架构没有太大变化。

(48:25):

Google 通过在数据库外绘制图表来解决 MySQL 的这个问题。当时谷歌意识到这是一个令人担忧的架构。如果你不解决数据库内部的规模问题,你就会失去数据库的保证,你会在应用程序级别和操作级别花费大量时间来管理许多独立的 MySQL 分片,而没有像交易。举个例子,在 AdWords 中,他们有 eBay 作为客户,而 eBay 不适合单个分片,所以你遇到了另一个奇怪的问题,而不仅仅是如何将大量客户放在一个分片上并且你有许多分片,但您实际上拥有如此大的客户,以至于它们甚至无法放入一个分片中,因此您将客户分散在分片之间。因此,您可以看到不在数据库级别解决该问题的复杂性,实际上会导致软件工程和 SRE 以及运行您自己开发的系统的巨大成本,然后您继续运行。谷歌没有用 Spanner 替换那个系统我想已经将近 10 年了,到那时它已经拥有了 1000 多个 MySQL 分片。

(49:37):

相比之下,只是为了让您知道我不是……我实际上是 MySQL 的超级粉丝,它本身就是一个了不起的系统。Facebook 现在拥有数十万甚至数百万个 MySQL 分片,他们已经使用 MySQL 作为每个节点的组成部分并实施了一个元数据库,并将所有这些混合在一起成为真正庞大的系统,这些系统具有某些对 Facebook 使用有意义的属性案子。Facebook 如此之大,Cockroach 从未被证明可以在那种规模下工作。我的意思是,它实际上是数百万个节点。所以这是一个有趣的问题,他们有一个专门为它构建的解决方案。所以 MySQL 仍然非常有用,但我想说,如果你不是为 30 亿活跃用户提供服务的 Facebook,那么 Cockroach 的亮点在于,我认为这是一家更常见的公司。世界上只有一个。

马特图尔克( 50:42 ):

好吧,就此而言,这是今天的总结。非常感谢您从技术角度、市场角度、市场角度分享所有这些,非常棒。我希望你很快回来第五次,我认为你现在需要跑步。除非情况有所改变,否则我认为你需要去吃晚饭。非常感谢您的宝贵时间,非常感谢。

斯宾塞金博尔(51:06):

这是我的荣幸,马特。谢谢你。


文章来源:https://mattturck.com/kimball/




最后修改时间:2022-11-22 16:20:45
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论