“平台工程”正在迅速成为新的 DevOps 或 SRE。几乎每天我们都会听到有一个公司正在构建内部开发人员平台或控制平面。
我们都已经建立了多年的应用/网络平台
- - 企业内部：ticket驱动，裸机，交货时间长
- - 第一代PaaS：自助服务、基于虚拟机、一刀切、按需使用
- - 下一代PaaS/客户平台：自助服务、基于容器、快速反馈、良好的UX/DevX
更多精通运营的开发人员（和SRE）和对开发人员友好的信息工具的兴起，导致了定制平台的创建热潮。
构建自定义平台的吸引力在于，你可以精心设计抽象概念，以准确匹配你的组织的要求（理论上）。
这个 "平台工程 "的概念对我来说，是在听了NetflixOSS的演讲后第一次具体化的，他们团队在2010年中期谈论他们如何创建一个内部开发者平台和支持工具链时，我第一次明白了 "平台工程 "的概念。
他们的一大重点是：提供一条 "铺平的道路"；一个以开发人员为中心、低摩擦和运营支持的平台（和支持流程），使Netflix的工程师能够快速和安全地交付和运行应用程序。
后来，他们阐述了 "全周期开发人员 "的有利概念，该概念与平台工程团队共生/和谐地工作。
同时，谷歌也在大谈特谈SRE。正如我的同事所指出的，平台工程、SRE、DX团队等之间有很多交叉的地方：SRE 与平台工程，这些跨角色的共同点：专注于消除工程师的辛劳。
当然，平台工程不只是为独角兽量身定做的，我们应该为其他 "99%的开发者 "建立工具和平台。根据我过去作为软件开发者和平台建设者的经验，我认为在平台工程领域内越来越需要关注开发者体验（DevEx/DX）。
除了关注开发人员的经验，平台所有权也是一个核心概念。这里的关键要点：“让开发人员拥有所有权是速度和安全的关键”
最近的《开发者领导的景观》的主要主题。
- - 任何有想法的开发人员[被授权执行]。
- - 从CIO到开发者的权力转移
- - 开发人员的授权推动了以产品为主导的增长型公司的出现
平台工程的前景是光明的，但我们不能忘记基本原则：我们在这里都是为了向我们的最终用户客户提供价值；平台可以帮助或阻碍这一点--像对待组织中的任何其他产品那样对待你的平台。
我所看到的模式是平台工程以敏捷的名义从devOps实践中演变出来。一旦有足够多的用户在prod中互动，平台就会试图演变成SRE。让SLXs在组织的价值流中保持一致是改变游戏规则的关键。