闪亮的新云原生对象会吸引你的眼球，但很多时候，经过验证的、枯燥的解决方案才是更好的选择。
译自Architecting the Modern App: A Case for Simplicity，作者 Patrick Wolthausen。
复杂性。避免复杂性是许多人被Kubernetes和云原生计算基金会 (CNCF) 生态系统吸引的原因之一。毕竟，谁不喜欢尝试最新的工具，并找到新的、创造性的方法来克服技术限制呢？作为技术人员，当新的挑战出现时，我们会积极应对。
也就是说，这是 2024 年 CNCF 项目的现状：
这里有很多事情正在发生。对于我们在使用云原生技术时遇到的几乎所有问题，都会启动一个项目——通常不止一个——来解决它。但是，这种不断扩展的格局（以及我们对最新技术的热爱）是否会导致我们采用过于复杂的解决方案？
也许吧。大量的解决方案很有吸引力，我们很容易陷入想要集成比实际需要的更多云原生产品的陷阱。
让我告诉你一个可能非常熟悉的例子。
过于复杂的客户用例
我们的旅程从一个简单的 Web 应用程序开始，它在一个带有NoSQL数据库后端的 Kubernetes 集群中运行。
数据库将需要一些存储来存放有状态数据，因此我们需要找到一个云原生存储解决方案。我们还需要添加一个消息队列来提高性能。
我们还应该添加一些东西来处理应用程序的身份和访问管理 (IAM)、密钥和安全。开发团队刚刚建议我们需要一个关系型数据库。
随着所有这些有状态应用程序在集群中运行，我们需要包含一个用于备份和灾难恢复的工具。
我们还将包含Argo，这样我们就可以轻松地推出所有用于不同组件的 Helm 图表，并将它们部署到任何我们想要的地方。
你明白我要说什么了吧。所有这些组件都被添加到解决方案中，其中许多是仍在开发中的新工具和项目。这意味着现在需要更多的时间来学习——以及将来更多的技术债务。
但这还没有结束
随着业务不断扩展，新的需求浮出水面——例如 15 分钟的服务级别协议 (SLA) 用于恢复和区域故障转移。由于某些应用程序的限制，应用程序不支持跨数据中心的热/热设置。
Kasten 涵盖了大多数组件，但即使丢失五分钟的 Kafka 或 Cassandra 数据也会对应用程序造成严重问题。当恢复到另一个数据中心时，可能会出现其他与 IP 地址冲突的问题（由于我们数据中心中的一些网络限制）。
因此，我们现在正在探索甚至更新的项目或工具，这些项目或工具完全位于 CNCF 之外，可能能够解决这些新的挑战。由于测试新工具，这会导致重大延迟，而由于文档和支持有限，测试时间更长。这增加了更多故障点、调试不熟悉的系统和风险依赖关系。所有这些都分散了我们对核心业务目标的注意力，并导致项目交付延迟。
乏味的替代方案
这些问题对云原生工具来说并不新鲜（好吧，有些可能是，但那是另一篇文章的内容）。多年来，我们在构建应用程序时遇到了许多这样的挑战，这也意味着许多这样的挑战已经得到解决。它们可能是乏味的解决方案，但它们稳定且众所周知，因此会产生更少的技术债务。
或者正如Dan McKinley（优秀选择乏味技术演讲的创建者）所说：“与刚发布的软件相比，存在时间更长的软件往往需要更少的维护。”
乏味和有趣可以共存！
与其承担所有新的挑战并从头开始重建一切，不如利用乏味的工具，并在最需要的地方探索闪亮的新技术。如果有一个简单、乏味的解决方案可用，请使用它。
选择更简单解决方案的一个很好的例子是，如果您计划在云中部署，或者您有一个专门的数据库团队，他们已经准备好部署自动化和解决方案，那么可以利用数据库的软件即服务 (SaaS) 解决方案。
以下是它的运作方式：
将状态从集群移出并转移到更传统的主机上效果很好，因为它将自动化从类似 Argo 的东西转移到类似 Jenkins 和 Ansible 的东西——您可能已经在使用它们了。
无论基础设施是在数据中心还是云中，都可能已经存在用于备份和恢复有状态数据的解决方案。为了冗余和灾难恢复，大多数数据库可以轻松地配置跨多个数据中心的复制。
这样做消除了对云原生存储解决方案和备份这些存储的工具的需求。我们还用更简单的工具（例如 Envoy，一种可以作为应用程序的 sidecar 部署的轻量级代理）替换了全面的服务网格，以满足我们的 mTLS 需求，而不是像 Istio 这样的全面的服务网格，它带来了比实际需要的更多复杂性、开销和功能。
总的来说，这减少了技术债务，提供了更高的稳定性，并简化了支持团队的过渡，因为许多解决方案要么是熟悉的，要么是组织范围内使用的集中式解决方案（例如共享的 Vault）。
我们剩下的集群基本上是无状态的。这使我们能够轻松地部署到任何地方，并充分利用 Kubernetes 集群的优势，以及开发人员和运营人员将完全熟悉的经过良好验证的技术栈。
简化一步一步来
就像一般的云采用或我们使用的任何其他工具一样，重要的是要记住，在每个决策点使用合适的工具来解决合适的问题。有时，使用成熟的非云原生工具并将其与我们的云原生解决方案一起使用，会更容易、更可靠。
尝试所有这些新玩具可能很有趣，但总有一个团队在发布后要支持解决方案，而运维团队最喜欢的莫过于简单可靠的解决方案。
确保您考虑将新的技术选择引入您的堆栈所带来的额外成本（时间、资源、认知负荷）。将所有受影响的团队纳入任何讨论，以充分了解这些选择的成果，并考虑长期支持将是什么样子。
通常情况下，保持简单更好——或者正如比我聪明得多的人所说：
“完美不是在没有更多东西可以添加的时候实现的，而是在没有更多东西可以拿走的时候实现的。” —— Antoine de Saint-Exupéry
您是否经历过过度复杂的云原生架构的陷阱？我们很乐意听取您关于简化 Kubernetes 部署的故事。在 11 月 12 日至 15 日于盐湖城举行的KubeCon + CloudNativeCon 北美大会上，请到 Q32 展位与 Aptum 聊聊保持简单的益处——以及我们如何在自己的项目中解决复杂性！
要了解更多关于 Kubernetes 和云原生生态系统的信息，请加入我们参加KubeCon + CloudNativeCon 北美，该活动将于 2024 年 11 月 12 日至 15 日在美国犹他州盐湖城举行。
