图片
Gartner 将平台工程列为 2024 顶级战略技术趋势之一
说起平台工程（Platform Engineering） ，经常听到有人说是：新瓶装（平台工程）旧酒（DevOps）。
今天根据过去自服务平台的实践经验，聊聊我所理解的平台工程。
说到平台工程，不可不免地要聊聊云原生，不过这里不会针对是否转向云原生进行讨论。
云原生的三驾马车：微服务、Kubernetes、DevOps。根据过往的实践经验，我认为云原生技术平台的核心能力（包括但并不限于）可概括为：
容器平台：专注于容器化技术和 Kubernetes 编排，实现应用的弹性、高效存储和网络通信。这为微服务和 DevOps 的实现提供了基础架构支持。
微服务平台：集中管理微服务，包括统一的服务治理、配置管理、API 网关和支持多样的微服务框架，以适应复杂的服务交互和灵活的开发需求。
监控平台：提供全方位的监控系统，包括日志收集、性能指标监控、链路跟踪、实时告警以及监控数据的可视化展示，助力于系统的稳定运行和故障迅速定位。
DevOps 集成平台：集成持续集成和持续部署（CICD）流程，以及文档中心和代码质量管理，实现自动化、高效和标准化的软件开发和运维流程。
对于风靡多年的云原生（近来也有降温的趋势？），业界的褒贬不一：提升了研发效率和资源的利用率，；浪费资源、部署维护困难、可观测性变差等等。
云原生技术所面临的众多负面反馈，很大程度上源于其本身的复杂性。云原生平台向开发人员展现了过多的复杂性。
云原生技术，尽管带来了许多优势，比如灵活性、可扩展性和高效的资源利用，但同时也引入了一定的复杂性：
技术栈的复杂性：云原生环境通常涉及到容器化、微服务架构、CI/CD、以及基于 Kubernetes 的容器编排等技术。这些技术各自有其学习曲线，并且技术之间需要集成并协同工作，增加了系统的整体复杂性。
管理和运维的复杂性：在云原生环境中，应用程序通常被分解为多个微服务，每个微服务部署在不同的容器中，这使得监控、日志记录、故障排查和性能优化变得更加复杂。
网络复杂性：微服务架构意味着服务之间有大量的网络通信，再叠加容器、混合多云的网络环境，管理这些服务间的网络流量、确保高可用性和网络安全，以及实现服务发现等都增加了网络管理的复杂性。
可观测性和监控的挑战：确保对在不断变化的环境中运行的众多微服务有足够的可见性，需要复杂的监控和日志系统。
安全挑战：云原生架构中的分布式和动态性质引入了新的安全挑战。例如，需要确保容器安全、服务间通信的安全，以及在动态环境中持续地管理和更新安全策略。
这些复杂性给开发人员带来了显著的摩擦和认知负担，从而降低了他们的开发体验。在专注于业务开发的开发人员与底层基础设施之间，形成了一个模糊的交界区域。平台工程正是专注于这个模糊地带，旨在缩小这一差距并简化开发流程。
平台工程是一个胶水层。
图片
平台工程是一门在云原生时代为软件工程组织设计和构建工具链及工作流程的学科，旨在提供自助服务能力。平台工程师提供的综合产品通常被称为“内部开发者平台”，涵盖了应用程序整个生命周期的运营需求。
Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application.
来自 平台工程社区的介绍[1]
平台工程致力于构建和维护一个桥梁，这座桥梁把复杂的基础设施转化为简化的抽象，使得开发人员能够专注于业务逻辑的开发，无需深入钻研底层技术细节。同时，他们也努力将业务逻辑层的通用功能整合并下沉，进一步简化开发流程。
此处，我更倾向于将“工程”理解为一个动词，即对平台进行工程化。
软件开发的过程标准化、系统化和规范化是为了提高软件开发效率、质量和可维护性。这三个方面通常包括以下内容：过程标准化、系统化、规范化。
随着平台工程化水平的提升，开发人员得以享受到更高水平的自服务能力。这样的自服务平台的实施，进一步缩短了开发人员与基础设施平台之间的距离，使得开发人员能够更便捷地使用平台资源，而无需深入了解底层技术细节。
自服务平台正是工程化的产物，或者是平台工程的具象化。
自服务平台使开发人员能够直接管理和操作资源，让他们亲自参与到软件的整个生命周期中，同时无需关注幕后的基础设施和实现细节，并减少了平台团队成员的直接介入。这种平台遵循着“You build it, You run it”的理念，但不强求开发人员深入理解底层技术（“Know-how”）。
从我的角度看，自服务平台更像是流程和工具的结合体。在工具层面，无论是开源还是商业软件，都提供了对通用能力的抽象。然而，在流程方面，由于每个企业都有自己特定的管理需求和对支撑部门的依赖，流程设计上会有所不同。虽然工具可能实现标准化，但流程很难做到这一点。
我认为，将平台工程简单比喻为‘新瓶装旧酒’是不够全面的。实际上，平台工程代表的是对传统方法（例如 DevOps）的进一步沉淀和提升，为其赋予了新的表现形式和能力。
在技术与人的互动中，我们不应该忽视连接和协调的重要性。软件系统作为现实世界的一个反映，应当始终坚持以人为本的原则。
[1] 平台工程社区的介绍: https://platformengineering.org/blog/what-is-platform-engineering
本文链接：http://www.28at.com/showinfo-26-66198-0.html聊聊我所理解的平台工程
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： C++范围for循环详解
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
