[介绍音乐]
Ryan Donovan：大家好，欢迎来到Stack Overflow播客，一个谈论所有软件和技术的地方。我是主持人Ryan Donovan。今天，我们将讨论一些云原生的内容——如何让你的虚拟机（VM）和Kubernetes和谐共处，这样你就不用为基础设施那些繁琐的细节而烦恼了。我今天的嘉宾是Nutanix云原生部门的副总裁兼总经理Dan Ciruli。Dan，欢迎来到节目。
Dan Ciruli：谢谢邀请，Ryan。我很高兴来到这里。
Ryan Donovan：不胜荣幸。在我们深入讨论基础设施之前，我们想先了解一下我们的嘉宾。你能告诉我们你是如何进入软件和技术领域的吗？
Dan Ciruli：当然。我是通过传统方式进入这个行业的。我学习计算机科学。但那是在我孩子们亲切地称为“1900年代”的时候，当时学习计算机科学并不是因为你想要一份赚钱的职业，而是因为你擅长计算机。
Ryan Donovan：没错。
Dan Ciruli：但事实证明，我喜欢它。我做了10年的工程师。大约10年后，我转入了产品管理，因为那时产品管理这个岗位已经出现，而且我喜欢与客户打交道。你知道，比起自己动手在键盘上解决问题，我更喜欢思考如何解决问题。所以，到现在，我已经做了20多年的产品管理工作，全都是在非常技术性的企业产品领域。具体到这个领域，我在谷歌工作了七年。那时，相关概念和技术背后的开源理念被发明出来，然后被公开和开源。所以，我从早期就开始在这个云原生生态系统中工作。我是Open API倡议的创始人之一；所以如果人们知道什么是Open API规范，我是那个组织的创始成员之一。Istio服务网格是CNCF中的一个重要项目——我曾是其指导委员会的成员。然后我还参与了一个名为gRPC的协议，现在它已经变得相当普遍。所以，现在我在帮助Nutanix将所有这些云原生的东西带给企业。
Ryan Donovan：那里提到的很多东西确实已经成为标准云原生栈的一部分。我认为当大家谈论云原生栈的基础设施层时，他们会想到容器、Kubernetes或其他基础设施编排器。但是，较旧的模式，比如虚拟机（VM）——在我们讨论如何让它们和谐共处之前，你为什么会想要这么做呢？
Dan Ciruli：这是个好问题。我打算分两部分来回答：首先，你为什么会想开始使用容器？其次，为什么需要它们和谐共处？而“为什么想使用容器”归根结底是：你可以更快地交付软件。当你做得好的时候，还有一些其他附带的好处，比如更容易保障安全、更具可扩展性、可以在更多地方部署。但根本上，你想采用容器的原因是，因为将代码推送到容器的开发者最终能够更频繁地进行推送。我喜欢给人们举的例子是：回想一下21世纪初，对于还记得那时候的人来说，当时最先进的搜索是Alta Vista，最先进的地图是MapQuest，最先进的电子邮件是Hotmail，对吧？收件箱只有10兆的限制，对吧？然后这家公司突然冒出来，说，“你知道吗？我们要同时革新所有这些不同的事情。”突然间，谷歌搜索横空出世，碾压了一切。谷歌地图比MapQuest或雅虎地图好得多，还有Gmail的无限存储空间。他们是怎么做到的？他们能够做到这一点，是因为他们行动、创新速度快得多，其中一个重要原因就是他们采用了容器。他们能够快速创新。当然，他们在后端存储等方面也做了一些其他工作。但容器在其中发挥了重要作用，现在整个行业都已经朝这个方向发展。所以，从根本上说，无论你是在做一个面向20亿人的网络服务，当你交付更小的增量时，你就可以更频繁地交付，这意味着你可以更快地创新。
Ryan Donovan：那么，在我们讨论第二部分之前，这还有个相反的方面：容器很棒。那为什么还需要虚拟机呢？
Dan Ciruli：所以，保留虚拟机是因为你已经有了虚拟机，对吧？事实是，迁移到容器——为容器编写代码本身并不难，但当你有一个已经在运行的应用程序时，改变它以便它能适应在容器中运行，这可能相当困难。我认为这是我们云原生社区有一段时间没有意识到的事情，因为我们总是说，“嗯，只要重新架构你的应用就行了。”但事实是，重新架构一个应用程序可能需要很长时间，需要大量工作，而且根本上还是同一个应用。它不会给你带来任何商业价值。你可以用不同的方式运营它，也许你能更快地移动，但也许这是一个不需要快速移动的旧应用程序。所以，目前，我们一直以在服务器上部署应用的方式编写应用程序，后来是在虚拟机上，已经有30年了。确实有30年，我们一直以同样的方式编写应用程序。这样的应用程序有数百万个。我昨天还在美国一家最大的银行。你知道，他们有成千上万个应用程序在虚拟机上运行。其中大多数永远不会被重写。所以，当他们那些新的移动应用和Web应用，以及等待，还有AI应用涌现时，所有这些新东西都是被写成要部署在容器中的。它们需要：A，与那些已经运行了10年、20年、30年的应用程序一起部署；B，有时需要与这些应用程序通信。这就是真正的原因。你知道，当人们谈论虚拟机何时会消失时，我说，“大型机何时会消失？”因为事实是大型机不会消失。这家银行说他们没有计划从数据中心淘汰大型机。他们也不会从数据中心淘汰虚拟机。所以，我们有了一项新技术。除非你今天创办一家公司，把所有东西都放在容器里，否则你会有成百上千，甚至成千上万的虚拟机，它们将在你的整个职业生涯中一直存在。
Ryan Donovan：我的意思是，“大型机何时会消失”这个问题人们已经问了一段时间了，对吧？
Dan Ciruli：是的。大概从1900年代就开始问了。
Ryan Donovan：是啊，是啊。所以，那些运行在虚拟机上的遗留系统，很多都很难停下来，然后用重构的应用来替代。那么，如何让它们和谐共处呢？虚拟机和Kubernetes集群之类的东西之间通信有什么问题？
Dan Ciruli：我认为，当处理得不好时，问题就来了。几周前，我和一家大型保险公司在一起。他们运行着完全独立的基础设施团队，这些团队运行着基础设施——本质上，他们的数据中心里有巨大的孤岛，对吧？一堆硬件可能为虚拟桌面提供存储，另一堆硬件运行着数据库和大型应用程序所在的虚拟机。他们还有另一堆硬件运行着Kubernetes，而且这个Kubernetes是安装在裸机上的。事实是，所有这些大型硬件堆栈之间的网络、身份管理、网络通信都根本不同。它们简直就像在月球上，实际上就像在另一家公司里，对吧？如果你有一个部署在Kubernetes中的应用，它需要与运行在虚拟机中的某个东西通信，因为你面对的是不同的网络系统、不同的身份验证和认证系统，这个过程真的很困难。再说一次，这和你与合作伙伴集成没什么不同。
Ryan Donovan：嗯。
Dan Ciruli：当事情做得好时，部署东西的基础设施之间就没有这样的孤岛。一个简单的例子是，你有一个运行在容器中的应用，需要与你虚拟机中的一个现有应用良好通信。理想情况下，你可以用这样的方式运行它们：它们之间拥有相同的网络，你可以在一个系统中编写一个单一的网络策略，说，“是的，我希望那个东西能和这个东西通信”，反之亦然，保护它们俩，而不是放开一切。保护它们，但同时允许它们通信。
Ryan Donovan：对。
Dan Ciruli：那些孤岛的另一个大问题是，当你创建这些孤岛时，不可避免地——这是我差不多10年前在Kubernetes早期采用者那里就看到的情况——他们购买专用硬件：你的数据中心可能有一部分满了。假设你一直在停用虚拟机，在你的虚拟机集群中，那台硬件上还有空间可以运行更多东西。但你有一个Kubernetes集群已经完全满了。而这些团队正在增长。他们需要运行更多的Kubernetes。你却无法利用放在另一堆硬件上的那部分资源，对吧？所以，拥有一个可以运行所有这些的通用底层平台，真的能解决很多不同的问题。
Ryan Donovan：是的。所以，我想问一个关于通信的简单问题。为什么不能直接通过虚拟机进行IP到IP的通信呢？
Dan Ciruli：你说“通过虚拟机”是指从虚拟机到Kubernetes，然后——
Ryan Donovan：是的。从虚拟机到——是的。
Dan Ciruli：可以。嗯，IP到IP。在“Kubernetes领域”中，IP地址的问题在于它们往往是短暂的，对吧？东西可以移动。而对于虚拟机，当有新的软件，当虚拟机升级或打补丁时，你通常是在那个运行的软件上进行。你的IP地址保持不变。在“Kubernetes领域”中，当有新的容器时，你不会更新你的容器，而是启动一个新的，然后销毁旧的，对吧？根据定义，那可能落在其他地方，可能有不同的IP地址，然后你可能还会遇到其他问题，比如，“好吧，所有流量都会通过一个出口网关，我们只需白名单这个出口。”但那样你就得再次编写不同的网络策略。所以，现在你可能有一些网络策略在做你的L2或L3层，但集群内部还有别的东西在做L7层，比如，“哦，这个特定的东西是否被允许在这里通信？”这只会变得复杂。
Ryan Donovan：没错。
Dan Ciruli：我认为，当实施得当后，对大多数人来说——我不确定是否每个人都意识到了这一点——对大多数公司来说，在虚拟机内运行Kubernetes实际上解决了很多这个问题，因为当你在虚拟机内运行时，即使某个东西运行在Kubernetes里，那个Kubernetes也是运行在虚拟机中的，你可以使用你的虚拟机网络策略。这听起来一开始很明显，但实际上，这就解决了一个大问题。当然，你还可以做更多的事情，但有趣的是，这确实解决了其中一个主要问题。它也解决了那个孤岛问题。因为当你在虚拟机中运行时，嗯，根据定义，你运行着各种东西。在大多数情况下，企业中的所有东西实际上都是运行在虚拟机里的，对吧？对。所以在同一硬件上，在同一个物理集群中，你可以在相同的物理节点上并排运行基于虚拟机的工作负载和基于Kubernetes的工作负载。
Ryan Donovan：是的。你知道，当你有云计算时，它本质上是在某种虚拟机（管理程序）上运行的，对吧？
Dan Ciruli：是的。这很有趣，因为在Kubernetes社区里有时会有争论，是运行在裸机上更好吗？我不知道世界上有多少百分比的Kubernetes运行在虚拟机里，但鉴于绝大多数都运行在超大规模云服务商的托管Kubernetes服务中，所有这些都运行在虚拟机里，而且是有原因的，对吧？再说一次，他们获得了一些网络方面的好处。当然，他们希望的是能够运行任何——他们当然不想将特定的工作负载绑定到特定的硬件上。然后，你可以访问Kubernetes中一些很好用的功能，比如自动扩展你的集群，自动缩减你的集群。对吧？你无法在基于硬件的集群上做到这一点。你需要去购买、配置机架。你需要更多的基础设施。对吧？
Ryan Donovan：这是一个非常手动的过程。是的。
Dan Ciruli：非常手动，而且非常耗时。当然，也有一些个别工作负载、个别集群的用例，你可能希望在裸机上运行Kubernetes；但对于大多数企业应用来说，正如我所说，越来越多的应用正被写成容器化的形式。
Ryan Donovan：没错。
Dan Ciruli：以这种方式来做是合理的，这样你可以在所有工作负载之间实现硬件的互换性等等。
Ryan Donovan：是的。那么，如果那是显而易见的解决方案，就像你说的，为什么人们不总是这样做呢？
Dan Ciruli：我认为有几个不同的原因。一是大型组织中可能存在——也许是康威定律（Conway’s Law）的一种体现。我不知道康威定律是否正好能描述它，但是——
Ryan Donovan：本质上是你把你的组织结构图给“产品化”了？
Dan Ciruli：你把你的组织结构图产品化了，对吧？你在数据中心里构建你的组织结构图。如果我是Kubernetes团队，我的预算是，“嘿，去买些硬件来运行Kubernetes。”首先，我不是虚拟化团队。我不关心管理程序。我可能认为我不需要在那里运行管理程序。我甚至可能毫无理由地对管理程序有偏见。我认为这是第一个原因。然后，我认为还有一些纯粹主义者认为，“嗯，这才是正确的做法。”但总的来说，除非你有专门用于特定工作负载的硬件，尤其是像基于GPU的硬件这种专用硬件——这确实是我们看到的情况，客户这样做有很好的理由——除非你购买的硬件在某种程度上是特定于该工作负载的，否则管理程序……你知道，它过去30年在数据中心变得如此普遍是有原因的。
Ryan Donovan：普遍。这是个有趣的表述。
Dan Ciruli：我这么说并无贬义。我加入Nutanix时可能对管理程序有偏见，但我当然已经被“治愈”了——你知道，我看到它被广泛且非常成功地使用着。
Ryan Donovan：所以，据我所知，很多大型机的范例设计早于大多数网络协议，对吧？是这样吗？
Dan Ciruli：是的。
Ryan Donovan：那是否使得管理程序/虚拟机与大型机上的虚拟机通信变得困难？
Dan Ciruli：与大型机上的虚拟机？是的。我的意思是，与大型机通信肯定会更困难。原因是，随着虚拟化的发展，我们基本上都标准化到了HTTP，而HTTP使得这些调用变得非常容易，而碰巧大多数那些东西从根本上来说都比它更早。对吧？我作为开发者的第一份工作就是与不同的硬件接口。真的，你写的代码是在线路上逐个比特、字节地传输数据。不开玩笑。所以，不幸的是，那些东西就是那样写的。你不能只是使用每种语言都内置的常见库之一。我们现在使用的每个框架都有这些让调用其他地方进程变得非常容易的东西。而大型机的东西比这些都更古老。
Ryan Donovan：是的。你提到你参与过gRPC的工作，据我了解，那是一种更现代的服务器到服务器通信解决方案。
Dan Ciruli：没错。
Ryan Donovan：那对于与大型机通信有什么影响吗？你能用gRPC来管理IOS吗？
Dan Ciruli：一点关系都没有。事实上，gRPC是基于HTTP/2的。所以，它现在是一个非常现代的实现。有趣的是，当它刚出来时，对人们来说感觉像是倒退了一步，因为它是个远程过程调用。RPC代表“远程过程调用”，这是一种旧技术。然而，它通过HTTP/2实现，有一些非常棒的语义，包括像双向流这样的功能。顺便说一下，我们现在正在进行视频和音频聊天。这里可能就有gRPC，因为，你知道，你可以在一个连接上同时进行双向流传输。它还有其他一些非常好的优点。其中之一是它在调用者和被调用者之间有一个合约，而标准的HTTP REST没有。对吧？你希望你能理解返回的JSON，并尝试解析它，但他们可以更改服务器上的内容，而你未必知道。所以，gRPC在某种程度上是我参与过的最喜欢的开源项目之一。原因是gRPC，谷歌在开源它的时候，我们并没有商业实现。没有商业化的gRPC产品。它只是一个协议。一个只是为了让网络变得更好的协议。它获得了巨大的采纳。我离开谷歌后待过的每家公司都在内部使用gRPC。因为它是一个非常方便的工具，它变得非常成功。说它是标准可能不太准确，但它已经变得极其普遍。它之所以如此，并不是因为有人为了推广他们的Kubernetes产品而推动它。每个人都有一个商业化的实现，对吧。每个人都有一个商业化的gRPC实现。它只是有用，而且，你知道，10年后它只是越来越多地被使用。所以，这挺酷的。
Ryan Donovan：是的，绝对。我最近还听到有人把它作为多代理系统的基本构件之一提起，比如它正在催生新的实现。
Dan Ciruli：向我以前的朋友Louis Ryan致敬，他现在在solo.io，是gRPC的发明者之一。我很幸运在谷歌的七年里一直与Louis共事。
Ryan Donovan：是的。很好。那么，你提到了为了与大型机通信而在线路上传输比特。有没有什么标准的中间件试图管理那里的通信？我想一定有人想出了什么办法。
Dan Ciruli：是的。所以，现在中间件通常是解决方案的一部分。正如我所说，我在那家银行，他们说，“你知道，我们没有计划淘汰大型机。”显然，他们不再以那种方式写任何新东西了。我猜发生的情况是，他们已经有了一个标准的方式——“好吧，这是我们利用那些东西的方法。我们会让它们留在那里。总有一天，应用程序会被停用。”对吧？然后最终，也许你可以停用放在中间的那块中间件。但你肯定不希望今天写代码的那些开发者去做我在90年代初做的事情，那肯定就是在线路上传输比特。
Ryan Donovan：是的。对于实际上要淘汰大型机并迁移到现代架构，你有什么看法吗？需要些什么？
Dan Ciruli：AI有一个有趣的用例，我在过去两年半的LLM热潮之前就看到有公司在做这件事，但现在确实非常热门，那就是对于那些你有源代码（可能是Pascal或Cobol——这些现在已经没人会的语言）的应用程序，通过LLM来生成一个现代版本。我认为我们可能会在这方面看到一些成功。你知道，首先用原始代码生成一组测试用例，对吧？这样你就能有效地证明当你这样做时它是正确的，然后再进行转换。所以，我实际上认为这是一个LLM可以发挥作用、真正有用的领域。我还没听说有人真正说过，“嘿，我们刚刚淘汰了最后一台大型机”，但我猜测这是它会取得成功的领域之一。我们会看到的。每个人都知道AI将改变一切，但我们不太清楚具体会怎样。在这一点上，我持相当乐观的态度，我们会看到一些公司真的能做到。
Ryan Donovan：是的。这似乎是LLM和大规模代码转换中较安全的一种应用，有很强的护栏和大量的脚手架。AWS做过一个项目，声称节省了大约4500年的开发工作量，那是一个Java升级项目。
Dan Ciruli：真的吗？是啊，是啊。这样算下来就多了，对吧？
Ryan Donovan：是的。
Dan Ciruli：尤其是在亚马逊工程师的成本水平下。
Ryan Donovan：没错。所以，你与很多遗留和现代混合的系统打交道。对于一个传统组织来说，通往云原生系统的路径是什么？
Dan Ciruli：嗯，我们正在试图解决的一件事是，我之前说过，世界上很大一部分Kubernetes运行在超大规模云服务商上，原因在于超大规模云服务商让获取一个Kubernetes集群变得非常容易，基本上一个按钮点击，或者一个API调用（如果你在自动化的话）。对吧？而且能让你安全地获得它，升级也无需你操心。你甚至不用想它；在云端它就自动发生了。为什么Kubernetes在本地部署（on-prem）中没有那么普及，是因为情况并非如此。对吧？在本地，你需要做很多照料和维护工作。你要负责那个Kubernetes集群。所以，我们正在尝试做的一件事（也有其他供应商在尝试），就是让在本地获取一个Kubernetes集群变得和在云端一样容易。我认为这是一个很大的障碍，因为现在有很多企业说，“开发者说我们想用Kubernetes写这个。”然后有人说，“好吧，那你就在那里做吧。”你在那里做，对吧？但从经济角度看，这可能不合理。你需要的数据可能不在那里。但Kubernetes在那里。所以，我认为一个很大的障碍是让它变得和在本地获得Kubernetes集群一样容易。顺便说一句，再次强调，在虚拟机中运行的另一个好处就是你可以做到这一点。你可以让它变得，“噗”的一下。现在，不用再购买硬件，什么都不用。你只要有一个Kubernetes集群。但不仅仅是获取它，还有它的照料和维护，对吧？保持它最新，确保它安全，确保它正确打补丁。所以，这是一个很大的障碍。之后，你知道，就归结为开发者体验和其他开发工具了，这些在云端作为服务可用，但你需要在本地的容器镜像仓库等等。在云端，我无需做任何事情。确保你有一个容器镜像仓库，确保你有一个可用的持续交付（CD）流水线。最终，你想达到的效果，本质上，就是谷歌在21世纪初拥有的，以及现在许多大公司已经拥有的东西：开发者签入代码，然后魔法就发生了，对吧？开发者签入代码，测试发生，部署发生，如果标志位和批准流程正确，生产部署就发生了。所有这些环节现在都存在。所有这些环节都可以存在。你也可以在本地拥有它们。我们正在尝试做的一件事就是让人们能够更容易地在本地启动这套流程，这样他们就能在必须出于安全原因、法律原因、数据原因、延迟原因等任何原因而留在本地的应用上，获得和在云端一样好的体验。
Ryan Donovan：你看到有组织把东西从云端移回本地吗？
Dan Ciruli：是的，我看到过。这是一个有争议的问题，因为我听到有分析师说，“不，没有这种趋势。”但绝对有。我经常与企业交流，他们会说，“嘿，我们在云端已经五年了，现在我们了解了经济性，我们知道它擅长什么，也知道什么我们自己可以做更便宜。”对吧？所以我跟这些公司聊过。有趣的是，我跟一家诞生于云端、本身就是Kubernetes原生的公司聊过。这是一家不到10年的公司，每月在云端的花费，我想说的是，数千万美元。他们告诉我他们的计划（今年早些时候聊的）是要把其中的80%迁移回本地。这很有意思，因为这不是那种“嘿，我们上了云，结果更贵了”然后又搬回来的情况。他们是“生于云”。他们意识到，他们做了经济核算，租用比购买更贵，对于一个如果你要一直使用那台机器的工作负载——虚拟机能真正帮助你做到的另一点。是的，在规模上，在本地运行可能更便宜。云很棒。有些服务只能在云端获得。灵活扩展、按需获取资源的能力，你知道，它带来的变革是不可思议的，对吧？但要让企业能够就为什么他们想在某个地方运行某个东西、他们想在哪里运行它做出真正明智、合理的决定，然后他们就能在那里运行它。而不是“哦，哪些工具可用？”理想情况下，你知道，你要摆脱这种思维方式。
Ryan Donovan：对。如果你有那些基础流量，你知道你会得到什么。你就把它放在本地，对吧？
Dan Ciruli：对。是的。我们有客户就是这样运作的。他们所有临时性的集群都在云端。他们在那里做开发，但当他们运行生产后端时，他们是在本地运行的。
Ryan Donovan：那么，什么样的软件、什么东西最适合在云端运行呢？
Dan Ciruli：我认为，如果你需要访问一个在本地很难复制的服务。我最喜欢的例子是BigQuery。谷歌在BigQuery上投入了巨大的资源，你可以做令人难以置信的数据处理，短期内可能需要访问海量的服务器。对吧？这太棒了。任何需求量会剧烈变化的东西，可能甚至是每天变化。你可能是一家只在世界一个地区运营的公司，而且你的业务主要在白天进行。如果是这样，那么那种东西你可以在每天晚上缩减规模。或者你是那种——当我在谷歌时，《Pokemon Go》游戏发布了，对吧？
Ryan Donovan：哦，对，是的。
Dan Ciruli：并且，你知道，大概三天内就获得了1亿用户，他们绝不可能预先投入资金去准备一仓库的机器，对吧？以防他们的游戏成为有史以来最受欢迎的游戏。通过在云上构建（他们构建在GKE上），他们能够不断地启动、添加集群，不断启动新的Kubernetes集群。满足了巨大的需求。所以，那种类型的应用，就像我说的，有几个特点。他们的全球网络非常棒。顺便说一下，云不会消失。
Ryan Donovan：当然。
Dan Ciruli：云是惊人的。它为如何思考运营业务带来的灵活性是极好的。我只是希望人们能够将工作负载运行在合适的地方。
Ryan Donovan：对。用合适的工具做合适的工作。我知道我们没怎么谈论Nutanix，但你们在那里做的工作有什么独特之处？
Dan Ciruli：我认为Nutanix真正与众不同的一点在于，首先，Nutanix最初是一家存储公司。一些谷歌工程师说，“嘿，谷歌在商用硬件上存储数据的方式真的很酷，”对吧？谷歌在普通的Linux服务器上获得了惊人的性能和弹性，这在21世纪初也是超级突破性的。所以他们创立了Nutanix，并构建了一个操作系统，本质上是我们的存储工具。它是分布式存储。而分布式存储正是构建谷歌的基础，对吧？谷歌有分布式存储，然后有一个容器管理层。所以，在Nutanix，我们拥有运行历史和现代应用所需的所有基础，因为我们有这套很棒的分布式存储。它非常适合容器化应用，非常适合基于ML和AI的应用。那些东西也是在分布式存储上开发出来的，而且我们还有一个真正的企业管理程序，非常擅长运行那些在1990年到2020年间开发的工作负载。所以，Nutanix真正与众不同之处在于，对于大多数企业来说，他们考虑一家供应商做虚拟化，另一家供应商做存储，再另一家不同的供应商做容器管理。而Nutanix，虽然我们可以很好地互操作，可以在任何这些层级上与其他厂商的产品一起工作，可以使用任何人的存储、任何人的管理程序、任何人的容器管理，但我们确实提供了一个包含所有这些的完整解决方案。所以我们确实有客户会说，“好的，我要这个，因为它有我需要的所有东西。”没有其他公司能说，“是的，我们真的能把这些事情都做好。”
Ryan Donovan：我和其他一些做大规模分布式存储的人聊过，谈到分片和复制等问题。在你看来，处理分布式存储最难的事情是什么？
Dan Ciruli：嗯，我的意思是，我认为这本身至少需要30分钟的会谈。
Ryan Donovan：那是太长不看版（tl;dr），对吧？
Dan Ciruli：太长不看版是：你必须构建一个分布式数据库，对吧？从根本上说你需要一个分布式数据库。你无法后期再添加。而今天大多数企业基本上都在使用我们称之为“三层架构”的模式，即存储运行在一些地方，网络运行在一些机器上，虚拟化又在另一些地方。几乎不可能事后改造它，然后说，“好吧，现在我们如何把它变成分布式存储？”所以，Nutanix是构建在分布式数据库之上的。我有一位从VMware加入的同事，名叫Kostadis，他一直在发布一系列非常棒的博客文章和LinkedIn帖子，讲述加入Nutanix如何让他大开眼界，他意识到，“嘿，这比我们过去看到的技术领先了十年”，Nutanix已经拥有他未来十年想构建的东西。所以是的，你必须从一开始就以这种方式构建。正如我所说，Nutanix是由一些前谷歌员工创立的，他们基本上就是这么做的。
Ryan Donovan：好了各位，现在是节目时间，我们要喊出某位来到Stack Overflow、贡献知识、分享好奇心并为自己赢得徽章的人。今天，虽然惊悚季节已过，但我们还是要喊出一位“亡灵法师”徽章的获得者。恭喜David Ferenczy Rogožan回答了“adb shell mkdir 在哪里创建目录”。他回答了一个超过60天后的问题。所以他回来了，并且让它起死回生。哇哦哦哦。
Dan Ciruli：真是个英雄。恭喜David。
Ryan Donovan：真是个英雄，对吧？我是Ryan Donovan。我在Stack Overflow编辑博客，主持播客。如果你有问题、关切或想讨论的话题等等，请给我发邮件：podcast@stackoverflow.com，如果你想直接联系我，你可以在LinkedIn上找到我。
Dan Ciruli：我是Dan Ciruli。想了解我们的产品？当然，请访问nutanix.com，如果你想听我的闲聊，可能在Blue Sky上。我在Blue Sky上是 danciruli.cloud，我在LinkedIn上也写点东西。
Ryan Donovan：谢谢大家收听，我们下次再聊。
订阅播客 在你喜欢的收听服务上获取《The Stack Overflow Podcast》。