内部開発者プラットフォーム（IDP）とは、組織が構築する集中型の内部ツール、サービス、ワークフローの集合体であり、開発者が基盤となるインフラを自ら管理することなくソフトウェアの構築、デプロイ、運用を容易に行えるようにするためのものです。

内部開発者ポータル（紛らわしくなるがIDPとも略される）は、エンジニアがソフトウェアの構築や保守に必要なツール、ワークフロー、API、ドキュメンテーション、統合を発見しアクセスできるようにするインターフェースです。これにより、組織の開発プロセスと組織的知識に関する単一の集約先が提供されるため、開発者はセルフサービス・モデルで効率的に作業を行うことができます。

この2つはしばしば混同されます。単に頭字語を共有していること、またどちらも開発者の能力強化を扱っていることが理由です。

現代のソフトウェア配信環境はますます複雑になっています。開発者はKubernetesクラスター、 CI/CDパイプライン、クラウドインフラ、 オブザーバビリティ ツール、 インフラストラクチャ・アズ・コード（IaC） リポジトリ、コンプライアンス要件などを把握しなければなりません。また、組織の規模が拡大するにつれて、ソフトウェア開発ライフサイクル（SDLC）全体にわたる内部サービスと依存関係の数も増加します。これは、複数のクラウド・プロバイダーで分散マイクロサービス・アーキテクチャーを運用している企業に特に当てはまります。

プラットフォーム・エンジニアリングは、こうした複雑さへの対応として出現し、より広範なDevOpsイニシアチブから発展したものです。組織は、すべての開発チームにインフラストラクチャーやオペレーションの専門家になることを強制するのではなく、再利用可能なシステムと、反復的な運用作業を抽象化する「ゴールデン・パス」の構築を担当する集中型プラットフォーム・チームを編成します。その目標は、開発者の認知負荷を軽減し、セルフサービスを可能にすることで、開発者がソフトウェアの構築と提供に集中できるようにすることです。

このトレンドにより、内部開発者プラットフォームと内部開発者ポータルという2つの（異なるが）相互に関連するレイヤーが誕生しました。

このプラットフォームは、標準化されたソフトウェアの提供と開発者のセルフサービスを可能にする運用の基盤です。すべてのテクノロジーとツールが連携して、ゴールデン・パスを提供します。通常、次のコンポーネントで構成されます。

• インフラストラクチャー・オートメーション（Terraformなど）

• CI/CDパイプライン

• Kubernetesの抽象化

• IDとアクセス制御

• 環境プロビジョニング・システム

• セキュリティガードレール

• コードとしてのインフラストラクチャーのテンプレート

• クラウドネイティブなオーケストレーション

• GitHubの統合

• リアルタイムの可観測性

• ポリシー執行システム

このプラットフォームの魔法は、開発者がこれらのシステムの多くと直接やり取りすることがないことです。このプラットフォームは、ソフトウェア配信の背後で面倒な作業を処理します。通常、専用のプラットフォーム・エンジニアリング・チームによって保守されています。その目的は、承認されたワークフローとインフラストラクチャー・パターンを、再利用可能でスケーラブルかつ安全な形で公開することです

ポータルは、開発者がプラットフォームの機能を見つけて操作できるようにするユーザー向けインターフェースです。それはエンジニアリング・エコシステムのコントロールパネルのようなものです。これは通常、以下を提供します。

• サービスカタログ

• ドキュメンテーション・ハブ

• APIディスカバリー

• インフラストラクチャー・リクエスト・フォーム

• デプロイメント・ダッシュボード

• 所有権メタデータ

• スコアカードとヘルスチェック

• テンプレート

• セルフサービス・ワークフロー

• 運用ツールへのリンク

これらのコンポーネントは、多くの場合、Backstageと呼ばれるオープンソースのテクノロジーを介して統合されます。これは、その拡張性が高く評価されているフロントエンド・ポータル・フレームワークです。これは完全なプラットフォームではありません。組織がセルフサービス機能を提供するには、バックエンドの自動化、オーケストレーション、インフラストラクチャー・ツールが依然として必要です。

ポータルは、数十のシステムに分散してしまいがちなエンジニアリング参考情報へのアクセスを一元化します。ワークフローを実行するわけではありません。単にユーザーフレンドリーなインターフェースを提供し、プラットフォームの他の場所でトリガーできるようにするだけです。このプラットフォームは、実際の運用機能を提供します。

内部開発者プラットフォームは、ポータルがなくても存在できます。開発者は、CLI、API、GitOpsワークフロー、またはインフラストラクチャー・リポジトリを介して直接やり取りできます。同様に、ポータルはその下に洗練されたプラットフォームがなくても存在できます。この場合、ポータルはサービス・カタログまたはドキュメンテーション・レイヤー以上のものにはなりません。

小規模なエンジニアリング・チームであれば、ドキュメンテーション、メタデータ、API、サービス検出を一元化するだけであっても、軽量ポータルから大きな価値を引き出すことができます。このように信頼できる唯一の情報源として機能する限定的なポータルは、運用知識を統合することで迅速な成果を生み出せますが、それには強力なガバナンスが必要です。

数百人、数千人の開発者がいる成熟したデータ駆動型の組織には、ポータルとプラットフォームの両方が必要です。これらのシステムを組み合わせることで、断片化されたツール・チェーンやインフラストラクチャーのワークフローを手動で操作する必要のあるエンジニアにとって、よりユーザー・フレンドリーなエクスペリエンスが生まれます。

実際には、多くの組織は、Backstageのようなポータルを実装することからプラットフォーム・エンジニアリングを始めています。ビジュアル・インターフェイスが可視性と組織の勢いを生み出すからです。

このプラットフォームは、次のようなユースケースに不可欠になります。セルフサービス・インフラストラクチャー・プロビジョニング

• 標準化されたデプロイメント・ワークフロー

• マルチクラウド・オーケストレーション

• 安全な黄金の道

• ポリシーの施行

• コストガバナンス

• 環境の自動化

• インフラストラクチャー・ライフサイクル管理

• チーム全体で一貫した開発者エクスペリエンス

プラットフォームが提供する標準化がなければ、開発者はコアの開発者のワークフローを中断する無関係なタスクの責任を負うことになるため、開発者の生産性が低下します。この標準化により、オンボーディングも合理化されます。

ポータルとプラットフォームが連携することでセルフサービスが実現し、開発者はポータルを通じて必要な参考情報を独自にオンデマンドで発見でき、プラットフォームを通じて運用タスクを実行できます。

AIはこれら両方のコンポーネントを再構築しています。このプラットフォーム内では、AIはインフラストラクチャーのプロビジョニング、CI/CDの最適化、ポリシーの適用、インシデント分析、コスト管理をはじめとする運用タスクを自動化できます。

ポータルでは、AIにより検出と使いやすさが向上します。開発者は自然言語クエリーを使用して、複数のシステムを手動で操作することなく、API、ドキュメンテーション、テンプレート、所有権情報、運用ワークフローを見つけることができます。IBM BobなどのAIアシスタントは、オンボーディングを案内し、内部ツールに関する質問に答え、組織の基準に基づいて承認されたゴールデン・パスを推奨できます。

AIにより、セルフサービスはかつてないほどサービス性が向上しています。AIをポータルとプラットフォームの両方に適用することで、開発者は自分の中核的な業務に集中できます。