没有 Kubernetes 的云原生

没有 Kubernetes 的云原生

托管服务允许开发人员专注于应用程序，将基础设施、扩展和服务器管理交由云提供商负责。

本文来自基础设施服务商 nitric ，可能不够中立，但是其思路还是值得一看。译自 Achieve Cloud Native without Kubernetes 。

图片来自 Shutterstock 的 Peshkova

这是一个两部分系列的第二部分。

在本质上，云原生是充分利用云计算模型的好处。这意味着构建和运行能够充分利用基于云的基础设施的应用程序。始终处于前沿的基本原则包括：

• 可伸缩性 — 根据需求动态调整资源。
• 弹性 — 以故障为前提设计系统，以确保高可用性。
• 灵活性 — 解耦服务并使它们互操作。
• 可移植性 — 确保应用程序可以在任何云提供商甚至本地运行。

在第 1 部分中，我们强调了学习曲线以及直接使用 Kubernetes 可能不是最佳选择的情况。本部分专注于使用托管服务构建可伸缩的云原生应用程序。

托管服务：通向云的电梯

达到云可能感觉像是使用 Kubernetes 等工具逐步构建梯子的过程。但如果我们可以简单地按下按钮并平稳地乘坐电梯上升呢？这就是托管服务发挥作用的地方，它们充当我们通向云的电梯。虽然不深入研究具体的提供情况可能不太明显，但托管服务通常在幕后使用 Kubernetes 来构建可伸缩的应用程序平台。

在涉及基础设施（以及总体软件）时，控制和复杂性之间存在明确的联系。我们可以通过将一些控制权委托给 AWS、Azure 或 Google Clou d等云提供商的托管服务来开始降低复杂性。

托管服务使开发人员能够专注于应用程序，将基础设施、扩展和服务器管理的问题交给云提供商的有能之手。这种方法的核心优势在于消除了服务器管理，并让云提供商处理动态扩展。

把托管服务看作是您 IT 部门的延伸，承担着确保基础设施健康、稳定性和可伸缩性的责任。

选择您的提供商

在设计云原生应用程序时，主要关注的应该是能够提供灵活性、弹性和可伸缩性的架构原则、模式和实践。与其立即选择特定的云提供商，对于团队来说，开始开发而不受这个决策的限制要更有价值。

幸运的是，云的竞争性质已经推动云提供商朝着功能平等的方向发展。基本上，它们已经建立了基础性的构建模块，这些模块在很大程度上互相借鉴，最终为最终用户提供了相同或极其相似的功能和价值。

这为抽象层和框架（如Nitric）铺平了道路，可以利用这些相似之处，为应用程序开发人员提供更大的灵活性，以提供云开发模式。真正的价值在于能够在工程团队的时间表上就技术（如云提供商）做出决策，而不是将其作为开发的阻碍。

默认扩展的资源

应用程序的资源选择决定了它们的增长轨迹；它们塑造了应用程序建立的基础，影响其可伸缩性、安全性、灵活性和整体效率。让我们对一些对构建强大和安全的应用程序起作用的基本组件进行分类和审查。

执行、处理和互动

• Handlers：用于执行代码或处理事件的入口点。它们定义了在发生特定事件或触发器时执行的逻辑和操作。
• API gateway：充当管理和路由请求到各种服务的单一入口点。它提供了诸如速率限制、身份验证、日志记录和缓存等功能，为您的后端服务或微服务提供了统一的接口。
• Schedules：允许在预定时间或间隔内执行任务或操作。对于自动化重复或基于时间的工作负载（如数据备份或批处理处理）至关重要。

通信和事件管理

• Events：在事件驱动架构中至关重要，它们代表可以启动操作或工作流的事件或更改。它们促进了系统或组件之间的异步通信。
• Queues：在组件之间提供可靠的基于消息的通信，增强了容错性、可伸缩性和解耦的异步通信。

数据管理和存储

• Collections：数据结构，如数组、列表或集合，用于存储和组织相关的数据元素。它们通过促进高效的数据存储、检索和操作来支持许多应用程序场景。
• Buckets：对象存储系统中的容器，如 Amazon S3 或 Google Cloud Storage。它们为各种非结构化数据类型提供可伸缩和可靠的存储，从媒体文件到文档。

安全和机密性

• Secrets：用于安全存储诸如 API 密钥或密码等敏感数据。使用集中式的秘密管理系统确保这些关键信息受到保护，并且只能被需要的人访问。

自动化部署

传统的云提供商提供了 CI/CD 服务，但通常无法提供真正无缝的体验。像 AWS CodePipeline 或 Azure DevOps 这样的服务需要复杂的设置和维护。

为什么这是个问题？

1. 耗时：设置和管理这些流水线会占用宝贵的开发时间，这些时间本可以更好地用于功能开发。
2. 复杂性：每个云提供商的CI/CD解决方案可能都有其特点和学习曲线，这使得团队更难以切换或维护多云策略。
3. 容易出错：手动步骤或配置错误可能导致部署失败，甚至更糟糕的是停机。

您可能会注意到这里与采用 K8s 时面临的一些挑战有一些相似之处，尽管规模较小。然而，有一些选项可以大大简化部署过程，例如使用自动化部署引擎。

示例：简化的流程

这是 Nitric 采取的简化部署流程：

1. 开发人员将代码推送到存储库。
2. Nitric 的引擎检测到更改，构建所需的基础设施规范，并确定所需的最低权限、策略和资源。
3. 为应用程序自动提供所需的整个基础设施，无需开发人员明确定义它，也无需独立的基础设施即代码（IaC）项目。

基本上，部署引擎会智能地推断并设置应用程序所需的基础设施，以确保为最大安全性配置了角色和策略，并降低了权限。

这种简化的流程解除了应用程序和运营团队的以下活动的负担：

• 需要将镜像容器化。
• 制作、排查和维护像 Terraform 这样的 IaC 工具。
• 解决应用程序需求与现有基础设施之间的不一致。
• 启动用于原型或测试阶段的临时服务器。

总结

使用托管服务可以简化与基础设施相关的复杂性，使组织能够将主要重点放在其主要目标上：应用程序开发和业务扩展。与直接使用 K8s 相比，作为 IT 部门的一部分的托管服务为云的平稳过渡提供了更加流畅和更有信心的方式。它们是云原生开发的绝佳选择，以增强数字增长和稳定性。

借助像 Nitric 这样简化部署流程并在不同的云提供商之间提供灵活性的工具，向无 Kubernetes 的云原生环境迈进似乎不仅仅是可行的，而且令人信服。如果您正在努力构建云原生应用程序或多应用程序的平台，我们很愿意听到您的意见。

阅读本系列的第 1 部分：“Kubernetes 并不总是正确的选择”。