谷歌平台工程五个误区

盲人摸象的故事让我们明白：为什么人们会对一个新话题产生分歧，如果只从自己的角度看待问题，他们就会错过整体。

平台工程是一种相对较新的软件交付方法，IT 组织和软件工程团队正在研究它：对于它是什么、它能做什么以及为什么应该或不应该采用它存在很多分歧。

误解 1：开发者门户和内部开发者平台是同一回事
开发者门户是一个用户界面，可供开发者访问文档、API 和工具。

然而，内部开发者平台不仅仅是一个门户，它是一种工程化产品，旨在解决现实世界的问题，例如：

• DevOps 超载或认知负荷：由于现代软件系统日益复杂，团队成为瓶颈。
• 开发人员摩擦：团队与基础设施、工具、政策和流程交互的可量化减速。

• 开发人员主要与开发人员门户界面进行交互，而开发人员平台隐藏在其下方。
• 开发人员平台通过使用黄金路径实现开发者自助服务。该平台通过编码实践、设置公司范围的配置和应用安全控制等方法抽象了技术复杂性。

误解二：我们不需要内部开发者平台
平台工程从建模您当前的流程（或其改进版本）开始，并构建软件来为您完成此操作，而不是要求每个团队都成为 DevOps 实践专家。

这可以从简单的 CI/CD 管道开始，并且可以通过一致的可观察性或托管基础设施服务进行改进。

通过将这些组件整合在一起，平台就出现了。

向开发人员团队展示抽象概念，以便更好地将这些组件整合在一起，形成一致、可用的开发人员体验，这是平台工程团队的职责，而内部开发人员平台是实现这一目标的手段。

平台工程涉及的不仅仅是编写代码。虽然编码是一个重要方面，但真正的价值在于系统设计、集成、可扩展性和确保无缝的用户体验。它涵盖了系统如何通信、数据流、操作扩展以及跨团队协作。

误解三：平台工程“只是高级 DevOps”
DevOps 是一种组织和文化运动，旨在提高软件交付速度、提高服务可靠性并在软件利益相关者之间建立共享所有权，其中DevOps 实践包括

• 版本控制
• 持续集成
• 基于主干的开发
• 持续测试
• 持续交付
• 建筑学
• 云基础设施
• 测试管理

• 采取以开发人员为中心的方法
• 自动化和基础设施即代码 (IaC)
• 安全性与合规性
• 可观察性
• 连续的提高

误解四：平台工程“只是自动化”
平台工程确实是自动化，但平台是作为产品交付的，并且为完整的服务生命周期而设计的，而不仅仅是被动地附加。

自动化让团队在管理系统时减少了人工干预的需要。这可以简单地完成，例如使用 shell 脚本，也可以更复杂、更细致、更可扩展。一般来说，当人们嘲笑某些东西“只是自动化”时，他们指的是大量经常中断的琐碎 shell 脚本。

事实确实如此：自动化实际上可能会带来新的、更难解决的问题。因此，避免不受控制的自动化是可以理解的，因为系统开始失败不是由于自动化的质量，而是由于社会技术压力，如对信号的误解、误解的设计、错误的假设或不一致的激励。

误区五：平台工程只是最新的时尚
软件开发团队的认知负担显著增加：当您要管理分布在许多计算资源群中的数百或数千个微服务时，您根本无法同时深入了解基础设施层和应用程序层。

如今，平台工程解决了一些现实世界的问题，即：

1. DevOps 超负荷，又称认知负荷——当团队试图管理现代软件日益复杂的过程时，他们就会成为瓶颈
2. 开发人员摩擦 -团队与基础设施、工具、政策和流程交互时可量化的减速。

平台工程是一个协作领域，需要与产品团队、设计师、安全专家和其他利益相关者进行无缝沟通。最佳解决方案源自不同团队汇集集体专业知识。

虽然技术敏锐度必不可少，但同理心、沟通能力、适应能力和理解更广泛的业务目标等软技能也同样重要。解决方案是为有真正需求的真实用户而构建的，而不是凭空而来。

平台工程与 PaaS 有何不同？
平台即服务 (PaaS) 早于平台工程，但它并不总是适合某些团队。您可能会问，平台工程与 PaaS 有何不同？

虽然 PaaS 提供了高效构建应用程序和配置必要底层基础设施的技术，但它需要周围的人员和流程生态系统才能成功采用。
平台工程为团队提供了一种方法来构建产品的抽象或扩展，包括 PaaS，实施适合其组织的约束或自由。

换句话说，平台工程是对 PaaS“以技术为中心”模型的回应，PaaS型不适用于可能需要进一步定制的组织。

总之，平台工程是一种超越编码的整体方法，通过工程平台、协作以及技术和软技能的结合来解决现实世界的软件交付挑战。