什么是IDP？

在讲IDP之前，先讲下平台工程。平台工程是软件工程中比较火的一个话题。Gartner预测，到2026年，80%的软件工程组织将建立平台工程团队，作为应用程序交付的通用组件、服务以及工具的内部提供商。

平台工程是设计和构建工具链和工作流的学科，为云原生时代的软件工程组织提供自助服务功能。平台工程师需要提供一种集成的产品，即IDP，涵盖应用程序整个生命周期。

简单总结的话，技术体系中会新增一个平台团队，该团队会按照平台工程的思路，提供一个IDP。

为什么需要IDP？

从业务来看，业务变得越来越复杂。比如一家内容公司，内容形式从过去的文本扩展到图片、视频以及直播，同时又会考虑增加社交属性。有了流量，就会考虑商业化和电商。为了更大程度增加APP用户使用时长和使用效果，又会引入推荐系统。

实际上业务复杂意味着对技术的要求也是越来越高。比如使用到的存储类型的产品，除了过去的关系型数据库、redis，也会有KV存储、图数据库、数据仓库等。

从底层基础设施来看，从单一的公有云或是私有云演进到混合云。

如果让业务研发需要感知这些复杂性，简直无法想象。所以需要在业务研发和基础设施团队之间，增加一个平台团队。

平台团队通过IDP，让业务无需感知底层基础设施，专注在业务迭代上，提高应用交付效率。

简单总结的话，当业务规模到一定程度的时候，需要IDP来解决复杂性的问题。

如何构建IDP？

humanitec 有一些关于IDP的实现方案。在不同的云上，根据实际情况替换部分组件。

AWS

GCP

Azure

通过上边三幅图，可以知道一个IDP，包括：

• 开发者控制层
• 开发工具
• 服务目录、API目录、Portal
• 版本控制
• 代码版本控制
• 应用描述版本控制
• 基础设施版本控制
• 集成和交付层
• CI
• 平台编排
• CD
• 可观测层
• 监控和日志
• 安全层
• 资源层
• 云资源和云服务

实际上，核心是构建一个以应用为中心的，可以支持业务自助管理应用并且持续交付应用到不同异构基础设施的平台。

其实想实现这样的目的，需要抽象很多东西。此处想一下，平台团队在技术体系中的位置，我个人理解关键主要是应用模型、资源模型（IaC）以及workflow三块。

应用模型

应用模型不仅包括服务自身的描述，也会包括所依赖服务的描述。该模型是以应用为中心思想的关键。

图中的方案是score。

类似的解决方案有OAM和radius。

资源模型

资源模型是对异构基础设施的抽象，向上提供标准化的体验，并且自动化基础设施的管理和交付。

图中的实现方案是terraform。类似的解决方案有crossplane、pulumi。

Workflow

Workflow会涵盖整个应用的交付过程。不仅包括CI、平台编排、CD，也会包括风险管控、预算审批等环节。所以workflow一定需要支持其他工具以插件化的形式接入的能力。

总结

本文简单介绍了平台工程和IDP。并且基于humanitec的平台架构方案给出了自己的一些观点。