聊聊我所理解的平台工程
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.
