我就直说了：如果仔细研究与 Kubernetes 相关的总体拥有成本 (TCO)，更传统的开发方法仍然具有令人信服的优势。在又一次 KubeCon 即将结束之际，也许是时候深入探讨一下这个问题了。
这是一个罕见的立场。自从多年前容器和 Kubernetes 首次出现在云计算领域以来，我就一直在使用它们。我使用这项技术在公共云上设计并构建了大量可扩展的系统，因此我知道它行之有效，而且效果很好。我想说的是，它经常被过度应用。系统构建者的动力来自于时下最酷的孩子们在做什么，而不是找到能带来最大商业价值的解决方案。
因此，我敢肯定，由于这些架构错误的继续存在，数百万美元被浪费掉了。是时候让我们做得更好了。也许您也同意。
需要考虑的问题
在我们进行分析的过程中，你会发现其中有些内容可能适用于你和你的组织，也可能不适用。对很多人来说，说 “看情况 “似乎是一种逃避，但这通常是正确的答案。无论是迁移到云还是构建全新系统，您都必须评估每种工作负载和数据集。您需要做好准备，使用最佳技术解决方案来满足您的系统需求。很抱歉要告诉您一个坏消息。
Kubernetes 带来的复杂程度是传统开发工具无法比拟的。管理 Kubernetes 集群需要深入了解其架构和组件，从网络到存储再到安全。这种复杂性要求技术熟练的人员有能力管理和优化 Kubernetes 环境。
相比之下，传统的开发方法和工具通常依赖于更简单的架构，大多数企业已经具备了相应的管理技能。当然，每个公司的情况会有很大不同，但获得 Kubernetes 技能或培训现有员工的成本通常要比使用该技术带来的好处高得多。
尽管 Kubernetes 承诺通过高效的容器编排降低基础设施成本，但 Kubernetes 集群需要大量的开销。这包括组成集群的节点和管理故障转移所需的资源。此外，如果你有管理冗余和可扩展性的基础设施，也会有所帮助；你需要支付的资源可能远远超出需要。
传统的开发方法可能会使用更多的单体架构。灵活性较低可能会降低初始资本支出和持续成本。我有一个项目使用两种方法构建了相同的系统；传统的单体架构基础设施成本是 Kubernetes 部署成本的三分之一–仅就该特定系统而言。当然，除了在简历上看起来不错之外，使用 Kubernetes 可能还有其他原因。
维护 Kubernetes 环境在操作上非常复杂。需要持续监控、调整和更新，以确保环境安全、高效和可靠。同样，这种持续的维护需要熟练的员工和现代化的工具，这都会导致总体拥有成本上升，在某些情况下甚至会翻倍。
尽管 Kubernetes 可以自动化和简化部署流程，但初始设置和配置可能既耗时又复杂。这可能会延迟许多系统的部署时间和上市时间，使您面临更多潜在错误。传统的开发和部署方法可能需要更多的容器自动化和可扩展性优势。但是，对于某些应用而言，它们往往更简单、部署更快。
这些系统的分布式性质带来了新的风险和故障点。Kubernetes 和基于容器的部署具有很高的可扩展性和容错水平，这也是我们使用它们的原因，但它们确实存在传统开发中看不到的问题。这些问题包括从 “容器蔓延 “到容器生态系统中的安全漏洞，以及需要更新技能才能正确运行的新工具。我发现，故障并不在于何时发生，而在于发生多少次。Kubernetes 部署的故障总是更多。
传统架构提供的可扩展性选项可能较少，但可以提供更易于安全和管理的封闭环境。这意味着成本更低，但功能也更少。有时，这种权衡具有良好的商业意义。
总体拥有成本分析的重要性
尽管 Kubernetes 和容器在可扩展性、效率和资源利用率方面具有显著优势，但它们的总体拥有成本（TCO）有时也会失衡。当然，我发现总体拥有成本分析经常被忽视；那些选择该技术的人并不能很好地把握所做的权衡。我通常会问使用更传统的方法会有什么得失，但得到的往往是茫然的目光和不置可否的回答，这说明没有进行总体拥有成本分析。另一方面，我也经常被问到是否会去 KubeCon，这也是原因之一。
管理 Kubernetes 环境的复杂性和成本凸显了传统开发和部署方法仍然具有价值。事实上，如果你是一家 IT 资源有限的企业，你确实需要关注总体拥有成本。
花在基于 Kubernetes 的系统上的钱会占用其他更迫切需求的资源。我不知道哪家 IT 企业有无限的预算来尝试所有新技术。您需要谨慎选择您的战斗。
本文文字及图片出自 Is Kubernetes worth it?
你的反应是：