国外大神Sid Palas，一位专门做 DevOps 和 Cloud infra 相关工作的开发者，不久前发出的一条惊悚推特：DevOps is dead，long live Platform Engineering（DevOps已死，平台工程万岁！），引爆了开发者们的焦虑与愤懑。

因为DevOps，开发者们焦虑什么？

开发者们主要焦虑的点是：DevOps 将开发工作和运维工作重新统一了起来，然而，DevOps 的理念（之一）就是 “谁敲的代码，由谁来运维”，那么，在这样的理念之下，必然会产生新的问题：

问题一：管理越来越复杂

企业采用了 DevOps 的理念或平台，再加上云原生的应用，这个时候云原生的工具一箩筐，K8s、Helm Charts、Promethus等；有关的概念也有一堆，GitOps、ChatOps 、FinOps等； 就连一个CICD也能整出不少花样，更别说把什么高代码和低代码对接起来，然后还要再把API编排测试和服务网格等融合进来……

无论是研发还是运维层面的工作，越来越复杂，门槛越来越高。

问题二：开发者工作越繁重

一些技术能力极强的开发者，无论是应用层还是底层、基础层等各方面的技术都懂，他不但需要（主动或被动）地承担了运维的职责，或许，同时他还得响应大量的初级开发者的求助。在这种情况下，资深开发者的精力没有用在“敲代码”上，来创造新的价值，反而是被纠缠于运维和“被求助”的一些琐事中。而这些“琐事”，也未必是他的上级（通常是指一个产品研发的Leader) 的关注点，甚至做了这些“琐事”，他无法为自己、为企业创造任何价值。

话又说回来，谁还不是个技术能力强悍的开发者呢？即便现在不是，未来也终将会变得技术能力超群，现在的技术“大佬们”面临的窘境，也许也是未来的你即将面临的问题。

因此，Sid Palas这条推特的核心观点是：开发者不想跟基础设施打交道，企业在发展过程中又需要管控自己的基础设施。只有平台工程，能将这两个相互矛盾的命题统一起来。

什么才是“平台工程”？

按照“平台工程”社区主要贡献者和 Humanitec 的产品负责人 Luca Galante 的说法，平台工程是一门设计和构建工具链与工作流的学科。这些工具链和工作流可以为云原生时代的软件工程组织提供自助服务功能。平台工程师提供集成化产品，通常称为“内部开发平台（Internal Developer Platform）”，可以涵盖应用程序整个生命周期的所有操作需求。

内部开发平台（以下简称 IDP）是位于工程团队已有技术和工具之上的一层。它帮助操作人员进行系统性设置，并为开发人员提供自助服务。平台工程做好了，就好比是为个体开发人员铺就了金光大道，他们可以从 IDP 层获得合意的抽象等级。

通过建设这样一个企业内部开发平台，可以让所有开发者以“自助式”实现应用的端到端流程（包括设计、开发、测试、运维），不需要成为各领域云原生“技术专家”，通过平台来设计好软件、敲好代码、支持好业务才是一个开发人员的关键工作。

kaiyun开云创新CloudOS（一站式云原生开发平台），正是秉持着这样的理念

通过CloudOS，可以为企业构建敏捷创新的应用研发环境，实现应用研发可视化、敏捷化和技术平台标准化，让传统应用研发人员快速实现云原生应用创新，加快企业数字化转型。提供可视化操作界面，通过WEB页面完成架构设计、API管理、在线开发、API自动化测试、多云发布、多云应用调度、应用运维等云原生应用全生命周期管理。支撑传统应用迁移上云，助力传统应用研发团队高效完成云原生应用创新。

1. 提供可视化操作页面，屏蔽底层技术

CloudOS 封装 Docker、K8S 等底层技术，为用户提供的是简洁明了的可视化操作界面。

真正的实现了应用与云原生平台分离，IT 团队中相关人员分别承担应用研发、应用运维、平台运维等角色。Docker、K8S 等云原生技术为底层平台技术，平台运维人员需要学习并掌握，应用研发和应用运维人员将更聚焦于应用本身，不需要过多关注底层云原生平台技术。因而CloudOS 云原生平台对底层技术进行封装，给应用团队提供友好易使用的可视化操作页面，让应用团队不需要学习 Docker、K8S 技术也能高效进行数字化应用创新。

2. 为应用创新提供一站式平台支撑

CloudOS 打破了各环节、各部门信息壁垒，提供统一操作页面，让研发资产（如软件架构资产、API 接口、测试用例、制品包、镜像文件等）在各环节顺畅流动起来，进而提升各环节协作效率。同时，CloudOS还提供云原生 DevOps 能力，实现应用的 CI/CT/CD（持续集成/持续测试/持续交付）。

真正的DevOps，应该是与云原生开发平台（云原生平台工程）关联起来的，这样才能发挥真正的 DevOps 效应。

3. 提供 PaaS 能力，让研发人员更聚焦、运维人员更轻松

CloudOS 提供 PaaS 能力，承接各垂直数字化应用中的大量非功能特性，如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力、多数据中心部署能力等等，实现应用与平台分离，为数字化应用瘦身减负。让研发人员尽可能只关注业务逻辑，花更多的时间在写业务相关的代码上，减少写公共代码所花费的时间，减少维护环境所花费的时间，同时让运维人员能借助工具更轻松的运维应用。

4. 让企业研发模块化、标准化、自动化

· 模块化，用他人生产的轮子，而不是自己重复造轮子：构建企业模块商店，通过可视化模块组装，像搭积木一样进行软件架构计；形成企业内共创协同机制，共同推进各类模块的演进，形成日益丰富的数字化积累。

· 标准化，标准执行是加强规范性和提高复用性的重要基础：通过形成开发模板和任务分发机制，形成API统一管理能力并制定相关测试用例，定义好每个服务接口的API规范及相关测试用例，对下游开发成果进行强约束。模块研发人员以接口规范为开发契约，甚至不需要知道最终服务于何类业务。

· 自动化，配套工具是让研发人员聚焦提效的重要手段：一站式的开发环境，一站式的多云灵活发布、调度，自动化、智能化安全排查机制……配套工具齐全，开发一站到底。

总结

未来，在企业发展当中，会逐渐衍生出四种团队 :

· 业务导向团队：与业务领域某个部分的工作流相匹配，处理核心业务逻辑。

· 赋能团队：帮助业务导向团队克服障碍并检测缺失的功能。

· 复杂子系统团队：在严重依赖数学 / 技术方面的专业知识时组建。

· 平台团队：提供一个令人信服的内部平台，提高业务导向团队的交付速度。如上图所示，平台团队与其他所有团队都是平行的，旨在确保从编码到生产的自助工作流的流畅运转。

所以，借助平台的力量让分工明确，才是企业管理需要考量的最重要的事情。

如果您认为您的团队目前很小，用不上云原生平台工程，其实这便错了。

Humanitec 的产品负责人 Luca Galante 对此强调道，“我听过无数团队的故事，他们构建 IDP 的时间太滞后了，并因此承受了许多本不必承受的痛苦，例如，唯一一名负责 DevOps 的员工休假，整个组织几周都不能部署。IDP 和招聘平台工程师可能是你今天就要考虑的投资。”

云原生已经成为了趋势，一切都水到渠成，何必再等东风？

点击链接，免费体验CloudOS （一站式云原生开发平台）>>

点击链接，免费获取《CloudOS云原生技术解决方案》白皮书>>