平台工程通过标准化创新，降低认知负荷，赋能开发者。它整合网络、存储、可观测性等要素，并随组织扩展引入GitOps、策略管理等高级组件。自建平台始于开源工具，逐步转向购买，以应对复杂性。AI时代，平台工程连接软件工程师和数据科学家，促进AI应用。
译自：Kubernetes Isn't Enough for a Production-Ready Platform
作者：Jennifer Riggins
Kubernetes 是云原生架构的基石，但这个容器编排器并不是支撑企业堆栈的唯一要素。
从一开始，任何可用于生产的云原生平台工程战略都需要网络、存储和可观测性。但随后，第 2 天的维护和可扩展性问题开始出现，这些问题通过寻找和使用更多工具来“解决”。这带来了更多的 Kubernetes 复杂性，尤其是在添加 GitOps、策略管理和服务网格等功能时。最终，组织必须调整他们通常是临时的平台战略，以寻求更好的解决方案。
无论您在内部开发者平台 (IDP) 之旅中处于哪个阶段 — 无论您是构建还是购买了它 — 您都需要安全性、基于角色的访问控制 (RBAC) 和在现代技术堆栈的许多层中保持一致的可观测性。
以下是您需要的考虑因素 — 除了 Kubernetes 之外 — 适用于 平台工程战略，该战略可在提高速度的同时降低开发人员的认知负荷。希望它也能减轻您平台工程师的负担。
DevOps 的消亡和平台工程的兴起
Nutanix 的 Jose Gomez 告诉我：“平台工程并不是什么新鲜事物。这是组织多年来一直在做的事情，由一个特定的团队控制。” 新技术，特别是容器，促使人们回归到“横向团队的想法，但这一次，我们不会减慢开发人员的速度”，他说。
根据 Team Topologies，平台工程是一个团队或一组团队，专注于创建和维护一个或一组平台，使包括软件工程师在内的其他团队能够更有效地构建和部署软件。
根据 Gomez 20 年的平台工程经验，他表示，今天的主要区别在于包装。通过从虚拟机 (VM) 转向容器，IDP 成为速度和可移植性的推动者，而不仅仅是应用程序团队需要跨越的另一个障碍。
平台工程的受欢迎程度部分原因是，在现代堆栈的复杂性面前，“你构建它，你运行它”的 DevOps 原则变得难以克服。DevOps 驱动的所有权通常要求应用程序开发团队了解五层、六层甚至七层堆栈。这些应用程序团队 — 通常是由五到九名成员组成 Scrum 团队 — 必须同时管理开发和运营，这会带来巨大的成本，并且通常会产生大量重复工作。每个团队都需要自己的 DevOps 工程师才能投入生产。而且，仍然有太多的其他团队 — 质量保证 (QA)、安全、网络 — 参与其中。这不仅进一步减慢了生产路径，而且还可能引入安全性和可靠性风险，从而增加停机时间和漏洞。
DevOps 的运营工作太多了，因此开发人员感到被抛弃了。应用程序团队应该专注于为最终用户带来价值 — 而不是寻找创新的生产途径。
Gomez 说，DevOps 认为“过多的成本用于运营，知识重复”，而不是像平台工程模型那样，“由一个团队共享所有这些知识并在工具方面保持一致”。他认为，需要学习的工具越少，“转化为更低的风险和认知负荷”。
黄金路径简化、标准化创新
他继续说道，平台工程团队将网络、后端自动化、运营系统和安全团队聚集在一起，以制定需要遵循的护栏和轨道。
换句话说，平台工程团队创建了一条 通往生产的黄金路径，作为完成重复性任务的最简单方法。Gomez 解释说，这条路径建立了投入生产的策略 — 但并没有关闭创新之路。
Gomez 说：“这意味着，如果你想投入生产，我们不会减慢你的速度，但你需要遵循这些标准”并使用指定的工具。
IDP 还可以通过创建一个沙箱来支持创新，应用程序团队和数据科学家可以在其中安全地进行创新。然后，平台团队可以验证新的用例，并且一旦确定了概念验证的价值，就可以使该新功能或开发工具做好企业就绪的准备，将其添加到黄金路径并提供培训以鼓励采用。
开源并非免费
开源软件 (OSS) 非常受欢迎，因为它价格合理、易于定制和扩展。开发人员喜欢它带来的自主性。
但是，仅仅因为 OSS 可能没有许可成本并不意味着它是免费的。正是因为没有直接成本，团队才会觉得更有能力采用 OSS，从而导致工具蔓延和可维护性成本。
仅在 云原生计算基金会 (CNCF) Landscape 中就有 230 多个开源选项，工程团队面临着决策过载的问题 — 更不用说 DevOps 倦怠，不得不更新、修补和维护他们的选择。
也许最重要的是，由于 OSS 通常是影子 IT 的一部分，组织不知道正在使用什么或正在暴露什么数据，因此安全漏洞经常被忽视。修复开源漏洞的平均时间现在是 400 天。
平台工程的兴起是为了帮助控制开源的蔓延，以及集中管理更新。
随着组织扩展其平台工程计划并进入第 2 天的运营，有主张的开发者平台可以通过维护软件物料清单 (SBOM) 来帮助提高开源供应链的可见性。专有平台还可以扫描镜像以查找补丁，然后自动修补库、依赖项和其他漏洞。这减轻了各个团队维护软件的负担，同时也确保没有准备被利用的安全漏洞。
从构建开始，通过购买成长
组织通常从使用开源工具构建自己的平台开始。Gomez 说，手动并非 IDP 的一个糟糕的起点。早期的平台工程战略通常是零敲碎打地构建平台，通常是利用开源项目，这并不罕见。而且，尽管在 IDP 供应商工作，但 Gomez 并不急于告诉每个人立即购买。相反，他看到了早期自己动手做的价值。
Kubernetes 专家 Kelsey Hightower 将此称为 “Kubernetes the hard way”。他说，它是“针对学习进行了优化，这意味着采取漫长的路线，以确保您了解引导 Kubernetes 集群所需的每项任务。” 这甚至可能不是一个可用于生产的途径，而是让平台工程师快速掌握 Kubernetes 的一种好方法。
在某些时候，您的 IDP 可能会发展到包括 20 多个开源工具，每次发生更新时都必须对其进行测试、验证和部署。但是，平台工程团队并非旨在随着 IDP 采用率的提高而扩展，更不用说相互竞争的利益相关者和需求了。
您从开发人员那里获得的认知负荷最终会落在您的平台工程师的肩上。Gomez 观察到：“您有一个非常昂贵的团队，因为这些人技术精湛、知识渊博”，您可能不希望他们“将时间花在测试和验证上，而不是从沙箱中获取开发人员的实验并准备好在黄金路径上增加额外的价值。”
最终，平台团队不堪重负，试图平衡维护和新功能。在此过渡期间，您很可能会走出“构建自己的平台”阶段，并演变为“购买有主张的平台”阶段，该平台包括一流或最常用的开源项目，并为您处理更新。
像 Nutanix Kubernetes Platform (NKP) 这样有主张的 Kubernetes 平台充当集中式控制平面，以管理您的环境、创建和升级集群以及部署应用程序。此策略不仅可以更好地管理容器集群和提高容器之间的一致性，还可以提高效率、速度和可重用性。这种单一的视角还可以在集群扩展到 5 到 10 个或更多时实现策略管理和可观测性。
企业级 IDP 的组成部分
Kubernetes 无法独立存在。根据您的工程组织的规模，需要将其他部分构建到您的 IDP 中。
一个可用于生产的云原生平台从一开始就需要以下组件：
- 具有 L4 和 L7 负载平衡和网络策略支持的网络。
- 存储，因为越来越多的容器化应用程序需要持久存储。
- 可观测性，包括指标、日志记录和跟踪。
- 用于私有托管容器镜像的容器注册表。
- 在所有层强制执行的 安全 性，具有不可变的操作系统和自加密磁盘。
- 微服务之间的 HTTPS 证书和 RBAC。
这是 在生产环境中运行 Kubernetes 的最低要求，但随着云原生组织的增长，它们的需求也在增长。第 2 天需要您使用更多节点来扩展集群，因此您很快就需要：
- 多集群编排
- 一致性和标准化
- 安全性和合规性
- 运营效率
支持这种规模很快就需要更高级的组件，例如：
- 具有更改历史记录、审批和回滚的 GitOps
- 策略管理
- 服务网格
- 成本管理
- 集群管理
Gomez 建议，服务网格 很复杂，因此等到您必须管理和保护分布式应用程序中微服务之间的通信时再添加它。服务网格是一个专用的基础设施层，具有流量管理、可观测性和安全性等功能。集成服务网格的平台使平台和应用程序团队都可以看到应用程序的哪个部分正在经历哪个负载。
成本可见性或 FinOps 是云原生组织仍在努力解决的另一个领域，因为它们通常会过度配置资源以确保可扩展性。平台主导的集群管理可以为资源重新分配提供建议（甚至可以自动执行），这对于预算和环境都有好处。
为了简化设置和管理，您可能希望选择像 NKP 这样的平台，该平台包括交付可扩展生产堆栈所需的组件，这些组件构建在开放标准之上，因此开发人员可以使用他们首选的工具链，而平台工程师可以随着时间的推移调整他们的环境。
平台上的 AI 沙箱
平台工程已经从炒作发展到广泛采用，部分原因是它是一种弥合业务和工程之间差距的方式。现在，在 人工智能时代，平台工程团队可以将软件工程师和数据科学家更紧密地联系起来。
例如，Gomez 说，平台工程可以更好地满足数据科学家对计算的需求，因为它建立在自动化和基础设施即代码 (IaC) 的基础上。这使平台团队可以通过 Kubernetes 为数据科学家配备虚拟机，Kubernetes 成为一种编排数据科学作业的方式，自动在具有 GPU 的基础设施节点上进行调度。这种途径使数据科学家能够更有效地共享资源，而不是在单个计算机上运行进程并在需要扩展时发出请求。
Gomez 问道：“与其以孤立的方式使用 PC，为什么不创建一个包含 GPU 的服务器池并在其上运行 Kubernetes 呢？借助此节点池，Kubernetes 可以调度来自数据科学家的 AI 作业，从而更好地利用您对 GPU 能力的投资。”
此外，开发和数据科学用例中的许多入职、RBAC 和安全性都是相同的，那么为什么不在单个平台中管理它呢？然后，当模型准备好投入生产时，可以通过相同的黄金路径进行部署。
另一方面，开发人员希望在整个软件开发生命周期中探索和使用 AI，以促进智能运营。平台工程师可以利用 AI 用例来分析代码的质量，并比较开发人员编写的代码与 AI 生成的代码。或者，他们可以使用 AI 来提取数据并围绕 Jira 工单做出预测。
同样，平台促进了沙箱式的创新，以后可以将其转化为应用用例。
最后，由于所有软件开发 AI 用例都隐藏在 IDP 中，因此 衡量 AI 投资的回报 变得更加容易，Gomez 强调说，许多组织忘记了这样做。
底线：赋能开发人员
虽然大多数开发人员并不希望构建平台，但他们确实希望平台能够带来优势。他们也想要 Kubernetes，但他们希望它在幕后运行，这样他们就不必担心它了。
Gomez 最终得出结论，平台工程的成功归结于“你在多大程度上接受技术并调整由该技术支持的流程”。
