Deep Dive
Shownotes Transcript
#289：对于初创公司来说，云选择难题至关重要。虽然主要提供商提供激励和熟悉度，但走出传统道路去探索其他提供商，甚至建立专门的解决方案，可以带来显著的成本节约和量身定制的优化。关键在于理解何时才能通过商业产品进行扩展，以及何时才能进行更定制化、可能成本更高的项目。在本集中，我们与 Namespace Labs 的首席执行官 Hugo Santos 进行了交谈，他讲述了他们如何通过针对特定用例进行优化，从而找到了能够胜过大型云提供商的利基市场。然而，这条道路是复杂的，并非对每家公司都实用，尤其对于那些缺乏必要基础设施专业知识的公司而言。Hugo 的联系方式：X（前身为 Twitter）：https://x.com/20thr LinkedIn：https://www.linkedin.com/in/hugomgsantos/ YouTube 频道：https://youtube.com/devopsparadox 在 Apple Podcasts 上评价播客：https://www.devopsparadox.com/review-podcast/ Slack：https://www.devopsparadox.com/slack/ 联系我们：https://www.devopsparadox.com/contact/</context> <raw_text>0 我相信人类思维中的创造力是无法被取代的，所以你总是需要某种指挥者，我预计五年后仍然如此。这是 DevOps Paradox，第 289 集。何时构建自己的系统，何时使用现成系统。欢迎收听 DevOps Paradox。这是一个关于各种随机话题的播客，在其中，我和维克多假装我们知道自己在说什么。
大多数时候，我们通过在任何地方都尽可能多地使用“DevOps”一词来掩盖我们的无知，并将其与 Kubernetes、无服务器、CICD、团队生产力、快乐岛屿以及其他让我们听起来像知道自己在做什么的花哨表达混在一起。偶尔，我们会邀请确实懂一些东西的嘉宾，但我们不会经常这样做，因为他们可能会让我们显得无能。
真相就在那里，我们不可能找到它。附言：这是达伦在读这段文字，并为维克多让我这样做而感到尴尬。以下是您的主持人，达伦·波普和维克多·法森。所以我们在这里，维克多。我们开始轻松进入假期了。现在是十一月中旬。事实上，如果你在发布日期收听这个节目，那是 11 月 13 日。通过提前录制的神奇效果，维克多现在正前往 KubeCon。
美国或北美，你想怎么说都行。我们的嘉宾也是。在今天的节目中，我们邀请了 Hugo Santos。你们俩都将在 KubeCon 上见面。让我先问一个问题。我先问 Hugo。我们今年是否期待 KubeCon 有什么新东西？
这是一个很好的问题，首先感谢你们的邀请，很高兴能与你们聊天，有些人参加 KubeCon 的时间比我长得多，但看到 KubeCon 从一小群从事 Kubernetes 工作的人发展到如今这个行业中围绕着它的众多公司，这绝对是一段有趣的旅程。
这就是我的预期。我实际上是去那里看看有什么热门话题，什么东西吸引了人们的注意，以及人工智能是如何渗透到我们讨论的一切中的。我主要去是为了人，而不是其他任何东西。我非常感谢这种联系，能够与我认识一段时间的人聊天，看看他们在做什么。现在，维克多，在你回答之前，Hugo 是他自己的公司的首席执行官，所以他可以选择去 KubeCon。
不像我们这些公司的雇员，对吧？所以 Hugo，你处于一个非常有利的地位。他也是受雇的，只是受投资者雇佣。好吧，这绝对是一种有趣的说法。我们与我们的投资者关系很好。我认为如果他们觉得我们没有很好地使用我们的资金，我相信他们会敲响警钟。但在这种情况下，我认为重要的是要身处行动中心。我们实际上是那些思考同样问题的人。所以这是一个深思熟虑的……
决定。但当我们在内部讨论这个问题时，我们也会考虑在一年中的哪些会议、哪些聚会上值得参加，我们非常关注将会有哪些人参加，哪些公司会参加。我认为决策过程可能与你自己的过程没有什么不同。维克多，今年 KubeCon 会有行动吗？不会。第一年、五年、六年、七年，也许八年。
我们处于发现阶段，嘿，哦，我没有想到这一点。所以公司或项目正在出现一些你以前从未听说过的新的想法，对吧？哦，服务网格，对吧？
或者其他什么东西。我觉得我们现在更成熟了。所以我不认识任何人正在做一些以前从未见过，并且将在 KubeCon 上宣布，每个人都会睁大眼睛说：“哦，我不敢相信你想出了这个主意。”我认为我们不再处于那个阶段了，对吧？这将发生在其他一些领域，而不是在云原生 CNCF 中，这没什么好说的。
这并不意味着没有改进。只是现在有更多渐进式的改进。类似于 Docker，对吧？Docker 已经不再彻底改变任何东西了，对吧？他们只是在逐步改进他们已经拥有的东西。现在，Hugo 以前在谷歌工作过，这么说对吗？是的，实际上是三年前。时间过得真快。所以你离开已经三年了。你在谷歌工作了多久？
我在那里工作了九年，从事基础设施工作，主要关注内部开发人员，他们构建搜索、YouTube、照片和其他应用程序。从谷歌的角度来看，这是一段非常有趣的旅程，它是一个微型世界。你可能从其他人那里听说过这个说法。这是真的。每当我们今天将人员
带到我们公司时，如果他们来自谷歌，我们经常会谈到一个“去谷歌化”的时期，在这个时期，我们会将我们在谷歌内部做事的方式与行业的做法进行大量翻译。但在大多数情况下，语义相似，只是解决相同问题的不同方法。所以在那九年里，如果你要算算的话，那大概是 2015 年你在那里？13 岁时我开始的。
是的，因为你已经离开三年了。所以 13 岁是在 Borg 的早期阶段，也许吧？我的意思是，Borg 已经存在了，但那是它开始泄露的时候？我认为那是谷歌开始谈论 Borg 的时候。当我加入时，Borg 已经非常成熟了。所以它有几个阶段。有些团队仍然……
没有完全认同运行多个副本、在容器中运行或谷歌版本的容器中运行的性能影响。但是当我离开时，Borg 无处不在，就像一切一样。除了少数几个非常专业的应用程序之外，几乎所有东西都在 Borg 上运行。人们倾向于将 Borg 视为类似于 Kubernetes，但它有其自身的特点。方式
软件包分发方式略有不同。网络方式略有不同。但在大多数情况下，它具有类似的语义或至少类似的目标。这就是 Borg 被整合在一起的原因。但是，2013 年不同团队如何使用 Borg，以及 2021 年我离开时我们最终如何使用 Borg，这是非常不同的，极其不同。
然后我认为这里与我们看到的 Kubernetes 和所有 CNCF 项目也有很好的相似之处。就像事情一开始更简陋，然后随着时间的推移，它们在复杂性和集成性方面都会增长。这也是我们看到的旅程。
直到它们发展到足够大的规模，以至于没有人能够再取代它们了，对吧？能够取代某些东西所需的能量有时是如此巨大，以至于根本不值得。我的意思是，我不能代表谷歌发言，但我们经常感到这种压力，好吧，我们对 Borg 的投入如此之大，但业界正在采用 Kubernetes。那么为什么谷歌不干脆在内部也迁移到 Kubernetes 呢？
这极其困难。内部系统运行的规模如此之高，以至于需要大量工作才能使等效系统达到同等水平。对于一家正在运营的企业来说，即使是谷歌规模的企业，也很难证明这样做是合理的。因此，看看 Borg 将在谷歌继续作为基础设施存在多久将会很有趣。据我所知，它今天仍然是如此。
老实说，我实际上很惊讶 Kubernetes 本身现在如此广泛地使用。如果你五年前问我，我会说，是的，它会爆炸式增长。人们会喜欢它。他们会广泛使用它。但是那些在 20 年前就创建了愚蠢的企业将无法迁移。有些企业没有迁移。他们中的大多数没有 100% 迁移。但我仍然惊讶的是
公司有足够的动力或看到了足够的价值来进行这项投资，因为这是一项巨大的投资。是的。我认为 Kubernetes 的开发者做得非常好的一件事是可组合模型。在某些方面，没有单一的 Kubernetes。有一个控制平面。但是如果你看看不同公司内部的情况，他们都会将不同的部分组合在一起以构建自己的基础设施。
有些公司，甚至包括我们自己，我们试图尽早解决这个问题领域。但我认为现在回想起来，这实际上是一个优势，并且不可避免地需要专业化。Kubernetes 更像是一个构建块这一事实，我认为这使得不同的公司能够使用它。我认为 Kelsey 曾经提到过
Kubernetes 更像 Linux。它更像是一个核心操作系统，但更像是一个分布式操作系统。我倾向于认同这一点。它建立了一种共同的语言，构建系统不同部分的人们可以互相理解，并且他们有可以构建的 API。他们可以选择他们要定位的 API，以及他们要组合的 API。
是的，这增加了复杂性，因为存在所有这些不同的解决方案，但这也是我认为 Kubernetes 能够获得如此广泛采用的原因。即使超越了像 ECS 和 Google Cloud Run 这样的容器平台，我认为这种灵活性最终也会非常强大。老实说，我对这一点有复杂的心情。我认为这种可访问性对项目本身非常非常有益，
因为它是如此可扩展，我们最终可能会出现数百或数千个不同的项目来竞争想法并推动其发展，对吧？因为我觉得这与 Kubernetes 本身以及其他所有东西，即生态系统本身一样重要，对吧？这才是 Kubernetes 的真正含义。但是普通人、用户却经常感到困惑。你知道，你在 KubeCon 或其他地方看过多少次演讲，
从 CNCM 全景图的屏幕截图开始。你知道，好的，这个演讲将讨论围绕着我们的疯狂，对吧？现在，我觉得我们比几年前要好得多，因为我们有一些赢家。好的，哦，你很可能使用 Argo CT 进行同步。你很可能使用 Cilium。所以它可能会稍微好一些，但它仍然非常复杂。
仅仅是选择，你知道，仅仅是说，好的，我该如何开始？是的，确实如此。我认为很多人都在寻找解决这个问题的方案。我不知道是否应该有一个解决方案。这就像技术中的所有事情一样。存在权衡。你可以缩小选项集，然后使其更简单。但是有了这种简单性，你就会失去构建更强大解决方案的许多灵活性。
我很欣赏 Cilium。所以 Cilium 解决了大量问题，但是 Cilium 能够出现是因为有足够的灵活性来构建像 Cilium 这样的东西。因为如果没有更改 CNI 的 API，那么 Cilium 可能就不会存在。将其集成到 Kubernetes 生态系统中将非常困难。如果你没有一个增量故事，那么你无论如何都会失败。
所以我认为这些抽象很有帮助。是的，它们是有代价的。代价是色彩斑斓、像素极高的 CNCF 全景图横幅不断增长，但这是其中的一部分。
全景图会停止增长吗？不会。我也认为它不会停止增长。我认为维克多是对的，曲线会发生变化。它在一开始的时候呈指数级增长，那时有很多问题需要解决，然后它会稳定下来，现在可能呈次线性增长，实际上它减缓了增长速度。但我也不认为它会停止，因为世界不会停止。就像问题类型不会停止一样。五年前，我们会谈论
GPU 编排和调度，但不会像今天这样强调。这样做有非常现实的原因。几年后，还会有其他一些重要的事情，我们需要找到一种方法来表示它，并拥有正确的抽象和正确的支持软件，以便将其整合到我们已经拥有的东西中。所以我认为它永远不会停止。五年后会发生什么？这取决于你阅读 Twitter 的哪个部分。是的。
好的，让我们阅读 X、Twitter 或任何东西的所有部分。你怎么看？我认为五年后，但也许让我们先说一下，我最熟悉的工作是技术，对吧？无论是软件工程还是系统工程。所以这就是我思考最多的事情。我认为五年后，它将更加辅助。我认为解决某些复杂性级别将更容易。
因为你将能够访问大量的知识百科全书，你可以直接提出问题。他们甚至可能能够推断你正在问的问题。这是正确的问题吗？我们应该如何处理它？有些人认为，某些类型的工作将被取代。我相信人类思维中的创造力是不会被取代的。所以你总是需要某种指挥者。我预计五年后仍然如此。
所以我认为，副驾驶可以帮助软件工程师、DevOps、DC 运维人员以及各种职业，并提升他们的工作效率。我认为缺点是将会有更多的输出，而且目前还不清楚该输出的质量，即信噪比是否会保持不变。很可能会下降。所以将会有更多的软件，但是
我认为很多软件的质量会较低，因为开发新软件所需的努力会更少。所以我认为这是它的对应面。我认为我们不知道如何解决这个问题。现在，我们仍然相当简单，因为你与 LLM 交互，你提出一个问题，你仍然解释那个问题，即使围绕着能够整体构建应用程序的自主代理有很多精力。我还没有看到……
任何以这种方式构建的有意义的大型系统。如果有什么不同的话，我在谷歌的经验告诉我，这些类型的问题在很长一段时间内都无法解决。软件只是问题的一小部分。它是一个重要的部分，但它只是问题的一小部分。所以是的，辅助，人们将能够用更少的东西做更多的事情。
也许规模较小的公司能够构建更大、更强大的产品，因为你不需要那么多人。这就是我预计五年后将要达到的方向。我认为软件行业历史的一个重要部分是试图消除或减少我们可以做的重复性工作，以便我们可以更多地关注创造性工作，对吧？
对我来说，这次谈话与我们很久以前关于 Java 的谈话非常相似。哦，那些家伙，他们不知道如何自己管理内存，对吧？这会过去，对吧？这将是低质量的，还是不是。结果并非如此。它解放了人们去关注其他事情。现在，在 Java 的情况下，这是错误的，因为内存管理解放了人们去编写 getter setter 指令，但是……
尽管如此，这些事情一直在发生。对我来说，人工智能的现状非常相似。它通过让我不必打开浏览器标签页并转到 Stack Overflow 来复制粘贴内容来帮助我。我现在可以直接从我的 ID 中做到这一点，对吧？这将继续改进。我更感兴趣的是操作，对吧？
我们几乎肯定会达到一个点，即操作将更多或更少地减少人工干预。因为这就是重复性发挥重要作用的地方。你们中有多少人只是通过重新启动应用程序来解决问题，对吧？我的意思是，这是一个愚蠢的例子，但是肯定有很多空间可以
通过执行某些操作来真正帮助人们。需要明确的是，Kubernetes 已经承担了部分工作负载，但我们可能可以通过人工智能做得更多。我认为这将使更多的人能够自动化以前需要一定程度专业化的系统。你必须知道特定的一组工具，或者你必须编写一些东西。
无论是小的脚本还是程序来进行数据自动化。我认为这将实现这一点。在某些方面，它可能会以更有效的方式实现这种无代码运动的想法。我认为自动化还有另一面。我在谷歌做的一部分工作，我实际上是从 SRE 开始的。即使我后来构建了一些基础设施，我也一直与 SRE 团队非常接近。
如果我们看看 SRE 经常在做什么，他们正在确保我们拥有做出决策的正确数据。然后在发生事件时或定期地，他们会查看这些数据以做出决策。这是一个非常普遍的问题，有时你要么没有正确的数据，要么有如此多的数据以至于很难真正查明根本原因。我认为这是一类问题，它更像是一个定性问题。
决策而不是定量决策，即哪个数据点是错误的，而是更多地关注趋势和相关性，其中像 LLM 这样的系统最终可能会产生影响。我们在内部进行了很多关于是否应该开始的讨论，并且有一些公司正在这样做，训练专门用于查找跨系统故障相关性的模型。
例如，此测试失败的原因不是因为此错误行已被提交，而是因为 Postgres 中的此事务由于此原因而失败。通常为了连接这些点，你需要同时拥有数据，并且你需要知道它们是相关的。而这些正是 LLM 擅长做的事情。所以我预计未来几年在这个领域也会有一些重大改进。
人们真的会托管他们自己的 LLM，还是他们只会使用服务，无论是来自特定服务还是三大云厂商？这里有一个经济问题，还有一个哲学问题。我认为围绕隐私有很多问题我们还没有答案。到目前为止，我们围绕数据所做的一切，都是为了某种工作原因而产生的数据，对吧？
现在，随着 LLM 越来越多地融入我们的日常生活，他们实际上知道，他们不仅知道输出，而且还知道你的思路。我听到一些人对此表示担忧。例如，我不希望透露我正在研究这个问题，而不仅仅是查询流，因为实际上，你经常进行的对话
会告诉你很多关于你前进方向的信息。所以我认为从隐私的角度来看，也许是因为我是一个欧洲人，你知道，当我们考虑很多隐私问题时，将会有经济上的投资来支持某种自托管或以隐私为中心的解决方案。所以在大型方面，我认为除非你是超大规模云提供商或类似超大规模云提供商，否则不可能找到一个经济单位。首先，机器的数量……
你需要多少，无论是 GPU、TPU 还是其他系统、专用系统。以及你需要的巨大能量，这简直令人难以置信。在谷歌，我对这一点没有任何了解。现在我有了，因为我们实际上将我们自己的硬件部署到数据中心。所以我们也是一个小型云提供商。
我只能想象从几十兆瓦到数百兆瓦再到千兆瓦数据中心的挑战。你作为一个小型运营商根本无法做到这一点。所以你的公司是 Namespace Labs。你正在将你自己的硬件放入托管设施中。我正在补充说明。正确吗？是的。
那么，为什么你要这样做，而不是按照人们告诉人们做的那样，说，去 AWS、去谷歌、去 Azure？为什么你决定运行你自己的硬件？在 2024 年，这似乎完全是愚蠢的。在某些方面，这确实很愚蠢。我们这样做的原因是，对我们来说，对于我们正在解决的那些问题类型，
我们可以通过这样做为用户提供更好的服务，因为我们设计进入这些机架的计算和网络的方式，以最大限度地提高这些用例的效率。实际上，其中一些可以追溯到我们之前讨论过的一些内容，例如 Kubernetes 和容器。在 Kubernetes 中，你可以启动 pod，它会知道如何从注册表中提取镜像，它就能工作。
但是端到端，可能需要几十秒才能真正启动一个 pod。为什么会这样？因为许多这些组件的构建方式可能没有考虑性能，它们没有垂直集成，以及其他一些原因。我们认为，好吧，我想在一秒钟内启动 pod。那么我该如何在一秒钟内启动 pod 呢？好吧，我需要某种类型的 CPU。我需要一定数量的内存带宽。
我需要提前以特定方式设置我的镜像。我需要足够的网络带宽。我们发现获得这些保证的唯一方法是部署我们自己的硬件。我们也有一些用例，我们使用 AWS 和其他大型云提供商，它们提供了非常棒的服务。我认为人们应该依赖
云。我认为这对大多数公司来说是有意义的，但我们正在构建基础设施，这种垂直集成，我们正在使用它来真正提供我们否则无法提供的极高性能。这正是我喜欢的答案，对吧？你正在建立你自己的数据中心。我的意思是，也许是托管的，没关系，因为云提供商目前没有解决你遇到的问题，对吧？是的。
这与我从大多数其他人那里得到的答案不同。相当多的公司不想使用大型云提供商，原因不仅仅是这一点。我不信任他们，或者我可以做得更好，而他们不能。我们这样做，相信我，这真的非常困难。这就是为什么我说，即使我们这样做，它仍然有点愚蠢。我们这样做是因为……
我们多次尝试使用大型云提供商提供的服务来构建相同的服务，但我们就是做不到。这就是为什么我们转向我们自己的硬件。这有点道理。大型云提供商在经济上更有动力提供大多是通用硬件，它非常适合大多数工作负载。
而我们的工作负载略有不同。我们关心的事情略有不同。就像大多数人一样，他们可能每天只部署几次 pod，或者每天部署几百次 pod。因此，如果一个 pod 需要 10 秒或 20 秒才能启动，这不会真正改变太多事情。对我们来说，启动延迟非常重要，因为我们正在构建短暂的计算，
并且你想启动工作负载，并且你想让工作负载立即开始工作，尽快开始工作。因此，启动延迟非常重要。然后你进入这些大型云提供商的 SKU 中，甚至是他们的高端 SKU，并且你
看到这样的情况并不少见，好的，你可以获得的最大虚拟机，除非你获得网络优化的虚拟机，这将影响其他方面，它大约是每秒 25 千兆比特。25 听起来很多，但是，当你非常快速地推送千兆字节的数据以在一秒钟内启动等效的 pod 时，你需要更多的带宽。这就是我们与众不同的地方之一。所以听起来你可能正在使用 InfiniBand
类型的速度来满足你的需求。这是真的吗？我们仍然只使用普通的以太网，但是，或者在一个机架中，我们有每秒数百千兆比特的容量可用。但这不仅仅是这一点。我的意思是，这极其重要，但是局部性也很重要。你在一个机架中有一定的网络容量，然后如果你必须从一个机架到另一个地方，那么你已经倾向于
我们的系统会根据你需要的數據所在位置来决定在哪里启动工作负载，以便我们尽可能多地依赖机架内的网络容量。这也是谷歌也使用的一种技巧。有很多工作负载需要一段时间才能迁移到 Borg，因为 Borg 很长时间都没有机架级别的调度亲和性。
当你进行高性能计算时，你需要考虑更多的事情，这超出了范围。也许我有 100 个虚拟机，它们之间的网络可以工作，就像我的服务网格一样。在我们的案例中，机架内的网络带宽和网络带宽是我们在调度时考虑的重要因素。我们实际上根据我们拥有的容量来放置等效的 pod。我认为所有这一切的关键部分是你之前使用的一个短语。
用例。你有一个特定的用例，听起来你可能已经在公共云上尝试过，并很快确定，呃，这对于我们的需求来说行不通。所以我们必须忍痛，不构建我们自己的数据中心。你没有走那么远，但是你确实去了一个托管设施并开始构建你的机架。在你去了托管设施之后，在谷歌工作之后，在弄清楚这部分内容的过程中，有哪些痛点？
实际上，就像 15 年来一直在使用某种托管云一样，Borg 就是某种托管云。在那之前，我在谷歌之前还有一家公司，我们在 AWS 上构建。云的一个神奇前景是，你需要容量。而且在大多数情况下，你可以立即获得这种容量。
如果你想调度大量容量，你可能会遇到一些配额限制。但是如果你能够解决这些配额问题，那么你就可以立即获得这种容量。嘿，你自己的数据中心也会遇到配额限制，需要明确这一点。没错。这就是我想要说的，这就是我们部署我们自己的硬件时与众不同的地方。有采购的各个方面。首先，你需要决定你需要多少硬件。
因为这不会自动出现。可能需要六到八周才能提供给你。你需要有可用的托管机房容量。所以也许你已经有了一些机架，然后你想部署额外的硬件，你需要更多的一些机架。你打电话给数据中心说，在这个数据中心，我没有一个完整的机柜，所以我只需要多几个机架。他们可能会告诉你，好吧，我们六个月内没有更多的机架了。然后你必须开始在其他地方寻找。
电力预算。这是另一件事。我们也把电力考虑进我们的调度中，因为不同的机架有不同的额定电路。我们在不同的数据中心部署。我们有不同类型的合同。在某些合同中，我们有可用的完整电路。在其他合同中，我们按使用付费。因此，我们实际上决定在哪里部署你现在要运行的工作负载
基于诸如电力之类的因素。电力供应情况如何以及它会花费我们多少钱？而这些类型的问题，当你只使用云时，你永远不必考虑。而且你不应该考虑。我认为这些是非常专业的问题。但我们必须学习很多东西。从冷却到功耗到网络容量，你的中转提供商是谁，
你如何构建你的主干？所有这些你必须考虑的事情。如果你不是一个基础设施极客，或者你的团队中没有一群基础设施极客，我会说，甚至不要冒险走这条路，因为它很痛苦，你也需要从中获得一些乐趣，因为它非常痛苦。在你的情况下，这可能不是这种情况，但在许多其他公司，他们往往没有意识到这一点。
他们减少了多少资源，我的意思是，从实际上可能更重要的事情中减少了多少人力，对吧？哦，我们可以做到。我知道你可以做到。但是如果这些人当时正在从事这项工作呢，对吧？100%。即使你与完全托管的提供商合作。所以我认为随着时间的推移，它一直存在，但我认为现在有更多了。
所以有一些提供商，你可以打电话给他们，然后你说，好吧，我想要机架中这么多硬件。他们会为你订购硬件。他们会部署该硬件。他们会部署网络容量。你有网络工程师可以为你服务。你为这些服务支付溢价。但即使在这些情况下，你仍然没有摆脱你需要管理的硬件这一事实。你还需要考虑其他一些事情。但这是一个权衡的世界。在我们的案例中，这是一个成本，但我们从中获得的回报非常高。我们经常告诉人们，我们构建全栈系统。就像当我们构建新产品时，我们实际上会考虑我们的机架设计中当前机架中有多少容量可用，以及我们应该如何改进
甚至某些产品只在我们的一些未来机架中可用，因为它们的设计就是这样。所以我们现在有了这种奢侈，因为我们已经进行了这项投资，我们可以真正深入研究并改变这些功能的经济性，以便我们可以同时提供非常高的性能（对我们来说是主要的驱动因素），但仍然保持具有竞争力的价格点，这样你就不会投入大量资金。
我认为托管机房有其空间，但并非适合所有人。我认为大多数人最好投资云。你有很多提供商。如果你不想在大型超大规模提供商上花费很多钱，那么有一些较小的提供商提供的产品几乎一样好，而且价格非常有竞争力。那是……
我觉得云领域的一个错失机会是，你拥有大型超大规模提供商，谷歌、Azure、AWS、阿里巴巴等等。然后你有一堆较小的提供商，比如DigitalOcean，他们基本上说，我们正在以较低的成本和更轻松的方式提供这些超大规模提供商的子集服务。但我没有听到更多专门的提供商。
我觉得这可能是一个机会。嘿，与其试图与AWS相同，只是更便宜，为什么不提供AWS可能提供的服务呢，但对于他们来说，解决这个问题的规模还不够大。你可以非常专业，说，嘿，我的客户是那1%，无论他们是什么，而不是我只是更便宜。
一件非常现实的事情是创新者的困境，如果你是一个大型超大规模提供商，我在过去几次看到过这种情况，不一定是这个领域，更多的是在消费者方面。但是，如果你有10亿美元的收入，只是为了用一个数字来说，如果你有机会启动一个产生1000万美元收入的新业务部门，那么投资这个业务部门真的很难，因为它与你的总收入相比只是一个如此小的相对数字。
但如果你今天才开始创业，你的目标市场实际上可以产生1000万美元的收入，那将非常有吸引力。所以我认为，对于许多初创公司来说，这是一个机会。在许多方面，这也是我们试图做的。我们是一家专门的云提供商。我们追求一个特定的垂直领域。当我们努力在这个特定垂直领域打造最好的产品时。我认为还有许多其他垂直领域。
正如你提到的那样，它们是人们可以解决的机会。我发现有一些公司很鼓舞人心。Model在无服务器GPU编排方面就是一个很好的例子。Fly是另一个很好的例子，它保持API控制平面超级简单，只需运行你的应用程序。所以我认为有空间去做一些特别的事情，仍然可以瞄准相当大的市场。
我想回到你1000万美元的例子。假设我想出了这个主意。假设我要运行一个Valkey特定服务。Valkey是开源Redis。多年来，我们已经看到了人们运行Elasticsearch的各种变化，当时Elasticsearch最初是开源的。不同的对话。但我有一个1000万美元的想法，但我不知道如何正确使用公共云。所以即使我有一个1000万美元的想法，我也要花费2000万美元来获得这1000万美元。
我们如何才能避免这种情况，让我有一个1000万美元的想法，而我实际上只需要花费200万美元就能做到？是的，这就是工程独创性发挥作用的地方。我现在年纪大了。随着年龄的增长，我越来越敏锐地意识到这将很难，但同时抓住机会，也会做得更加谨慎。我认为年轻时的我会非常乐观，并说，为什么我不买四台机器呢？
我去当地的电脑中心，买四台机器。所以我需要从某个地方找到1万到2万美元。也许我会从我的朋友那里贷款什么的。我去买那些机器，然后我把它们放在电力持续且有效且网络足够好的地方。所以我需要找到它。我只是在那里部署这些服务。就像你不会开始……
能够瞄准1000万美元。你首先要能够瞄准10万美元，然后从10万美元开始，你做出足够的努力来瞄准100万美元，依此类推。所以我认为你真的需要跳出框框思考，并且能够胜任其他人不胜任的事情。所以如果你只是在公共云上构建，那么你就不会让自己与众不同。这将非常困难
如果你只是托管Valky，实际上要构建一个差异化的服务。所以我不知道有什么公式。只是，你知道，这就是你跳出框框思考的方式。但这就是我认为在这里很重要的事情。我想补充的一点是，如果你要使用公共云，就要按照它的预期方式使用公共云，弹性地使用。如果你要把它当作一个愚蠢的数据中心来对待，你将花费比你一生中想象的还要多的钱。
你不必一定从一开始就设计成谷歌的规模，说我需要立即转向AWS。在你创业时使用DigitalOcean绝对没有错。也许当你达到1亿收入时，这对你来说就不够用了，对吧？也许那时你必须转向AWS或建立自己的数据中心或其他什么。但我仍然不明白为什么初创公司仍然……
害怕使用除大型超大规模提供商以外的任何东西？是的，这是一个很好的问题。首先，我真的很喜欢这个想法，你不应该为未来的问题进行优化。你应该为今天遇到的问题进行优化。然后大多数初创公司都失败了。所以你今天只需要做得足够好，这样你才能活到明天遇到问题。
DigitalOcean的问题，以及像DigitalOcean这样的几个提供商。Hetzner在Twitter领域出现得相当多，OVH也出现得相当多。这是一个很好的问题。我认为人们依赖一定程度的部落信任。比如，其他人都在用什么？好吧，他们正在使用超大规模提供商。所以我也应该使用超大规模提供商。那么如何摆脱这种困境呢？我认为这有点跳出框框思考。
也许这些提供商可以做更多的事情来建立信心。
这里还有一个经济方面。比如，我认为超大规模提供商在这一点上非常聪明，而且，你知道，我们也从中受益。所以我不会反对这些计划，但它们会激励初创公司，对吧？从经济上使用他们的产品。这创造了一种护城河，因为在你投资于特定的架构之后，并根据你的观点，你应该按照云的预期方式使用云，你
例如，如果你正在使用Lambda，现在突然用完了积分，退出是一个相当大的项目。而且很可能，你只会继续使用它。现在你是一个AWS客户了。
所以我认为，为初创公司找到合适的经济激励措施很重要，因为初创公司通常只是为了生存，你只想依赖那些随着时间的推移会变得越来越大的公司。所以围绕这一点进行一些尝试可能对这些其他提供商很重要。这就是我觉得Kubernetes被低估的地方，对吧？确实存在这样的恐惧，嘿，如果我在AWS Lambda中做我的事情，
我将永远与它绑定在一起吗？或者如果我去DigitalOcean并开始启动我的虚拟机，那会在其他任何地方工作吗？但是Kubernetes是那个规范器，对吧？需要一些时间才能习惯它。这是真的。但是如果你谈论的是一个普通的应用程序，我不是在谈论你所说的那些要求，但是我有一个杀手级应用程序的杀手级想法。我在DigitalOcean或Kubernetes中的任何地方运行它。
如果你将其移动到EKS或GKE或其他任何地方，相同的应用程序几乎也能工作。现在，再说一次，我指的是一个普通的应用程序，没有特殊的要求。你不会对自定义的东西感到疯狂。它工作方式相同。我的意思是，它并不相同，但足够接近。
所以这是一个我不太熟悉的领域，但我看到了一些尝试，试图为更多无服务器空间提供一个与供应商无关的解决方案。所以Knative就是一个解决方案。我认为这很难。我认为仅仅拥有它，而没有超大规模提供商或提供商的支持来使其真正有效，激励就少了。我认为你一开始就说这些事情有很多相似之处。这让我回到了……
很久以前，实际上一些听众甚至可能不知道这一点，但是移动运营商在数据成为主要数据时向数据迁移的过程中遇到了困难，因为它们变得更加同质化了，对吧？他们提供的服务是数据。因此，任何附加服务现在都通过数据提供。因此，你可以轻松地在不同的服务之间移动。
移动提供商的成本非常低。这对消费者来说很棒。太棒了。就像你可以选择接收效果最好、价格最好的一个一样。但对于运营商来说，情况并非如此，因为他们获利的机会更少了。我认为这是这些提供商所做的舞蹈，他们确实想要依赖
拥有与供应商无关的解决方案，因为他们也希望能够吸引客户。所以我们已经开箱即用地支持你正在做的事情。这很棒。就像我们运行Kubernetes一样。你使用Kubernetes，我们使用Kubernetes。我们说的是同一种语言。但随着时间的推移，仅仅不从成本角度陷入价格战总是有点困难。
因为这对在提供商上构建的公司来说很棒，成本只是下降了。但这对于提供商来说并不理想，因为他们无法为自己的研究和开发新功能提供资金，因为你不断面临降低价格的压力。对此我没有解决方案。我所看待的方式是，你应该找到某种难以复制的独特价值，但这在这些方面确实存在一种张力。
我的好朋友在一些这样的中等规模提供商工作，他们不会称自己为超大规模提供商。我认为他们提供非常高质量的产品，这对大多数初创公司来说都非常棒。而且100%，如果你有一个初创公司，你应该使用它们，因为你可能也会与工程团队建立更紧密的联系。如果你最终遇到问题，因为它们规模较小，它们将能够更好地支持你，而且你将获得更好的价格。
所以我们已经讨论过了。Hugo是Namespace Labs的首席执行官兼创始人。
但我们还没有告诉你Namespace Labs是做什么的，Hugo，你能不能快速地给我们一个电梯演讲？我们是一家开发人员基础设施公司，我们与开发人员团队合作以加快他们的开发工作流程。我们今天关注的是提供极其高性能的构建和测试基础设施，所以使用我们之前讨论过的一些内容，没有人喜欢等待他们的构建，没有人喜欢等待他们的测试
因此，我们提供现成的计算，无论你是否自己动手，或者是否使用一些超大规模提供商来为你运行这些工作负载，它都更快。然后，我们添加了一些我们独特的特殊方法，围绕着尽可能地使工作负载增量化，以使其具有极高的性能。但同样，只是通过加快他们的工作流程来改善开发人员的生活。这就是我们的目标。
因此，Hugo的所有联系信息都将在剧集说明中列出，Namespace Labs可以在namespace.so找到。Hugo，感谢你今天与我们在一起。非常感谢你邀请我。我们希望本集对您有所帮助。如果您想讨论或提问，请联系我们。我们的联系信息和Slack工作区的链接位于devopsparadox.com/contact。
如果您通过Apple Podcasts订阅，请务必在那里留下评论，这有助于其他人发现此播客。立即在DevOpsParadox.com注册，以便在我们发布最新剧集时收到电子邮件。感谢收听DevOps Paradox。♪