什么是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的平臺架構方案給出了自己的一些觀點。