Replay - Multi-Cloud is the Future with Tobi Knaup
31:02 Share

在这种情况下，当我们说多云时，他们想到的往往并非三大云提供商之一。欢迎收听《云端尖叫》。我是科里·奎因。本周和我一起的是托比·诺普，他是 D2iQ 的联合创始人兼首席技术官，你可能没听说过这家公司，它以前叫 Mesosphere，你肯定听说过。托比，欢迎来到节目。感谢你的邀请。本期节目由我的日常工作赞助，

鸭嘴兽集团。你的 AWS 账单是不是吓人？这可能意味着很多事情。预测它会是多少，确定它应该是多少，与 AWS 协商你的下一个长期合同，或者只是弄清楚为什么它越来越像一个电话号码，但似乎没有人知道原因。要了解更多信息，请访问 duckbillgroup.com。

记住，你躲不开鸭嘴兽账单。我的首席执行官告诉我，这绝对不是我们的口号。当然。那么，让我们从至少在我脑海中，如果不是其他许多人脑海中的一个紧迫问题开始吧。Mesosphere 是一家在基础设施领域至少每个人都对其有所了解的公司。去年，我想是去年，时间过得真快，该公司进行了品牌重塑。这背后是什么原因？

是的。这背后的原因是，事后看来，说实话，把技术名称放到公司名称里并不是一个好主意。

因为，你知道，技术会随着时间的推移而改变。我们显然是在 2013 年围绕 Apache Mesos 成立了 Mesosphere 公司。那是我们使用的核心开源项目，我的联合创始人和我曾在 Airbnb 和 Twitter 使用过它。我们想围绕它成立一家公司，帮助每个企业采用 Mesosphere。

Apache Mesos，但很快我们实际上开始帮助人们使用来自云原生生态系统的其他技术。我们帮助人们自动化 Kafka、Cassandra 和 Spark 等任务，并在其上构建这些数据管道，并且很快也参与了 Kubernetes。实际上是在它发布的第一年。

因此，随着时间的推移，Mesosphere 作为公司名称成为我们的绊脚石，因为我们总是不得不解释，是的，我们是 Mesos 公司，但我们也做其他事情，对吧？我们帮助你构建数据管道，我们也帮助你使用 Kubernetes。因此，它成了一种负担，我们决定把特定技术放在公司名称里可能不是一个好主意。所以我们

我们决定重塑品牌，我们想选择一个名称来表达我们真正的工作，我们帮助客户做的事情。也就是说，我们帮助他们在第二天取得成功。我们帮助他们在第二天取得成功，并在第二天的运营中变得聪明。从 DevOps 概念的第二天来看，也就是生产系统的持续运营和维护。

这就是背后的原因。你本可以走我走过的路，我从一份新闻通讯《上周的 AWS》开始，这是一家与之无关的咨询公司。还有这个播客《云端尖叫》，有三个品牌而不是一个，这意味着每当有人问我，你做什么？我的回答总是，嗯，

你能更具体地说明一下这个问题吗？它最终有效地将我们引向这条奇怪的品牌化道路。然后，当然，我还开始了另一个播客，名字完全不同，叫做《AWS 早间简报》。在这一点上，我只是听起来像是在专业上感到困惑。

命名很难，特别是当你有一个在某些方面不再准确的名称时，但这是人们对其有明确好感的东西。你拥有品牌认知度。我的意思是，我们之前邀请过 Palantir.net 的一位嘉宾，它比恐怖谷的 Palantir 早了大约 10 年。看起来他们的标语已经变成了，我们是 Palantir，不，不是那个。是的。

那太好了。是的，你知道，就像你说的，命名很难，公司改名也很难。多年来，我们积累了很多品牌资产。因此，对我们来说重要的是，我们不要放弃这一点。因此，Mesosphere 这个名称实际上仍然存在。它现在是我们围绕 Mesos 的产品系列的名称。

所以名称仍然存在。只是公司名称不同。那么，你是否发现，再次，显然从你开始 Mesosphere 的时候起，那是什么时候？

- 2013 年，所以我们快 7 岁了。- 好的，很久以前了，互联网时间。- 没错。- 在基础设施领域，出现了一些，让我们说，动荡。那时，坦白地说，我会把农场押在 Mace House 上。这似乎是正确的答案。许多大型商店都在这样做。而今天，每当你向人们建议这样做时，他们都会奇怪地看着你，说：“是的，如果我们正在做任何新的事情，”“它可能会建立在 Kubernetes 之上，”我对它有一长串抱怨。但我很好奇你的看法。

你如何通过你为客户所做的事情来观察 Mesos 的兴衰？好的。所以，你知道，我认为我们对 Kubernetes 的看法实际上是社区的力量。当我与人们交谈并询问他们时，你知道，为什么是 Kubernetes？

这是人们最常提到的。从最广泛的意义上来说，它是社区，这意味着我可以在网上找到一个地方来学习 Kubernetes 和相关技术。我可以从中招聘人才。人们希望在他们的简历上拥有它。显然，这个社区比任何单一供应商所能拥有的都要大得多。因此，这就是许多创新发生的地方，创新在这个社区中发生的要快得多。所以这就是……

最常见的原因。Mesos 最初是

大型计算集群的抽象层。虽然我们现在在 Kubernetes 上做了很多工作，并且我们有一整套围绕它的产品线，但我们仍然拥有我们的 Mesos 产品线，它仍然是这些大规模部署的首选平台。因此，我们的客户在生产环境中拥有数十万个节点，他们正在运行 Mesos，并且他们将在一段时间内运行 Mesos。

所以这真的是一个最适合工作的工具的情况，对吧？如果你

是一个小型商店，你正在开始使用云原生，你可能有 10、20、30 个节点的集群。20、30 个节点是我们看到的行业中大多数集群的数量。Mesos 可能不是正确的选择，因为它是为了规模而构建的。所以我们说，嘿，让我们为客户提供他们想要的东西。让我们给他们 Kubernetes。开发人员想要这个。我们仍然保留 Mesos 平台用于这些大规模部署。

你在 2020 年看到围绕 Mesos 的新活动吗？我们确实看到了。所以我们构建的一件事，多年来我们投入了大量时间，那就是帮助客户自动化数据服务，对吧？使用 Kafka、Spark 等技术构建端到端数据管道。他们在 Mesos 上获得的体验在 Kubernetes 之上还不存在。

我们正在努力实现这一点。显然，围绕构建 Kubernetes 运算符有很多活动。构建运算符有各种不同的方法。大约一年半前，我们启动了一个名为 Kudo 的开源项目，旨在使构建运算符变得非常容易。它基于我们在 Mesos 之上的经验教训。

所以，你知道，生态系统将会到达那里，但它还没有到达那里。因此，我们实际上看到很多人仍然在 Mesos 之上启动围绕这些数据基础设施项目的项目。你提到发布围绕基础设施世界中任何事物的开源产品很有趣。我的意思是，最近，围绕

围绕开源作为商业模式的危险，似乎出现了一种相当持续的叙述，因为像 AWS 这样的公司会进入并有效地将你所做的事情作为托管服务推出。这是否是你目前威胁雷达上的东西？你是否认为这不太可信，或者我完全错过了什么？

所以它绝对在我们雷达上，而且……我认为，虽然这是一个每个人都面临的威胁……但也存在机会为不同的……不同的用例、不同的客户群体构建差异化产品，所以我们现在看到很多情况是人们想要运行

任何混合或多云场景的组合，对吧？所以他们想要像从 AWS 获得的那样的公共云体验，但他们想要在他们选择的架构上获得它。

因此，我们看到了很多活动，我们与许多拥有工业物联网用例的客户合作，对吧？所以假设他们有一个制造工厂，一个拥有数千或数万个传感器的工厂，这些传感器实时产生数据，他们需要处理这些数据并进行预测性维护等操作，查找传感器数据中的异常值等等。

这些工厂通常位于与云连接质量不高的地方。因此，将所有这些数据实时发送到公共云是不可行的。你必须在本地处理它。因此，本质上，这些客户需要的是一个小型边缘云，对吧？他们显然不会在他们的每个制造工厂中都拥有高技能的云原生工程师。而其中一些人拥有超过一百个这样的工厂。

所以他们真正需要的是一种公共云式体验，他们可以将其部署在边缘。现在，他们还想在公共云上运行大量基础设施，他们还想在他们现有的数据中心上运行大量基础设施。那么你该如何做到这一点呢？你如何以一致的方式操作，例如选择 Kafka 或 Spark 作为示例，跨所有这些平台？

这就是我们关注的一点，也是我们与众不同的地方，是的，你可以去 AWS，你可以获得托管 Kafka，但你不能在制造工厂或没有互联网连接的隔离案例中获得它。所以仍然有很多这样的用例存在，这就是我们与众不同的方式，或者是一种与众不同的方式。

我一直说，你可以想出的关于运行 Kubernetes 的最有效的攻击性广告是，将正在考虑使用它的人发送到为期三天的 Kubernetes 研讨会。当他们回来时，他们将明白这里有巨龙。就与在 Kubernetes 生态系统中进行大规模操作的任何人交谈而言，这种情况一直持续存在，那就是构建在抽象之上的抽象的绝对抽象级别……

从根本上变成了难以理解引擎盖下发生了什么事情的东西。所以这不是第一天体验，第二天体验，正如你在录音中前面提到的那样。

一旦你运行了某些东西，然后你看到性能下降或间歇性故障，就会变得非常难以弄清楚是什么原因导致了这个问题以及原因。这是绝对正确的。我们看到很多人经历的典型旅程是这样的，他们决定使用云原生，他们决定使用容器，或者他们的老板告诉他们这样做，他们

他们上网，他们去 Stack Overflow 或其他地方，他们找到了 Kubernetes。他们尝试一下，你知道，他们将其下载到他们的笔记本电脑上并获得良好的体验，对吧？第一次接触 Kubernetes 的体验非常好。你可以快速启动和运行一个容器，或者快速启动和运行你的访客簿示例。因此，太多人认为将其投入生产将是类似的体验。

我们看到的第一个常见错误是，人们认为 Kubernetes 是他们所需要的一切，Kubernetes 为他们提供了将容器堆栈投入企业生产所需的所有工具。事实并非如此，对吧？你需要来自 Kubernetes 周围云原生生态系统的许多其他工具。你需要一个监控堆栈，你需要日志记录，你需要网络、负载平衡，所有这些东西。而且

因为人们采取了一种相当敏捷的方法，他们尝试一下，然后当他们遇到障碍时，他们就会想办法解决。假设我启动一个无状态容器，这是一个很好的体验。现在，我需要向其中添加状态。我该如何做到这一点？我如何获得卷？他们一步一步地进行，这就是我们看到许多云原生项目失败的原因，因为就像你说的那样，在某些时候他们会面临复杂性，他们会说，“哦，哇。”

实际上还有很多我没有考虑过的事情。我们想在那里做的是确保人们了解这一点，对吧？所以我们会说，嘿，当你需要投入生产时，这些都是你应该注意的事情。确保你有适当的监控，确保你有适当的日志记录，

你需要一个网络层等等。这也是我们在 Kubernetes 培训中教授的内容的一部分。因此，我们在世界各地的不同城市进行这些免费的现场培训，只是为了突出这些问题，因为就像你说的那样，很多人根本没有意识到这些问题。

在鸭嘴兽集团，我们日常工作中做的一件事是，我们帮助协商 AWS 合同。我们最近刚刚超过了 50 亿美元的已协商合同价值。

它解决了有趣的问题，例如，你怎么知道你与 AWS 签订的合同是你能获得的最佳交易？你怎么知道你没有浪费钱？你怎么知道你没有像我在这个播客和 Twitter 上不断做的那样，把脚放在嘴里？要了解更多信息，请访问 duckbillgroup.com 聊天。或者，当我们谈论它时，我也会进行播客配音。

同样，这是 duckbillgroup.com。我认为，历史上支持 Kubernetes 的论点之一是混合故事，对此我表示同情，以及多云故事，对此我略微不那么同情，因为它在纸面上看起来很棒。实际上，这意味着你不仅要处理一个云提供商的缺陷，还要处理所有云提供商的缺陷。

这已经成为本节目一段时间以来反复讨论的话题。你对多云作为最佳实践的想法持什么立场？是的，这是我最喜欢的主题之一。我认为多云是所有事物都将迁移到的方向。对我来说，多云也包括混合云，因为每个大型企业都拥有混合云。

他们出于各种原因想要保留在本地的大量工作负载，无论是他们想要保护他们的数据还是其他原因。而且在一定规模上，实际上运行你自己的设备也会更具成本效益。所以我认为最终每个企业都将达到这种状态。

现在，他们想要使用多云的原因各不相同。我认为很多人在听到多云时，首先想到的是，哦，你知道，我将拥有这个抽象层，Kubernetes 或其他任何东西，我将动态地移动我的工作负载，我将查看成本最优的地方，

你知道，我将针对其他方面进行优化。这通常不是人们这样做的主要原因。虽然我们正在与一些相当复杂的客户合作，他们实际上正在这样做。他们正在观察所有不同云提供商的现货实例价格市场，然后，你知道，每小时决定事情应该去哪里。但这只是一小部分人，他们，你知道，领先于潮流。他们是相当复杂的客户。对于大多数人来说，原因是，你知道，

不同。我们与许多在全球各地、在许多不同国家和司法管辖区工作的公司合作。因此，他们需要查看围绕此的数据隐私法律法规。因此，当他们在中国建立的基础设施，他们为中国客户在那里处理的数据通常不能离开该国。因此，他们需要在中国的云提供商上运行。

他们可能在欧洲运营，因此他们需要在欧洲的基础设施上运行，并在欧洲的每个国家/地区运行。因此，在这种情况下，当我们说多云时，他们想到的往往并非三大云提供商之一。这可能是在特定国家/地区需要在其之上运行的相当小的基础设施即服务提供商。因此，在这种情况下，多云非常有意义，因为

你想一次构建你的堆栈，你想将其构建在像 Kubernetes 这样的抽象层之上，然后能够出于这些原因在不同国家的不同 IaaS 上建立它。

这是我们看到的常见情况。显然，这是与在许多不同司法管辖区全球运作的公司一起的。我们看到的另一个多云原因通常是他们想要挑选他们喜欢的特定云提供商服务，对吧？他们可能想要去提供商 A 获取他们的机器学习堆栈，并且

他们想转向提供商 B，因为他们拥有更好的托管数据库。所以我认为更多的是这些原因，而不是大多数人立即想到的原因，即动态地移动工作负载。

这些工作负载的动态移动似乎是人们提出的，哦，能够随时随地神奇地部署我们的整个应用程序将是多么棒的事情。是的，除了数据重力总是使这成为一个挑战。这是正确的。尝试获得甚至那个基线……

在两个提供商之间工作的基本一致体验，即使其中一个是本地的，并且你几乎可以控制它的各个方面，也不是微不足道的。我一直以来都喜欢的一个论点是，很好，拿你的提供商，你的主要云提供商，无论它是什么，我不在乎，你可能在乎，我不在乎，然后尝试多区域。能够跨越同一提供商的多个区域并查看哪些内容会中断。这是一个好主意

当你开始使用多云时，你将不得不开始考虑的事情的基线故事，现在有一些工作负载证明了这种工作、经验和压力的水平，但这当然不值得很多公司的时间和精力去做，是的，你完全正确，这种体验与你在多云中将要做的非常相似，还有一个用例我前面忘记提到了，那就是

某些行业的受监管人员实际上必须与多个供应商合作。出于监管原因，他们必须选择两个或多个云提供商。因此，他们被迫这样做。你将不得不构建你自己的主要事情之一，或者这实际上是我们帮助客户做的事情，就是复制你的数据。就像你说的那样，数据有重力。因此，我们看到在多云或多区域方面取得成功的人，

他们会做一些事情，例如使用 Kafka 来异步复制他们的数据，或者使用 Cassandra 在不同的基础设施之间异步复制数据。这不是云提供商提供的服务，但我们帮助人们管理 Cassandra、管理 Kafka，因此这会使事情变得更容易一些。所以告诉我一些关于你从哪里来的信息。大多数人不会决定以基础设施领域公司的联合创始人的形式，从某个古代神灵的额头完全形成，每个人都听说过。

在 Mesosphere 之前你在哪里，如果可以说在 Mesospheric 时代之前有一个时间的话？在 Mesospheric 时代之前绝对有一个时间，是的。

我对互联网、基础设施和 HA 的接触始于十几岁。所以我的联合创始人 Flo Liebert 和我，我们在德国同一个城镇长大。当我们十几岁的时候，我们开始建立网站，我们开始建立一些冒险游戏等等。所以我们知道如何建立网站。我们在一个相当小的城镇长大，有 5 万人，那是 90 年代后期。而且

即使在那个地区，公司也开始听说互联网。所以他们基本上想知道这是什么东西。有人告诉他们，“嘿，你需要上网。你需要有一个网站，并且作为一家企业，你需要有一个电子邮件地址。”

但他们不知道该如何思考这个问题以及如何处理它。当时，获得网站非常困难，因为你基本上必须与三家不同的公司合作。你必须找到有人为你设计它。你必须找到有人来编程它，然后有人来托管它。这些通常是三家不同的公司。所以 Flo 和我所做的是，我们说，嘿，你知道，我们知道如何建立网站，我们知道如何运行 Linux 服务器。我们只是，你知道，在旁边做了一些尝试。所以……

我们实际上说服了我妈妈注册了一家公司，这样我们就可以为人们编写网站并托管它们。那是我们第一次接触基础设施。即使在那时，我们也做了 HA 的事情。我们买了两个服务器，而不是一个。一个足以托管我们所有的客户，但我们希望它具有高可用性。所以我们获得了一些这方面的经验，运行 Linux 服务器，运行生产基础设施。

然后，你知道，当你长大在德国或硅谷以外的任何地方并且你在科技行业工作时，你会听到这些故事，对吧？你会听到关于硅谷的故事。我一直认为它是一个超级未来主义的地方。我想在某个时候去看看。所以在大学里，我在 Redwood City 的一家初创公司找到了一份实习。

并加入他们三个月，帮助他们使用当时的 PHP 和 Ruby on Rails 构建他们的网站。那是我第一次接触硅谷。我只是喜欢这种活力、充满想法的人以及事物构建的速度。所以大学毕业后，我加入了那家我实习的公司，全职工作，在那里构建基础设施，构建网站。

然后我的下一份工作是 Airbnb。我很早就作为工程师 4 加入他们，所以在那里做了很多不同的工作。我在那里做的一件事也是设计和构建他们大规模增长的基础设施。聘请工程团队，在那里也做了一些机器学习工作。除了基础设施之外，这是我的另一个热情。

在 Airbnb，那时我们开始使用 Apache Mesos。我们在那里基于 Apache Mesos 构建了数据基础设施，我的第三位创始人 Ben 当时在伯克利工作。我应该提到 Ben、Flo 和我，三位创始人，我们认识很久了。Flo 和我一起长大，Flo 做了学生交流，高中也住在 Ben 家里。

我们都喜欢电脑。我们谈到了 Mesos，这就是 Twitter 和 Airbnb 最终使用 Mesos 的原因。对我们这些在那里运行基础设施和拥有寻呼机的人来说，寻呼机有时会在凌晨三点响起，Mesos 真的感觉像是魔法。这是一个 10 倍更好的解决方案，因为我们可以自动化更多的事情，并且寻呼机在半夜不会经常响起。

所以那时我们决定，嘿，这是一个开始公司的好机会，因为我们在那里用自动化解决的问题，对 Twitter、Airbnb 或任何硅谷科技公司来说都不是独一无二的。

每个公司在某个时候都将面临的基础设施挑战。这大约是在马克·安德森撰写“软件正在吞噬世界”这一理念的时候，我认为是在 2009 年。

那还是相当新的。但我们看到每个公司，无论是银行、保险公司还是汽车制造商，最终都必须运行大规模云基础设施。事实上，为了在未来保持竞争力，他们将不得不使用世界上最好的软件公司正在使用的一些相同技术。

所以这就是我们看到机会的地方。我们看到我们拥有这个自动化更多事情的工具，使基础设施更加强大和

可扩展且经济高效。当时的唯一挑战是，你知道，这是一个开源项目。世界上只有少数人知道如何使用它。所以我们决定，让我们围绕它组建一家公司。让我们围绕开源核心构建一个企业产品。这就是 Mesosphere 在 2013 年成立的方式。我依稀记得在我版本的计算时代之初，

我们会配置我工作的办公室的核心交换机。然后我们租了一辆货车，我们技术运营团队中的一些人把它开到大约 30 英里外的的数据中心，并进行了安装。我们学到了一些东西。首先，我们是超级糟糕的搬运工。其次，它……

公司决定不为这项工作支付专业有保险的担保搬运工，这有点令人不安。第三，将一件适合机架的计算机设备装入货车后部，你们中的两三个人可以把它抬起来，而这辆货车的成本低于交换机的成本，这是一种非常超现实的体验。

这仍然是一次如此奇怪和超现实的体验。你不会在云的世界中以同样的方式体验到这一点，但它通过它为我们展现的其他滑稽和讽刺性地令人不安的事情来弥补这一点。是的，绝对的。你知道……

我认为……我认为与真实的硬件和真实的数据中心互动，这是一种真正、真正塑造了我思考方式的体验。一个重要的方法是总是期望失败，对吧？因为我可以讲述很多有趣的故事，部分有趣，部分痛苦，关于数据中心、物理世界中出错的事情。

我认为这教会我的就是永远要预料到失败。任何事情都可能在任何时候失败。当你构建软件时，即使你是在一堆云计算层之上构建的，你也必须预料到这一点。即使在云中，机器也会发生故障，你会收到 AWS 的邮件说：“这个实例现在坏了。”

我认为，如果你没有这种经验，没有亲手安装和配置硬件，没有看到大量的物理故障，你可能不会以同样的方式思考这个问题。所以我不想错过这种经验。但是，就像你说的那样，云中还会发生各种各样的奇怪行为。它只是被一堆层抽象掉了。

我也经历过一些有趣的云中断，数据包绕圈传输，然后，你知道的，这导致 EBS 疯狂运行，以及各种有趣的事情。哦，级联和依赖关系总是故事，是事后才出现的传奇故事。事后看来，这是有道理的。每一次失败在某种程度上都是如此。但当你身处其中时，你会怀疑自己是不是疯了，旧规则是否不再适用，这种行为完全无法解释，发生了什么等等。

我想，弄清楚这一点并经历几次，我认为这是学习以更系统的方式处理这些问题的最佳方法。但是，哎呀，早期的一些失败并不愉快。看到这些方面在云环境中表现出来，绝对让我想起旧事物又重新出现。这是真的。我们也不应该忘记的一件事是，通过使用……

这些云服务，你也给了他们很多控制权，对吧？因为当事情确实失败时，你只能做这么多事情，对吧？API 可能会突然变成只读的，你无法

突然从备份中恢复你的数据库，或者你无法突然将你的只读数据库提升为主实例。所以肯定也有这方面的原因，当我们运行旧设备时，这要容易得多。你完全掌控，对吧？你控制一切。如果你想做一些疯狂的事情来尝试解决问题，你可以这样做。

在云上做不到。所以最后一个问题，我想在我们结束之前，我在大约一年前做了一个预测。我说现在五年。所以我们还有四年时间。

我当时认为，四年后，没有人会关心 Kubernetes。我的论点不是它会枯竭、消失，并被其他东西取代，而是它或类似的东西会消失在人们的意识之下。就像我们不再需要担心我们运行的操作系统的内核版本一样，我们不会关心在我们的各种数据中心和云提供商中处理编排的是什么。你认为这是一个准确的预测，还是我会自食其言？

不，我认为这绝对是准确的。它是一个底层结构。它正在成为一个底层结构

除非你直接参与向 Kubernetes 添加功能，或者你以其他方式使用它，这需要你直接对其进行更改，否则你可能会使用其他更高级别的 API。作为开发人员，你可能会与 CI/CD 系统交互。也许你知道它内部是 Kubernetes，就像你现在知道它内部是 Linux 一样。

但你并没有真正直接与它进行太多交互。或者，如果你是一位数据科学家，或者你在数据基础设施领域工作，你更有可能使用像 Kudo 这样的工具来部署该服务，而不是试图将你的 Kubernetes 原语组合在一起以启动该服务。所以我完全同意这一点。我认为这是一个趋势。

这是一种浪潮，一种抽象层浪潮，总是在我们身后，或者说是不断上升的抽象浪潮。所以我认为 Kubernetes 也会如此。我认为大多数人，个体开发人员或平台的最终用户，

他们会知道它在那里，但他们会在不同级别的其他 API 上进行交流。我们现在看到围绕 CI/CD 的很多活动。我认为像 Argo 和 Tekton 这样的东西非常令人兴奋。围绕这一点有很多活动，人们希望使用 GitOps 方法来部署他们的软件。所以我认为这些是我们看到的抽象层上升的一些迹象

当然还有无服务器。所以，如果人们想了解更多关于你对这些和其他主题的想法，他们可以在哪里找到你？所以他们可以在通常的地方找到我。我在 Twitter 上非常活跃。我在 LinkedIn 上。我有时会在会议上发表演讲。这些是一些首先找到我的地方。

太棒了。非常感谢你今天抽出时间与我交谈。当然。非常感谢你给我这个机会。Toby Knaup，D2IQ（前 Mesosphere）的首席技术官兼联合创始人。我是 Corey Quinn，这是《云端尖叫》。如果你喜欢这个播客，请在 Apple Podcasts 上给它一个很好的评价。如果你讨厌这个播客，请在 Apple Podcasts 上给它一个更好的评价。