平台工程可以做出一个通用产品吗？

平台工程（Platform Engineering）作为实施DevOps 的最佳路径，是业界的新宠。而平台工程一般的交付品是 Internal Developer Platform。

笔者在多个公司实施过平台工程，也和很多同行交流过经验，得到几乎一致的结论: 大家做的东西都大同小异。此处贴出一个朋友昨晚分享的 IDP 目标，相信做过 IDP 的朋友都会说”哎，这不就是我们团队的 KPI 吗？”

更进一步，各家做的 IDP 不仅试图解决的问题类似，功能集合和技术架构也类似。

上图是 CrossPlane 推荐的 IDP 架构图，下图是Spacelift 推荐的 IDP 架构图。可以看出。虽然具体的组件不一样，但是两个方案都是由这几部分用同样的关系组成的

1. 面向开发者的用户界面，包括 web portal，CLI 和 API，有时候还有 terraform modules

2. 一套 Git 触发的 CI/CD workflow。绝大部分日常工作由此 workflow 承载。

3. 一个资源 orchestrator，把底层的云资源抽象一层。

4. 供开发者运行时使用的 observability tools。

细心的用户可以看出，这些组件都有成熟的产品了。比如 Spotify 开源的 backstage 是非常流行的 IDP portal。CI/CD 可以选择GitHub Actions或者Jenkins。 Orchestrator可以选择crossplane。可观测性可以选择 Datadog 或者其国内替代品观测云。IDP 就是用胶水代码把这些产品，用本公司在本阶段需要的方式，粘合起来，满足本公司开发者的需求。

当然，也有财大气粗的公司，更愿意从第一行代码写起，自研每一个组件。蚂蚁金服的FusionStack和腾讯互娱的蓝鲸，都是这类。谷歌和 Meta 也是如此。不过他们都是软件工程师无限供给的巨无霸，对我们正常公司不具备可参考性。

既然每家的 IDP 目标类似，架构相同，是不是可以有这么一家公司，推出一个通用产品给大家用呢？ 目前来看，非常困难。我和朋友们讨论了一些原因，其中一个是: IDP 并不只是一个软件产品，它是一个公司软件工程方法论的具体承载物。每个公司的软件工程风格都不一样，甚至一个公司不同阶段的软件工程流程也会变化很大，要在这巨大的不同中抽象出相同的东西，确实非常困难。最极端的例子，一个专注于 IDP 的 IT consulting公司，同时为三个客户开发 IDP，他们试图做成一个产品的两个部署，结果很悲惨的失败了。

IDP 究竟能不能做成一个产品？ 如果可以的话，应该长什么样？ 目前业界没有很好的答案，读者如果有想法，欢迎留言交流。