CNCFプラットフォームホワイトペーパー

以下の記事は、CNCFのプラットフォームホワイトペーパーをGeminiで翻訳したものです。

原文: https://tag-app-delivery.cncf.io/whitepapers/platforms/

はじめに

DevOpsが約束したクロスファンクショナルな協力に触発され、企業内でその協力の明確な形として「プラットフォームエンジニアリング」が登場し始めました。プラットフォームは、アプリケーション開発者、データサイエンティスト、情報ワーカーなどの内部顧客の業務を促進し、加速するために、基本的な能力、フレームワーク、および経験を厳選して提供します。特にクラウドコンピューティングの分野では、プラットフォームは、製品の迅速なリリース、インフラ間の移植性、より安全で弾力的な製品、そしてより高い開発者生産性など、クラウドが長年約束してきた価値を企業が実現するのを支援しています。

本ホワイトペーパーは、企業リーダー、エンタープライズアーキテクト、およびプラットフォームチームリーダーが、クラウドコンピューティングのための内部プラットフォームを擁護し、調査し、計画するのを支援するために作成されました。私たちは、プラットフォームが企業の実際の価値の流れ（Value Streams）に大きな影響を与えるものの、それは間接的な方法であると信じています。したがって、プラットフォームチームの長期的な持続可能性と成功のためには、経営陣の合意と支援が不可欠です。この文書では、プラットフォームの価値とは何か、その価値をどのように測定するか、そして価値を最大化するプラットフォームチームをどのように実装するかを議論することで、そのような支援を可能にします。

なぜプラットフォームなのか？
プラットフォームとは何か？
成功するプラットフォームの属性
成功するプラットフォームチームの属性
プラットフォーム実装時の課題
プラットフォームの成功を測定する方法
プラットフォームの能力

なぜプラットフォームなのか？

今日のクラウドコンピューティングの世界では、プラットフォームとプラットフォームエンジニアリングは人気のあるテーマです。プラットフォーム構築のための定義、技術、測定方法を掘り下げる前に、まず、この関心を引き起こすプラットフォームの価値が何であるかを探求することが重要です。

過去20〜30年間のプロセス改善は、ソフトウェアアプリケーションおよび製品チームの俊敏性を大幅に向上させました。彼らには、コンピューティング、ネットワーク、ストレージなどのインフラサービスだけでなく、ビルド、テスト、デプロイ、可観測性などの開発者サービスも柔軟に提供されました。しかし、この自律性とプロセス改善は、皮肉にもサポートサービスに対する責任を製品チームに徐々に転嫁する結果となりました。結果として、製品チームはインフラ問題にますます多くの時間と認知的エネルギーを費やすようになり、組織に実質的な価値を生み出す時間が減少しました。

デリバリーチームが本来の業務に集中できるようにし、組織全体の重複した労力を削減したいという願望が、企業がクラウドネイティブコンピューティングのためのプラットフォームを実装する動機となりました。プラットフォームに投資することで、企業は以下の利点を得ることができます。

製品チームの認知負荷（Cognitive load）を軽減し、製品開発とデプロイを加速します。
専門家がプラットフォームの能力を構成および管理することで、その能力に依存する製品の信頼性と弾力性を向上させます。
企業内の複数のチームがプラットフォームのツールと知識を再利用および共有することで、製品開発とデプロイを加速します。
プラットフォームの能力とその周辺のユーザー、ツール、プロセスをガバナンス下に置くことで、製品およびサービスのセキュリティ、規制、機能上の問題のリスクを軽減します。
ユーザーエクスペリエンスに対する制御を維持しつつ、実装をパブリッククラウドおよびマネージドサービスプロバイダーに委任することで、費用対効果が高く生産的なサービス利用を可能にします。

これらの利点は、一部には少数のプラットフォームチームが多数の製品チームにサービスを提供することで影響力を倍増させるため、一部にはプラットフォームチームが共通機能管理を統合してガバナンスを容易にするため、そして最後に、プラットフォームチームが何よりもユーザーインターフェースとエクスペリエンスを重視するためにもたらされます。

プラットフォームの専門家チームは、製品チームに求められる共通のタスクを削減するだけでなく、それらの製品で使用されるプラットフォームの能力を最適化します。さらに、プラットフォームチームは、企業全体で広く使用されている慣習的なパターン、知識、およびツールセットを維持し、開発者が同じ基盤の上に構築された他のチームや製品に迅速に貢献できるようにします。共有されたプラットフォームパターンにより、テンプレート、パターン、および能力内にガバナンスと制御機能を組み込むことができます。最後に、プラットフォームチームはプロバイダーを管理し、一貫したエクスペリエンスを提供するため、データベース、IDアクセス、インフラ運用、アプリライフサイクルなどの基礎的だが差別化されていない機能のために、パブリッククラウドとサービスプロバイダーを効率的に利用できるようになります。

プラットフォームとは何か？

クラウドネイティブコンピューティングのためのプラットフォームは、プラットフォームユーザーのニーズに応じて定義され、提示される能力の統合された集合体です。これは、様々なアプリケーションやユースケースに対して、一般的な能力とサービスを取得し統合する際に一貫したエクスペリエンスを保証する横断的なレイヤー（cross-cutting layer）です。優れたプラットフォームは、ウェブポータル、プロジェクトテンプレート、セルフサービスAPIのように、能力とサービスを使用し管理するための一貫したユーザーエクスペリエンスを提供します。

Atlassian[1]によると、「プラットフォームチームは、最小限のオーバーヘッドで多数のストリームアラインド[製品]チームが利用できる能力を構築します。プラットフォームチームは、製品チームのリソースと認知負荷を最小限に抑え、異なるユーザーエクスペリエンスや製品を横断するまとまりのあるエクスペリエンスを生み出すことができます。」

Martin FowlerとEvan Bottcher[2]によると、「デジタルプラットフォームは、セルフサービスAPI、ツール、サービス、知識、およびサポートの基盤であり、魅力的な内部製品として配置されます。自律的なデリバリーチームは、このプラットフォームを利用して、調整作業を減らしながら、より速いペースで製品機能を提供できます。」

プラットフォームがサポートする具体的な能力とシナリオのセットは、ステークホルダーとユーザーのニーズによって決定されるべきです。プラットフォームがこれらの必須能力を提供する一方で、プラットフォームチームが常にそれらを直接実装する必要はないという点が重要です。マネージドサービスプロバイダーや専任の内部チームがバックエンドの実装を維持することができ、プラットフォームは提供される実装全体にわたって一貫性を提供し、組織の要件を満たす「最も薄く合理的なレイヤー（thinnest reasonable layer）」として機能します。例えば、非常に単純な「プラットフォーム」は、プロバイダーから能力をプロビジョニングするための標準運用手順へのリンクを含むWikiページである場合もあります[3]。

これらのプラットフォームは企業の内部ユーザーのみを対象としているため、私たちはしばしばこれを内部プラットフォーム（Internal Platforms）と呼びます。

プラットフォームは、クラウドネイティブアーキテクチャにおいて特に重要です。その理由は、以前のパラダイムよりもアプリケーション固有のロジックからサポート能力をより明確に分離するためです。クラウドのような環境では、リソースと能力はしばしば独立して管理され、カスタムビジネスコンポーネントと統合されます。これらのリソースには、データベース、オブジェクトストレージ、メッセージキュー、可観測性コレクターとダッシュボード、ユーザーディレクトリ、認証システムなどが含まれる場合があります。内部プラットフォームは、企業チームがこれらのリソースを自身のアプリケーションやシステムに簡単に統合できる方法で提供します。

プラットフォーム成熟度（Platform maturity）

最も基本的な段階では、内部プラットフォームは、パイプラインランナー、データベースシステム、またはシークレットストアなどの個々のサービスを取得および使用するための一貫したエクスペリエンスを提供します。成熟するにつれて、内部プラットフォームは、ウェブアプリケーション開発やデータ分析（MLOps）などの主要なシナリオのためのセルフサービステンプレートとして、これらのサービスの組み合わせ（compositions）を提供します。

企業がプラットフォームを通じて達成できるユースケースは、次のように発展することができます。

製品開発者が、コンピューティング、ストレージ、データベース、またはIDなどの能力を必要に応じてプロビジョニングし、すぐに使用してシステムを実行できます。
製品開発者が、サービススペースを必要に応じてプロビジョニングし、それを使用してパイプラインとジョブを実行し、成果物と構成を保存し、テレメトリーを収集できます。
サードパーティソフトウェア管理者が、データベースなどの必須の依存関係を必要に応じてプロビジョニングし、そのソフトウェアを簡単にインストールおよび実行できます。
製品開発者が、ウェブ開発やMLOpsなどの特定のシナリオに必要なランタイムおよび開発時サービスが結合されたテンプレートから、完全な環境をプロビジョニングできます。
製品開発者と管理者が、自動化されたインストルメンテーションと標準ダッシュボードを通じて、デプロイされたサービスの機能、パフォーマンス、およびコストを観察できます。

このホワイトペーパーが最初に発表された後に作成されたプラットフォームエンジニアリング成熟度モデルを参照してください。

個々の能力またはその集合体に対して一貫性があり、規制に準拠したエクスペリエンスを提供することで、内部プラットフォームは最終的にユーザーが価値のある製品をより簡単かつ効率的に提供できるようにします。

プラットフォームの属性

プラットフォームとは何か、なぜ構築すべきかを定義した後、成功に影響を与えるいくつかの主要な属性を確認しましょう。

製品としてのプラットフォーム（Platform as a product）：プラットフォームはユーザーの要求を満たすために存在し、他のソフトウェア製品と同様に、その要求に基づいて設計され、進化する必要があります。プラットフォームは、製品チーム全体で最も一般的なユースケースをサポートするために必要な能力を提供し、提供される価値を最大化するために、単一チームのみが使用する具体的な能力よりも共通の能力を優先すべきです。
ユーザーエクスペリエンス（User experience）：プラットフォームは、一貫したインターフェースを通じて能力を提供し、ユーザーエクスペリエンスに集中すべきです。プラットフォームは、ユーザーがいる場所（GUI、API、CLI、IDE、ポータルなど）で彼らに会うよう努めるべきです。例えば、製品オーナーはウェブポータルを使用し、開発者はIDEを、テスターはCLIを通じて同じデプロイ能力を消費することができます。
ドキュメントとオンボーディング（Documentation and onboarding）：ドキュメントは、成功するソフトウェア製品の核心です。プラットフォームは、ユーザーのニーズを満たす適切なドキュメントと例とともに提供されるべきです。また、ユーザーがプラットフォームサービスを迅速かつ簡単に利用できるように支援する新しいプロジェクトオンボーディングツールも提供すべきです。これらのバンドルはしばしばゴールデンパス（Golden Path）と呼ばれます。
セルフサービス（Self-service）：プラットフォームはセルフサービスが可能であるべきです。ユーザーは自律的かつ自動的に能力を要求し、受け取ることができるべきです。これは、プラットフォームチームが複数の製品チームをサポートし、スケールするために不可欠な特性です。
ユーザーの認知負荷の軽減（Reduced cognitive load for users）：プラットフォームの必須目標は、製品チームの認知負荷を軽減することです。プラットフォームは、実装の詳細をカプセル化し、アーキテクチャで発生する可能性のある複雑さを隠すべきです。ユーザーは、プラットフォームが提供するサービスを運用する責任を負うべきではありません（例：データベースサーバー自体を管理する必要がない）。
選択可能および組み合わせ可能（Optional and composable）：プラットフォームは効率を高めるためのものであり、妨げになるべきではありません。プラットフォームは組み合わせ可能であるべきであり、製品チームが提供される機能の一部のみを使用できるようにすべきです。また、必要に応じて製品チームがプラットフォーム外部で独自の能力を管理できるべきです。
デフォルトで安全（Secure by default）：プラットフォームはデフォルトで安全であるべきであり、組織で定義されたルールと標準に従ってコンプライアンスと検証を保証する能力を提供すべきです。

プラットフォームチームの属性

プラットフォームチームは、ウェブポータル、カスタムAPI、ゴールデンパステンプレートなどのプラットフォーム能力のインターフェースとエクスペリエンスに責任を負います。一方では、インフラを実装するチームと協力して一貫したエクスペリエンスを定義し、他方では、製品チームと協力してフィードバックを収集し、要件が満たされていることを確認します。

プラットフォームチームの主な業務は以下の通りです。

プラットフォームユーザーの要件調査と機能ロードマップの計画
プラットフォームの提案価値のマーケティング、普及、擁護
ポータル、API、ドキュメント、テンプレート、CLIツールを含む、能力およびサービスの使用/観察インターフェースの管理と開発

最も重要なのは、プラットフォームチームがユーザーの要件を継続的に学習し、提供するインターフェースを改善することです。学習方法には、インタビュー、ハッカソン、イシュートラッカー、アンケート、および可観測性ツールを通じた直接観察が含まれます。

インバウンドフィードバックと思慮深い設計が製品デリバリーの一面であるとすれば、もう一面はアウトバウンドマーケティングと擁護です。プラットフォームがユーザーの要件に合わせて構築されていれば、ユーザーは喜んでそれを使用するでしょう。プラットフォームチームは、告知、デモ、定期的なフィードバックセッションなどの内部マーケティング活動を通じて、ユーザーの導入を促進する必要があります。

プラットフォームチームが必ずしもコンピューティング、ネットワークなどのサービスを直接運用する必要はありません。実際、内部プラットフォームは可能な限り外部から提供されるサービスと能力に依存すべきです。プラットフォームチームは主に、これらのサービスが提供されるインターフェース（GUI、CLI、API）とユーザーエクスペリエンスに責任を負います。

プラットフォーム実装時の課題

プラットフォームは多くの価値を約束しますが、以下の課題も伴います。

プラットフォームチームは、プラットフォームを製品のように扱い、ユーザーと共に開発する必要があります。
プラットフォームチームは、優先順位と初期のパートナーアプリケーションチームを慎重に選択する必要があります。
プラットフォームチームは、企業リーダーシップの支援を求め、価値の流れへの影響を示す必要があります。

最も重要なのは、プラットフォームを顧客向け製品として扱い、その成功がユーザーと製品の成功にかかっていることを認識することです。フィードバックなしに機能をリリースしたり、トップダウンの命令（top-down mandates）に依存して導入を強制したりするプラットフォームチームは、ユーザーの抵抗に直面する可能性が高いです。

プラットフォームチームの活性化

プラットフォームチームもまた、多様な責任のために認知負荷に直面します。チームのエネルギーをビジネスに固有のエクスペリエンスと能力に集中させることが重要です。プラットフォームチームの負担を軽減する方法は以下の通りです。

マネージドプロバイダーの実装の上に、最も薄い実行可能なプラットフォームレイヤー（thinnest viable platform layer）を構築します。
ドキュメント、テンプレート、組み合わせを作成するために、オープンソースのフレームワークとツールキットを活用します。
プラットフォームチームが、ドメインと顧客数に合わせて適切な人員を確保するようにします。

プラットフォームの成功を測定する方法

プラットフォームチームは、ユーザーフィードバックを継続的に収集し、活動を測定する必要があります。測定項目は以下の通りです。

ユーザー満足度と生産性：アクティブユーザー数と維持率、ネットプロモータースコア（NPS）、SPACEフレームワーク[4]などの開発者生産性指標。
組織効率：サービス要求から履行までの遅延（latency）、新しいサービスのビルドおよびデプロイ時間、新規ユーザーが最初のコード変更を提出するまでの時間。
製品および機能デリバリー：DORAメトリクス（デプロイ頻度、変更リードタイム、障害からの復旧時間、変更失敗率）の追跡。

究極的には、組織の製品とアプリケーションの成功が、プラットフォーム成功の真の尺度です。

プラットフォームの能力

クラウドネイティブコンピューティングプラットフォームは、様々なサポートプロバイダーの能力を組み合わせます。プラットフォームは、能力提供者とアプリケーション開発者の間の橋渡し役を果たし、セキュリティ、パフォーマンス、コストガバナンスを施行します。

考慮すべき能力ドメイン：

ウェブポータル：製品および能力の観察/プロビジョニング用
APIおよびCLI：自動プロビジョニング用
「ゴールデンパス」テンプレートおよびドキュメント：最適な使用をサポート
ビルド/テスト/デプロイ自動化
開発環境：ホスト型IDEなど
可観測性：機能、パフォーマンス、コストダッシュボード
インフラサービス：ランタイム、ネットワーク、ストレージ
データサービス：：DB、キャッシュ、オブジェクトストレージ
メッセージングおよびイベントサービス
IDおよびシークレット管理
セキュリティサービス：静的/ランタイム分析、ポリシー施行
アーティファクトリポジトリ：イメージおよびパッケージストレージ

（以降の表部分には、各能力ごとのCNCF/CDFプロジェクトの例がリストされており、Backstage、Kubernetes、Argo、Crossplane、Prometheusなど、おなじみのプロジェクトが含まれています。）