当仔细观察与Kubernetes相关的总拥有成本（TCO）时，更传统的开发方法仍然具有令人信服的优势。当我们结束另一个KubeCon时，也许是时候深入研究这个问题了。

　　这是一个罕见的立场。自从容器和Kubernetes多年前首次出现在云计算场景中以来，我就一直在使用它们。我使用这项技术在公共云上设计和构建了许多可扩展的系统，所以我知道它有效，而且运行良好。我的观点是，它经常被过度应用。系统建设者的动机是这些天很酷的孩子在做什么，而不是找到回报最大商业价值的解决方案。

　　因此，我相信随着这些建筑错误的继续下去，数百万美元被浪费了。是时候让我们做得更好了。也许你同意。

　　考虑什么

　　当我们进行这项分析时，您会发现其中一些可能适用于也可能不适用于您和您的组织。对许多人来说，说“这取决于”似乎是逃避，但这通常是正确的答案。无论您是迁移到云还是构建网络新系统，您都必须评估每个工作负载和数据集。您需要准备好使用最好的技术解决方案来满足您的系统需求。很抱歉成为坏消息的传播者。

　　Kubernetes引入了更传统开发工具所没有的复杂程度。管理Kubernetes集群需要深入了解其架构和组件，从网络到存储再到安全。这种复杂性需要能够管理和优化Kubernetes环境的熟练人员。

　　相比之下，传统的开发方法和工具通常依赖于更直接的架构，这些架构可以使用大多数企业已经拥有的技能组合进行管理。当然，这因公司而异，但获得Kubernetes技能或培训现有员工的成本通常比使用这项技术的任何好处都要高得多。

　　Kubernetes集群需要大量的开销，尽管Kubernetes承诺通过高效的容器编排来降低基础设施成本。这包括组成集群的节点和管理故障转移所需的资源。此外，如果您有基础设施来管理冗余和可扩展性，那将有所帮助；您需要支付的资源可能比需要的要多得多。

　　传统的开发方法可能会利用更多的整体架构。灵活性降低可能会导致初始资本支出和持续成本降低。我有一个项目使用这两种方法构建相同的系统；传统的单片架构基础设施成本是Kubernetes部署的三分之一——仅适用于该特定系统。当然，除了它在简历上看起来不错之外，还有其他原因可以使用Kubernetes。

　　维护Kubernetes环境在操作上很复杂。需要持续监控、调优和更新，以确保环境安全、高效和可靠。同样，这种持续的维护需要熟练的员工和现代工具，既能提高TCO，又在某些情况下，又使其翻一番。

　　初始设置和配置可能既耗时又复杂，即使Kubernetes可以自动化和简化部署流程。这可能会延迟许多系统的部署时间和营销时间，使您更容易出现更多潜在错误。传统的开发和部署方法可能需要更多的容器自动化和可扩展性优势。然而，对于某些应用程序，它们通常更简单、更快地部署。

　　这些系统的分布式性质带来了新的风险和故障点。Kubernetes和基于容器的部署提供了高可扩展性和容错水平，这就是我们使用它们的原因，但它们确实存在我们在传统开发中看不到的问题。这些可以从“容器蔓延”到容器生态系统中的安全漏洞，这些新工具需要更新技能才能正确运行它们。我发现这不是什么时候会发生失败，而是会发生多少次。在Kubernetes部署中，失败总是更多。

　　传统架构可能提供更少的可扩展性选项，但可以提供更易于保护和管理的更封闭的环境。这转化为更少的成本，但也更少的能力。有时，这种权衡具有良好的商业意义。

　　TCO分析的重要性

　　尽管Kubernetes和容器在可扩展性、效率和资源利用率方面具有显著优势，但它们的TCO有时可能不正常。当然，我发现TCO分析经常被忽视；那些选择技术的人对正在进行的权衡没有很好的处理。我通常询问关于使用更传统方法权衡的问题，但最常见的是空白的凝视和无答案，这表明TCO分析没有完成。另一方面，有人问我是否要去KubeCon，所以就是这样。

　　管理Kubernetes环境的复杂性和成本凸显了传统的开发和部署方法仍然具有价值。事实上，如果您是一个IT资源有限的组织，您真的需要关注TCO。

　　花在基于Kubernetes的系统上的钱从其他更紧迫的需求中移除了资源。我不知道有一个IT组织有无限的预算来尝试所有新技术。你需要仔细挑选你的战斗。