与 Tanzu 先锋一起分析“云原生应用程序平台现状”报告。
译自 Is Cloud Native a Vibe? Power Users Weigh In，作者 Rita Manachi; Darin Zook。
自 6 月份发布 2024 年云原生应用平台现状 报告以来，我们一直在收集来自代表 Tanzu 先锋 的架构师、工程师、技术从业人员和 IT 领导者的反馈，这是一个 VMware Tanzu 平台资深用户的社区。这份报告（及其 Kubernetes 现状 前身）每年帮助读者了解同行在做什么、他们面临的最大挑战以及他们如何解决最苛刻的需求。
今年也不例外。组织正在从云原生架构、容器采用和应用平台中看到明显的价值。然而，对一致性的需求 以及对多种应用类型和部署模式的日益增长的需求从未像现在这样大。
考虑到这些因素，我们收集了 Tanzu 先锋对该报告的反馈。
云原生在实践中意味着什么？
今年，调查首次询问成为云原生企业的意义。当被问及“当你想到一个 云原生企业 时，你会想到什么？”时，40% 的受访者包括“这是一种思维方式”。Tanzu 先锋成员的观点与调查受访者的观点相呼应，有些人只是简单地说这与“云无关”有关，比如 CSG International 的高级系统工程师 Todd Kabella。其他人则强调了应用开发和架构的方法。
“对我来说，云原生是一种思维方式和方法论，遵循 12 要素应用方法论。仅仅因为应用程序被容器化并不意味着它是云原生的。同样，仅仅因为应用程序在公有云中运行并不意味着它是云原生的。” — Axians 波兰的解决方案架构师 Pawel Piotrowski
“对我来说，区分云原生企业的关键属性是连续性。这在几个方面体现出来： 持续学习文化：这使员工不仅能够了解现有实践，还能预测未来需求并有效地进行规划。 持续自动化：随着学习的进步，使用基础设施即代码 (IaC) 和数据驱动的方法将手动任务自动化，从而简化交付。 持续实验和创新：学习和自动化的结合为持续实验新技术创造了空间，培养了创新文化。” — Eviden/Atos 的首席架构师 Jaroslaw Gajewski
“云原生不仅仅是一种构建应用程序的方式；它是一种生活方式和一种思维方式。接受这一事实的公司正在按照敏捷原则工作，单个团队负责其产品的整个生命周期，这意味着他们拥有该产品。通常，这类公司具有 **扁平化的层级结构，重视每个员工的个人知识来推动产品发展。当然，这只有在支持这些现代运营模式的技术下才能实现，而这远不止技术本身。” — DATEV 的企业架构师 Jürgen Sußner
应用和部署模式的多样性比比皆是
报告中的另一个惊人发现：许多企业正在使用多个平台来支持不同团队构建和使用的各种应用程序类型和部署模式。这种趋势加剧了与分布式和混合架构相关的复杂性。我们询问了先锋们关于这个问题，发现这确实是一场斗争！
“这对我们来说是真实的！根据特定组织或特定 [业务线] LoB 的应用程序/业务模型，可能需要针对不同应用程序类型采用不同的模式。这与整体基础设施设计相同——没有一种设计适合所有人。” — Pawel Piotrowski
“应用程序组合的现代化是一个持续的过程，从旧的单体应用程序向现代面向服务的架构转变通常很慢，而且只有部分可行。不要强迫所有东西都进入容器并在 Kubernetes 上运行；有些东西，比如大型单体应用程序，根本不适合容器化。需要一个能够支持应用程序组合全方位的平台。” — Maximilian Marshall, Evoila 云原生国际部门负责人“
您将需要不止一条生产路径，尽管可能有一条标准的起始路径或起始点适合 80% 的团队。但有些团队会遇到默认路径无法解决的挑战。这可能意味着更复杂的发布策略或更复杂的技术选择。因此，拥有多个精心策划的路径不是反模式；这是正常的演变。*” — Jürgen Sussner
“虽然这是真的，但我认为有时我们误将缺乏标准化理解为多种模式，这会导致熵的显著增加。” — Jaroslaw Gajewski
平台激增持续存在
我们在这项研究中发现的最令人欣喜的结论之一是，平台工程团队和开发人员 都重视平台选择。然而，随着云原生应用程序平台和模式数量的增加，复杂性也随之增加，对单一平台体验的需求也随之增加——不仅对开发人员而言，而且对平台和 I/O 工程团队 而言，他们负责构建、管理和更新这些平台。这对需要根据季节性市场动态、重大事件和其他无法控制的外部因素进行扩展的组织至关重要。
“我们使用多个平台，但我们尽量将其控制在一定的范围内，并在合理的情况下尽量标准化。激增主要是由多个团队的不同、独特的经验和偏好造成的。” — Pawel Piotrowski
“我们正在尽力统一平台。例如，我们已经合并了许多应用程序，现在正在对 Kubernetes 平台和云实施进行同样的操作。” — Luis Freixas, LFConsulting IT 管理员
“对运行在所有平台上的所有平台和应用程序进行简单管理始终很重要。然而，对单一平台体验的追求不应干扰应用程序本身。在没有云原生应用程序平台的情况下，在可重复性和创新之间取得平衡是十分危险的。报告第 14 页的评论与我产生了共鸣：[‘这可能表明人们希望简化现状，但又不放弃云原生思维方式的标志——灵活性。’” — Christoph Villnow, Unique Projects 技术主管
安全在平台工程中的地位
超过三分之二的调查受访者在高度监管的行业工作，这意味着他们要应对持续的监管障碍和政策。因此，平台工程团队必须与安全团队更紧密地合作，以确保安全、合规性、治理和规模化执行。
虽然安全团队对与平台工程合作仍然持健康的怀疑态度，但要拥抱DevSecOps 模型，这种动态需要改变。合规性、治理和持续安全是平台工程的超级力量，可以改变我们保护应用程序的方式，无论它们运行在哪里，对开发人员体验的影响都很小。
“大多数安全团队缺乏关于容器工作负载以及如何解决它们带来的新挑战的足够知识。此外，基础设施、网络和安全之间的传统划分可能非常成问题，因为这些领域在云原生生态系统中往往相互融合。” — Maximilian Marshall
“云原生安全与传统的企业安全完全不同。传统上，安全是人们在进入生产环境时必须经过的一道门槛。将此应用于云原生会破坏持续交付和改进流程。因此，安全必须成为管道的一部分——不仅仅是左移，而是无处不在。同时，平台工程师需要对整个应用程序环境有整体的可见性，以了解谁受到什么影响以及如何修复它或是否已修复。这就是云原生应用程序保护平台越来越重要的原因。”* — Jürgen Sussner
“我每天都与安全团队合作。我的观察是，安全团队几乎无法跟上当今应用程序平台环境的变化速度。公平地说，技术周期似乎比以往任何时候都快。他们的怀疑是可以理解的，但他们也需要拥抱新的云原生安全思维，而不是应用过时的安全策略，这些策略会阻碍创新和他们的竞争能力。” — Pawel Piotrowski
“中央 IT 在其数十年的历史中，从未达到过普通安全团队的期望。这种不信任通常是双向的，企业内部的治理团队通常被视为快速迭代和创新的障碍。云原生技术在很大程度上仍然被许多企业认为是“未经验证的”，其生态系统通常感觉像“狂野西部”。通常，安全团队落后于这个生态系统，甚至无法了解其业务风险所在。由于对这些未知事物的恐惧，他们甚至可能变得敌对，并在他们认为事情进展过快时阻止计划。但事实是，他们通常确实如此，而且没有足够的保障措施。” — Robert Kloosterhuis，ITQ 云原生平台技术专家
“受过良好教育的安全团队正在与平台团队密切合作，以了解统一平台体验的优势，这种体验可以显着增强他们的安全态势。我们团队中有来自安全部门的代表，因此没有单独或孤立的安全功能。这使得将安全策略和知识纳入我们的平台策略变得容易。” — Jaroslaw Gajewski
平台工程并非万能药
平台工程师有望构建和交付一个应用程序平台，帮助不同的应用程序开发团队构建、测试、部署、运行和持续改进其应用程序安全。这对一个新兴的平台工程团队来说可能是压倒性的。然而，正如开发人员采用了敏捷、特性驱动开发 (FDD)、测试驱动开发 (TDD) 和 Scrum 等现代编程实践一样，平台工程师也采用了新的思维方式。
平台工程中最强大的转变之一是将您的 平台视为产品：一个需要不断改进、微调和升级以保持安全和竞争力的产品。将您的平台视为产品并不是灵丹妙药，但它可以帮助您提供最佳的客户体验（在本例中为开发人员体验），以便他们能够快速安全地构建和交付软件。
请务必完整阅读 2024 年云原生应用程序平台现状 报告，并详细了解采用云原生方法进行应用程序交付的 趋势和优势。
