现代应用程序架构:简约之道

闪亮的新云原生对象会吸引你的眼球,但很多时候,经过验证的、枯燥的解决方案才是更好的选择。

译自 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 日在美国犹他州盐湖城举行。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注