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

イントロダクション

DevOpsによって約束された部門横断的な協力に触発され、プラットフォームやプラットフォームエンジニアリングが、企業においてその協力の明確な形として登場しました。プラットフォームは、アプリケーション開発者、データサイエンティスト、インフォメーションワーカーなど、内部顧客の作業を促進し、加速するために、基盤となる能力、フレームワーク、エクスペリエンスを収集・整理して提供します。特にクラウドコンピューティングにおいて、プラットフォームは、迅速な製品のリリース、インフラストラクチャー間の移植性、より安全で弾力性のある製品、開発者の生産性向上など、クラウドが長い間約束してきた価値を企業が実現するのに役立ってきました。

この文書は、エンタープライズのリーダー、エンタープライズアーキテクト、およびプラットフォームチームのリーダーが、クラウドコンピューティングのための内部プラットフォームの提唱、調査、計画をサポートすることを目的としています。私たちは、プラットフォームが企業の実際のバリューストリームに大きな影響を与えると信じていますが、それは間接的なものなので、プラットフォームチームの長期的な持続と成功にはリーダーシップの合意と支援が不可欠です。この文書では、プラットフォームの価値が何であるか、それをどのように測定するか、そしてそれを最大化するプラットフォームチームをどのように実現するかについて議論することで、その支援を促進します。

Table of Contents

1. なぜプラットフォームなのか?
2. プラットフォームとはなにか？
3. 成功するプラットフォームの特徴
4. 成功するプラットフォーム・チームの特徴
5. プラットフォームを導入する時の課題
6. プラットフォームの成功をどう測定するか
7. プラットフォームの能力

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

今日のクラウドコンピューティングの世界において、プラットフォームとプラットフォームエンジニアリングは人気のある話題です。 プラットフォーム構築の定義、テクニック、測定方法に飛び込む前に、まずプラットフォームがもたらす価値を追求することが重要です。

過去20～30年にわたるプロセスの改善により、コンピュートやネットワーク、ストレージのようなインフラストラクチャーと、ビルドやテスト、デリバリー、オブザーバビリティのような開発者サービスの両方に、柔軟なサービスを提供するようになり、ソフトウェアアプリケーションやプロダクトチームのアジリティは大幅に向上しました。

また、このような自主性とプロセス改善は、サービスをサポートする責任の多くを徐々にプロダクトチームに移し、彼らがインフラストラクチャーの課題に費やす時間と認知エネルギーを増やすことを余儀なくされ、組織にとって価値のある成果を生み出すための時間が減らすという効果をもたらしました。

デリバリーチームを本来のコア業務に集中させ、組織全体の重複作業を減らしたいという要望から、企業はクラウドネイティブコンピューティング向けのプラットフォームを導入するようになりました。プラットフォームに投資することで、企業は次のことが可能になります：

1. プロダクトチームの認知負荷を軽減し、プロダクト開発とデリバリーを加速します。
2. プラットフォーム能力を構成・管理する専門家を配置することで、彼らに依存する製品の信頼性と回復力を向上させます。
3. 企業内の多くのチームでプラットフォームツールやナレッジを再利用・共有することで、プロダクト開発とデリバリーを加速します。
4. プラットフォーム能力、ユーザー、ツール、プロセスを統制することで、製品とサービスにおけるセキュリティ、規制、機能面のリスクを軽減します。
5. ユーザーエクスペリエンスの制御を維持しながら、パブリッククラウドやその他のマネージドサービスプロバイダーへの実装の委譲を可能にすることで、コスト効率と生産性の高いサービスの利用を可能にします。

これらの利点は、わずか数人のプラットフォームチームが多くのプロダクトチームにサービスを提供しその影響力を倍増させるため、またプラットフォームチームが共通機能の管理を統合しガバナンスを促進するため、そしてプラットフォームチームがユーザーインターフェースとエクスペリエンスを何よりも重視するため、といった理由もあります。

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

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

クラウドネイティブコンピューティングのためのプラットフォームとは、プラットフォームの利用者のニーズに合わせて定義、提供された能力の集合体です。これは、幅広いアプリケーションやユースケースに対して、一般的な能力やサービスの取得と統合を一貫したエクスペリエンスで保証する横断的なレイヤーです。優れたプラットフォームは、ウェブポータル、プロジェクトテンプレート、セルフサービスAPIなど、その能力やサービスの利用と管理において、一貫したユーザーエクスペリエンスを提供します。

Atlassianによると[ 1]、「プラットフォームチームは、少しのオーバーヘッドで多数のストリームアラインド[プロダクト]チームが利用できる能力を作成します… プラットフォームチームは、ストリームアラインド[プロダクト]チームのリソースと認知負荷を最小化します… プラットフォームチームは、異なるユーザーエクスペリエンスや製品にまたがる一貫した体験を構築できます。」

マーティン・ファウラーとエバン・ボッチャー[ 2]によると、「デジタルプラットフォームとは、魅力的な社内製品として構成されたセルフサービスAPI、ツール、サービス、知識、サポートの基盤です。自律的なデリバリーチームは、このプラットフォームを活用することで、調整の手間を省き、より迅速に製品機能をリリースすることができます。」

プラットフォームがサポートする具体的な能力やシナリオは、利害関係者やユーザーのニーズによって決定されるべきです。そして、プラットフォームはこれらの必要な能力を 提供します が、プラットフォームチームがいつもそれらを 実装する 必要はないことに留意することが重要です。マネージドサービスプロバイダーや社内の専門チームがバックエンドの実装を維持する一方で、プラットフォームは、提供される実装全体に一貫性を提供し、組織の要件を満たす合理的な最も薄い層です。例えば、非常にシンプルな「プラットフォーム」は、[ 3]で説明されているように、プロバイダーから能力を提供するための標準作業手順へのリンクが記載されたwikiページである可能性があります。

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

プラットフォームは、特にクラウドネイティブアーキテクチャにとって重要です。なぜなら、それらは従来のパラダイムよりも、アプリケーション固有のロジックからサポート能力を分離するからです。クラウドのような環境では、リソースと能力はしばしば独立して管理され、カスタムビジネスコンポーネントと統合されます。このようなリソースには、データベースやオブジェクトストア、メッセージキューやブローカー、監視収集やダッシュボード、ユーザーディレクトリや認証システム、タスクランナーや差分検出器などがあります。内部プラットフォームは、これらのリソースを企業チームに提供し、アプリケーションやシステムに簡単に統合できるようにします。

プラットフォームの成熟度

最も基本的な内部プラットフォームは、パイプラインランナー、データベースシステム、シークレットストアなどの個々のサービスの確保と利用において一貫した体験を提供します。成熟するにつれ、内部プラットフォームは、ウェブアプリケーション開発やデータ分析(別名MLOps)などの主要なシナリオ向けのセルフサービス可能なテンプレートの 組成物 も提供します。

企業がプラットフォームで対応できるユースケースは、以下のとおりに進展する可能性があります。

1. プロダクト開発者は、コンピュート、ストレージ、データベース、アイデンティティ管理などのシステムを実行するために、必要に応じて能力をプロビジョニングし、すぐに使用することができます。
2. プロダクト開発者は、オンデマンドでサービススペースを用意し、パイプラインやタスクの実行、成果物や設定の保存、テレメトリーの収集などに使用することができます。
3. サードパーティソフトウェアの管理者は、データベースなどの必要な依存関係をオンデマンドで準備し、簡単にインストールして、そのソフトウェアを実行することができます。
4. プロダクト開発者は、Web開発やMLOpsなどの特定のシナリオに必要な実行時サービスと開発時サービスを組み合わせたテンプレートから、完全な環境を構築することができます。
5. プロダクト開発者やマネージャーは、自動計装と標準ダッシュボードにより、デプロイされたサービスの機能、パフォーマンス、コストを監視することができます。

個々の能力または能力セットに対して一貫性のある、コンプライアンスに準拠した体験を提供することで、内部プラットフォームは最終的に、ユーザーにとって価値のある製品をより簡単に、より効率的に提供することを可能にします。

プラットフォームの特性

プラットフォームとは何か、そしてなぜ組織がプラットフォームを構築したいと考えるのかを定義しましたので、プラットフォームの成功に影響を与える主な要素をいくつか特定してみましょう。

1. 製品としてのプラットフォーム。プラットフォームはユーザーの要求に応えるために存在し、他のソフトウェア製品と同様に、その要求に基づいて設計・進化していくべきものです。プラットフォームは、プロダクトチーム全体で最も一般的なユースケースをサポートするために必要な能力を提供し、特定のチームのみが使用する具体的な能力よりも優先すべきです。そうすることで、提供される価値を最大化することができます。
2. ユーザーエクスペリエンス。プラットフォームは、一貫性のあるインターフェースを通じてその能力を提供し、ユーザーエクスペリエンスに重点を置くべきです。プラットフォームは、ユーザーのいる場所に合わせて対応するように努めるべきであり、GUI、API、コマンドラインツール、IDE、ポータルを組み合わせる必要があります。例えば、プラットフォームは通常、アプリケーションのデプロイ能力を提供します。開発者はIDEを通じてその能力を利用し、テスターはコマンドラインツールを使用するのに対して、プロダクトオーナーはGUIベースのウェブポータルを利用する場合があります。
3. ドキュメントと導入。 ドキュメントは、ソフトウェア製品の成功に欠かせない要素です。プラットフォームから提供されるものを十分に活用するには、ユーザーにドキュメントとサンプルを提供する必要があります。プラットフォームは、ユーザーのニーズに応える適切なドキュメントとともに提供すべきです。また、ユーザーがプラットフォームのサービスを迅速かつ簡単に利用できるように、新規プロジェクトの導入を加速するツールも提供すべきです。例えば、Kubernetes上でウェブアプリケーションを構築、スキャン、テスト、デプロイ、監視するための再利用可能なサプライチェーンワークフローをプラットフォームが提供できます。このようなワークフローは、初期プロジェクトテンプレートとドキュメントとともに提供され、しばしば ゴールデンパス と呼ばれるバンドルとして提供されます。
4. セルフサービス。プラットフォームはセルフサービスであるべきです。ユーザーは、自律的かつ自動的に能力を要求し、受け取ることができる必要があります。この特性は、プラットフォームチームが、複数のプロダクトチームが立ち上がることを可能にし、必要に応じて拡張できるようにするための鍵となります。プラットフォームの能力は、上記のインターフェースを介して、必要に応じて利用でき、手動の介入を最小限に抑えることができるべきです。例えば、ユーザーはコマンドラインツールを実行したり、ウェブポータル上のフォームに入力したりすることで、データベースの要求を行い、そのロケーターと認証情報を受け取ることができるはずです。
5. ユーザーの認知負荷を軽減。プラットフォームの重要な目標は、プロダクトチームにおける認知負荷を軽減することです。プラットフォームは実装の詳細をカプセル化し、そのアーキテクチャから生じる可能性のあるあらゆる複雑性を隠蔽すべきです。例えば、プラットフォームは特定のサービスをクラウドプロバイダーに委託する場合がありますが、ユーザーはそうした詳細を一切知らされることはありません。 同時に、プラットフォームは、必要に応じてユーザーが特定のサービスを設定し、監視できるようにすべきです。プラットフォームが提供するサービスの運用は、ユーザーの責任ではありません。例えば、ユーザーはデータベースを必要とすることが多いかもしれませんが、データベースサーバーを管理する必要はありません。
6. オプションで組み合わせ可能。プラットフォームはプロダクト開発をより効率的にすることを目的としているため、障害となってはいけません。プラットフォームは組み合わせ可能で、提供される機能の一部のみをプロダクトチームが使用できるようにする必要があります。また、必要に応じてプロダクトチームがプラットフォームが提供する能力以外の独自の能力を提供し、管理できるようにする必要があります。例えば、プラットフォームにグラフデータベースが含まれておらず、製品にグラフデータベースが必要であれば、プロダクトチームがグラフデータベースを独自に準備し、運用できるようにすべきです。
7. セキュア・バイ・デフォルト。プラットフォームはデフォルトで安全であり、組織が定義したルールや基準に基づいてコンプライアンスと検証を確実にする能力を提供すべきです。

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

プラットフォームチームは、ウェブポータル、カスタムAPI、ゴールデンパステンプレートなどのプラットフォーム能力のインターフェースと体験を担当しています。一方では、インフラストラクチャーやサポートサービスを提供するチームと協力し、一貫した体験を実現します。他方では、プロダクトチームやユーザーチームと協力し、フィードバックを集め、それらの体験が要件を満たしていることを確認します。

プラットフォームチームが担当すべき業務は以下のとおりです：

1. プラットフォームユーザーの要件を調査し、機能ロードマップを計画する。
2. プラットフォームの提案する価値を市場に売り込み、支持を得る。
3. ポータル、API、ドキュメント、テンプレート、CLIツールなど、能力やサービスを利用および監視するためのインターフェースの管理と開発をする。

最も重要なのは、プラットフォームチームはプラットフォームユーザーの要件を把握し、そのプラットフォームが提供する能力やインターフェースの改善を継続的に行う必要があるということです。ユーザー要件を把握する方法としては、ユーザーインタビュー、インタラクティブなハッカソン、イシュートラッカーやサーベイ、可視化ツールによる直接的な利用状況の観察などがあります。例えば、プラットフォームチームは、ユーザーが機能リクエストを送信するためのフォームを公開したり、今後の機能について共有するためのロードマップ会議を主導したり、ユーザーの利用パターンを確認して優先順位を設定したりすることができます。

インバウンドのフィードバックと配慮されたデザインは、製品提供の一側面です。もう一方はアウトバウンドのマーケティングと支援です。プラットフォームが本当にユーザーの要件に合わせて構築されている場合、ユーザーは提供される能力を使用することに興奮を覚えるでしょう。プラットフォームチームがユーザーに受け入れられるようにする方法はいくつかありますが、その1つは、社内マーケティング活動を通じて、幅広い告知、魅力的なデモ、定期的なフィードバックとコミュニケーションセッションを行うことです。ここで重要なのは、ユーザーの現状を把握し、プラットフォームに関わり、その恩恵を受けるための旅にユーザーを連れていくことです。

プラットフォームチームは、必ずしもコンピューティング、ネットワーク、ストレージ、その他のサービスを運用しているわけではありません。実際、内部プラットフォームは、可能な限り 外部から 提供されるサービスや能力に頼るべきです。プラットフォームチームは、管理プロバイダーや社内インフラチームから利用できない場合にのみ、独自の能力を構築し、維持すべきです。その代わりに、プラットフォームチームは、プラットフォームが提供するサービスや能力に対するインターフェース（GUI、CLI、APIなど）とユーザーエクスペリエンスに最も責任があります。

例えば、プラットフォーム内のウェブページでは、アプリ用のアイデンティティをプロビジョニングするボタンが説明され提供している場合があります。その機能の実装は、クラウドホスト型のアイデンティティサービスを介して行われる場合もあります。プラットフォームチーム内部では、ウェブページとAPIを管理することはあっても、実際のサービス実装は管理しません。 プラットフォームチームは、必要な能力が他では利用できない場合にのみ、独自の能力を作成および維持することを検討すべきです。

プラットフォームの課題

プラットフォームには多くの価値が約束されていますが、実装者は以下の課題についても留意する必要があります。

1. プラットフォームチームは、プラットフォームを製品として扱い、ユーザーとともに開発しなければなりません。
2. プラットフォームチームは、優先順位と初期パートナーのアプリケーションチームを慎重に選択する必要があります。
3. プラットフォームチームは、企業経営陣の支援を求め、バリューストリームに与える影響を明らかにしなければなりません。

おそらく最も重要なのは、プラットフォームを顧客向けの製品として扱い、その成功はユーザーと製品の成功に直接依存していることを認識することです。そして、プラットフォームチームはアプリチームや他のユーザーと協力し、プラットフォームの能力とユーザーエクスペリエンスについて優先順位付け、計画、実装、改善を繰り返す必要があります。フィードバックを得ずに機能や体験をリリースしたり、トップダウンで指示を出して普及を図るプラットフォームチームは、ユーザーからの抵抗や不満に直面し、約束された価値の多くを見失うことになるでしょう。これを防ぐには、プラットフォームチームは最初からプロダクトマネージャーをチームに加え、ロードマップを共有し、フィードバックを集め、プラットフォームユーザーのニーズを全般的に理解し、それを思い浮かべる必要があります。

プラットフォームを採用するときは、まず有効にする適切な能力と体験を選択することが重要です。パイプライン、データベース、オブザーバビリティなど、頻繁に必要とされ、差別化されていない能力は、着手する良い場所となるかもしれません。プラットフォームチームは、まず、熱心で熟練した限られた数のアプリチームに焦点を絞ることです。そのようなチームからの詳細なフィードバックは、最初のプラットフォーム体験を改善します。また、それらのチームの人々は、プラットフォームの擁護者となり、後続の採用者に対してその普及に努めます。

最後に、大企業ではプラットフォームチームに対するリーダーシップサポートを迅速に得ることが必要不可欠です。多くの企業リーダーは、ITインフラを本来の価値の流れとはかけ離れた費用として認識し、ITプラットフォームに割り当てられるコストやリソースを制限しようとするかもしれません。その結果、実装が不十分になったり、期待通りの成果が得られなかったりして、不満を招くことになります。これを軽減するには、プラットフォームチームは、プロダクトチームやバリューストリームチームに直接的な影響や、両者が関係していることを示す必要があります（前の2つの段落を参照）。プラットフォームチームは、顧客に価値を提供するプロダクトチームの戦略的パートナーとして、その存在をアピールします。

プラットフォームチームの実現

これらの課題から明らかなように、プラットフォームチームは認知負荷につながるさまざまな責任に直面しています。アプリケーションチームと同様、この課題はサポートが必要なユーザーやチームの数や多様性に応じて大きくなります。

プラットフォームチームのエネルギーを、具体的なビジネスに固有の能力と体験に集中させることが重要です。プラットフォームチームの負担を軽減する方法には、次のようなものがあります。

1. マネージドプロバイダーによる実装の上に、最も薄い実行可能なプラットフォーム層(Thinnest Viable Platform)を構築することを目指します。
2. アプリケーションチーム用のドキュメント、テンプレート、コンポジションを作成するためにオープンソースのフレームワークやツールキットを活用します。
3. プラットフォームチームは、担当領域と顧客数に応じて適切な人員を配置します。

プラットフォームの成功をどう測定するか

企業は、自社のプラットフォームの取り組みが、上で述べたような価値や特性を提供できているかどうかを測りたいと考えるでしょう。また、この文書では、内部プラットフォームを製品として扱うことの重要性を強調してきました。優れた製品管理は、製品のパフォーマンスを定量・定性的に測定することにかかっています。これらの要件を満たすには、内部プラットフォームチームは継続的にユーザーからのフィードバックを集め、ユーザー活動を測定する必要があります。

しかし、内部プラットフォームの他の側面と同様、プラットフォームチームは必要なフィードバックを集めるために、最小限の労力で対応すべきです。ここでは指標を提案しますが、最初はシンプルなサーベイやユーザー行動の分析が最も有益かもしれません。

企業およびプラットフォームチームが自社のプラットフォームの影響を理解するのに役立つ指標のカテゴリーには、以下のものが含まれます：

ユーザーの満足度と生産性

多くのプラットフォームがまず求める品質は、生産性を高めるためにユーザーエクスペリエンスを向上させることです。ユーザー満足度と生産性を反映する指標には、次のようなものがあります：

• アクティブユーザーと定着率：提供されている能力の数とユーザー数の増加/減少を含む。
• 「ネットプロモータースコア（NPS）」またはその他の製品に対するユーザー満足度を測定する調査。
• SPACEフレームワーク[ 4]で説明されているような、開発者の生産性を示す指標。

組織の効率性

多くのプラットフォームが求めるもう一つの利点は、共通のニーズを多数のユーザーに効率的に提供することです。これは、ユーザーによるセルフサービスを可能にし、手動のステップや必要な人的介入を減らし、安全とコンプライアンスを保証するポリシーを導入することで、しばしば達成されます。共通の作業を削減するプラットフォームの効率性を測定するには、次のような指標を考慮してください：

• データベースやテスト環境などのサービスや能力のリクエストから実行までのレイテンシ。
• まったく新しいサービスを構築し、本番環境に導入するまでのレイテンシ。
• 新規ユーザーが製品に初めてコードの変更を提出するまでの時間。

製品および機能の提供

内部プラットフォームの究極的な目的は、顧客にビジネス価値をより早く提供することであるため、自社の製品や機能リリースに対する影響を測定することで、プラットフォームの目的が達成されていることが証明されます。GoogleのDevOps Research and Assessment (DORA) 研究所は、以下の指標を追跡することを推奨[ 5]しています。

• デプロイの頻度
• 変更にかかるリードタイム
• 障害発生後の復旧時間
• 変更障害率

一般的に、プラットフォームチームの主な目的は、インフラストラクチャやその他のITの能力を企業のバリューストリームと整合させることです。そのため、最終的には、その組織が提供する製品やアプリケーションの成功は、プラットフォームの成功を測る尺度になります。

プラットフォームの能力

これまで説明してきたように、クラウドネイティブコンピューティングのプラットフォームは、多くのサポートプロバイダーが提供する能力やサービスを組み合わせて提供しています。これらのプロバイダーは、同じ企業内の別のチームであったり、クラウドサービスプロバイダーのようなサードパーティであったりします。一言で言えば、プラットフォームは、基盤となる 能力プロバイダー から、アプリケーション開発者などのプラットフォームユーザーへと橋渡しをするものであり、その過程でセキュリティ、パフォーマンス、コスト管理、一貫したユーザーエクスペリエンスなど、望ましいプラクティスを実装し、強制します。次の図は、製品、プラットフォーム、能力プロバイダーの関係を表したものです。

この文書では、優れたプラットフォームとプラットフォームチームの構築方法に焦点を当ててきましたが、最後のセクションでは、プラットフォームが実際に提供できる能力について説明します。このリストは、プラットフォーム構築者の指針となることを目的としており、クラウドネイティブアプリケーションに一般的に求められる能力が含まれています。ただし、これまで述べてきたように、優れたプラットフォームはユーザーのニーズを反映したものです。そのため、最終的にはプラットフォームチームが、ユーザーとともにプラットフォームが提供する能力を選択し、優先順位を決定すべきです。

能力は、親能力のドメインの属性や側面である、いくつかの 機能 で構成される場合があります。例えば、オブザーバビリティには、メトリクス、トレース、ログの収集と公開機能、およびコストとエネルギー消費の監視機能が含まれる場合があります。組織内の各機能または側面の必要性および優先度を考慮してください。CNCFの今後の出版物では、各ドメインについてさらに詳しく説明される可能性があります。

クラウドネイティブコンピューティングのためのプラットフォームを構築する際に考慮すべき能力ドメインは以下のとおりです：

1. 製品や能力を確認し、利用するための ウェブポータル
2. 製品と能力を自動的にプロビジョニングするための API（およびCLI）
3. 製品内の能力を最大限に活用できる 「ゴールデンパス」テンプレートおよびドキュメント
4. サービスおよび製品の 構築とテストの自動化
5. サービスおよび製品の 提供と検証の自動化
6. ホスト型統合開発環境やリモート接続ツールなどの 開発環境
7. 機能、パフォーマンス、コストの監視を含むインストゥルメンテーションツールやダッシュボードを使用したサービスや製品の オブザーバビリティ
8. コンピューティング実行環境、プログラマブルネットワーク、ブロックストレージ、ボリュームストレージなどの インフラストラクチャ サービス
9. データベース、キャッシュ、オブジェクトストレージなどの データ サービス
10. ブローカー、キュー、イベントファブリックを含む メッセージング およびイベントサービス
11. サービスやユーザーのアイデンティティと認証、証明書と鍵の発行、静的秘密情報の保存などの アイデンティティおよびシークレット 管理サービス
12. コードや成果物の静的解析、実行時解析、ポリシーの適用を含む セキュリティ サービス
13. コンテナイメージや言語固有のパッケージのストレージ、カスタムバイナリやライブラリ、ソースコードの保存を含む アーティファクトストレージ

以下の表は、読者が各能力を既存のCNCFまたはCDFプロジェクトと関連付けて理解するためのものです。