Zenn
📄

CNCF TAGの『Platforms White Paper v1』を読んでみる

2023/07/02に公開
#
platform
#
platformengineer
idea

Platform Engineeringの勉強のために、2023年4月にCNCF TAG（Technical Advisory Group）が公開した『Platforms White Paper (v1)』を読んでみました。PDFでダウンロードすると表紙や謝辞含めても13ページ程度の長さで、非常に簡潔に要点がまとまっていますので、翻訳ソフトの力なども借りて原文を読んでみることはおすすめします。

このエントリーでは内容理解のためメモとして残すことを最大の目的としていますので、翻訳の正確性は必ずしも重視していません。また、翻訳ではなく私個人の解釈を中心に書いていますので、原文の意図とは離れている部分も多々あると思います。

このWhite Paperの概要は、2023年6月30日のPlatform Engineering Meetup #3でjacopenさんが発表されていましたので、そちらの発表を確認するのもおすすめです。私もそちらの発表を見て、原文を読んでみようと思いました。

White Paperの目次・構成

  • はじめに（Introduction）
  • なぜPlatformなのか？（Why Platforms?）
  • Platformとはなにか（What is a platform）
  • 成功するPlatformの要素（Attributes of successful platforms）
  • 成功するPlatform Teamの要素（Attributes of successful platform teams）
  • Platform実装時の課題（Challenges when implementing platforms）
  • Platformの成功はどのように計測するのか（How to measure the success of platforms）
  • Platformの機能（Capabilities of platforms）

White Paperの内容メモと所感

はじめに

Platform Engineeringがなぜ登場し、このWhite Paperが誰に向けてのものなのか、が書かれています。特に注目したいのは後者の話です。

このWhite Paperは、企業のリーダー、エンタープライズアーキテクト、プラットフォームチームリーダーが社内でプラットフォームを立ち上げる際に活用することを意図したものです。つまり、Platform Engineeringの検討（およびPlatform Engineering Teamの立ち上げ）に着手するタイミングで読むべきものということです。

また、企画担当者だけではなく、企業のリーダーにも読んでもらいたいというところがポイントです。Platform Engineeringは企業のバリューストリームを改善させる大きな効果が期待できるものの、直接的に価値を生み出すものではなく、間接的にしか価値を生み出せないもののため、Platform Engineeringの価値は見失われがちという課題がありそうです。そのため、企業のリーダーが「なぜPlatform Engineeringが必要なのか」を理解し、継続的にスポンサーとしてサポートすることが重要な成功要因であり、このWhite Paperはその理解を助けるためにも使って欲しいということのようです。

なぜPlatformなのか？

今日のクラウドコンピューティングの世界で、なぜPlatformおよびPlatform Engineeringが必要になったか、Platformのもたらす価値はなにか、という話が最初に書かれています。

過去20～30年にインフラストラクチャの柔軟性が向上すると共に、ビルドやテスト、オブザーバビリティなどの開発者向けサービスが増加し、利便性が向上するというメリットが生まれました。一方で、アプリケーション/プロダクトチームはインフラストラクチャの管理に要する責任と時間が増え、それらを管理する認知負荷が向上した結果、開発者として価値を生み出す作業（つまり開発作業という意味でしょう）に要する時間が減ってきた、という問題が発生したとのことです。

別の問題として、各チームごとにインフラストラクチャや開発者向けサービスを導入することで、同様の作業を各チームで重複してやっており、チームごとの品質面のバラツキが生じている場合があります。これらをPlatformおよびPlatform Teamとして共通化することで、開発者の認知負荷を減少させると共に、信頼性やガバナンス、セキュリティ、コストの最適化をはかる、というのがPlatformの価値ということのようです。

Software-definedの領域が広がり、それぞれのDevOpsチームが個別最適でツール選定を進められる状況は、認知負荷の限界に直面する問題があり、関心の分離をはかる必要性があることはよく理解できます。また、DevOpsチームが複数立ち上がった状態で、ツールが重複・乱立するのはITサービスマネジメント的にも好ましい状態ではなく、一定規模を超えたら[1]Platformとして共通化する取り組みは必要だと思います。

Platformとはなにか

Platformの定義が紹介されています。Platformユーザーのニーズによって機能が定義され、幅広いアプリケーションとユースケースに対して一貫したユーザー体験を提供するものがPlatformである、というのが基本的な定義のようです。

Platformのユーザーとは、企業の内部ユーザー（もう少し具体的には企業内部のDevOpsチームということでしょう）です。そのため、PlatformはInternal Platformとも表現されることがあります。Platformの目的としては認知負荷やオーバーヘッドを減少させることであり、そのニーズに応じてPlatformとして提供する機能の範疇が決まるようです。その意味では、企業の規模や複雑性に応じて、インフラストラクチャや開発サービスの管理に関わる負荷の状況は異なり、Platformで何をどこまで統合して提供するべきかは環境ごとに異なる（負荷が少ないのであればあえてPlatformで提供する必要もない）、と理解して良さそうです。

また、面白いと感じたのは、Platformは実装の一貫性と企業の要件を満たした最小限の合理的なレイヤーである、という説明です。優れたユーザー体験を提供するものとして、Webポータルやプロジェクトテンプレート、セルフサービスAPIを提供することが例示されている一方で、標準的な導入手順を記載したWikiページを提供するだけでも十分に一貫性を提供できる、という例も言及されています。ある程度の規模になってきた場合にはコミュニケーションオーバーヘッドも無視できませんので、ポータルおよびセルフサービス機能は必要になってくるステージもあると思いますが、ツール導入ありきではない点は個人的には好感を覚えました。

他に興味深いと感じたのは、クラウドネイティブアーキテクチャより以前ではアプリケーションロジックとして実装されていた部分もPlatformの範疇という説明です。例えば、メッセージキューやブローカー、オブザーバビリティ・コレクター、認証機能などがPlatformの対象としてアプリケーションチームに提供されるものとして例示されています。これらはかつてであればアプリケーションロジック内に個別に実装されていた場合もあったものの、現在はマイクロサービスとして分離されアプリケーションロジックからは外部化された状態に変わってきたものだと思います。それらもPlatformの範疇という説明ですので、クラウドネイティブ以前のインフラストラクチャとPlatformは範囲が異なるもので、今後の技術と設計思想の進化に応じてPlatformの役割はさらに拡大することも予想できます。

Platformの成熟度

Platform提供のステップと成熟度について言及されています。上述の「ニーズに応じてPlatformの提供機能は異なる」という話に対して、成熟度ステップの話は考え方が固定的であり、個人的にはあまり良いとは思えないのですが、「とはいえ、今自分たちはどのステージにいて、今後どこに向かっていけばいいか」という手がかりがないとPlatform Engineeringの検討着手も難しいと思いますので、この部分は実務的な観点を重視したサービス精神によるものだと理解しました。

基本的な提供機能としてはパイプライン、データベースシステム、シークレットストアがあり、成熟度が上がるにつれて、Web開発やMLOpsなどのシナリオに対応したセルフサービス型テンプレートの提供などにも広がるとあります。個人的には標準ダッシュボードを含むオブザーバビリティは早期に提供する機能の範疇に含まれるべき内容なのではないかと感じました。おそらく今後のWhite Paper改定でもこの部分の内容は継続的に議論されるのではないでしょうか。

成功するPlatformの要素

成功するPlatformのキーとなる要素は以下のとおりです。

No 要素 説明
1 Platform as a product Platformはユーザーの要件を満たすためのものであり、Productと同様に管理・提供されるものである。また、局所的な特殊要件よりも広範囲で一般的な要件を優先してサポートするべきものである
2 ユーザー体験 Platformは一貫したインタフェースとユーザー体験を通じて機能提供するべきである。開発者はIDEを使い、テスターはコマンドライン、プロダクトオーナーはGUIなどを好む、などの嗜好の違いに対する考慮なども含む
3 文書化とオンボーディング ユーザーがPlatformの機能を使おうと思った時に、文書と適用例は重要である。また、Platform利用希望者にとってオンボーディングサポートのツールは重要であり、ワークフローやテンプレート、文書（これらは合わせて「Golden Path」と呼ばれる）が提供されるべきである
4 セルフサービス Platformはセルフサービス可能であり、ユーザーが自律的かつ自動的に機能を使えることが望ましい。これはPlatform Teamが複数のプロダクトチームをサポートするためのスケーラビリティの観点で重要となる
5 ユーザーの認知負荷の軽減 Platformの究極の目的は認知負荷の軽減であり、Platform機能の複雑性は隠蔽すること。また、Platform提供機能の一部設定を必要に応じてカスタマイズする自由をユーザーに与える場合でも、すべての責任をユーザーに担わせるべきではない（DB機能は提供しても、DBのカスタマイズは任せても、DBサーバーの管理までは任せない等）
6 オプショナルかつ構成可能である Platformは強制的に使わされるものでもなく、一部機能だけを選択的に使えるようにするべきである。Platformが提供していない機能をプロダクトチームが独自に利用することを妨げてはいけない
7 Secure by default Platformが提供する機能はデフォルトでセキュアであること。また、企業のルールと標準に準拠するためのコンプライアンスと検証の機能を提供すること

上記の成功の要素を見ていると、ここで言うPlatformと、従来型の共通基盤の違いの性格の違いを感じます。従来型の共通基盤も、複数チームで共通で利用する機能を集約し、専門チームによるマネージドサービスとして社内に提供していた点でPlatformと類似した位置付けだったと思います。

従来型の共通基盤とPlatformで私が大きな違いだと考えるのは、従来型の共通基盤がトップダウンで機能を共通化・集約し、その利用をルール化して半強制的にしているという点です。それに対してPlatformは、「as a Product」として開発者のニーズに応じてボトムアップ型で提供内容を動的に組み換え、利用を必ずしも強制していない（Platform Team側は強制せずとも選ばれるように努力する）という点です。

これはどちらが良いということでもないと思います。ある程度強制的に共通基盤を使わせることで、ITシステム環境の一貫性の確保や費用対効果は計測しやすい部分もあるでしょう。一方で、開発者にとっての使いやすさや柔軟性が損なわれる課題を実感される方も多いでしょう。対してPlatformは、開発者にとって使いやすいものとなる特性があり、仮にPlatformが使いにくくても利用が強制されないのは魅力です。ただし、ビジネスケースとして考えた場合に、共通基盤よりも導入と維持に関する妥当性の説明が難しそうです。

成功するPlatform Teamの要素

Platform Teamの役割と実施すべき仕事の内容が書いてあります。Platform Teamの役割としては大きく2つあります。

  1. プラットフォーム機能のインターフェイスと体験を提供すること：WebポータルやカスタムAPI、Golden Pathテンプレートなど
  2. インフラストラクチャとサポートサービスを実装するチームと協力して一貫した体験を定義する共に、プロダクトとユーザーチームからフィードバックを収集し、彼らの体験が要求を満たしたものであること確認すること

ユーザーからのフィードバックについては、ユーザーインタビューや機能要求を受け付けるフォームの公開、ユーザー利用状況のレビューなどを通じてユーザーの要求について学習し、継続的に機能改善を行います。これは普通の話だと思いますが、非常にユニークなのがアウトバウンドマーケティングとアドボカシーの重要性についての話です。Platformが本当にユーザーの要求を満たしたものであればユーザーは大歓迎するはずなので、社内でのアナウンスメントやデモ、セッションなどを通じてPlatformを周知させ、利用へと導くべきだということです。なかなかここまで自信を持ってPlatformの優位性を社内にアピールする状態に至るのは大変だと思いますが、Platformは使ってもらって初めて意味を持つものですので、そのくらいの気持と行動が成功するPlatformには必要ということだと思います。

一方、Platform Teamは必ずしもコンピュートやネットワーク、ストレージやサービスを実装・提供する立場ではないと書かれています。むしろ、出来る限りサードパーティの提供するサービス等を活用し、自分たちで実装・管理するのは他に方法がない場合に限ると明確に述べられています。Platform Teamの役割は、インターフェイスとユーザー体験の部分に責任があるのであって、インフラストラクチャや開発者向けサービスを自分たちで提供することが目的ではないということです。これは、サービス個別に作られる共通基盤系の各基盤チームとは明確に立場が違う部分ですし、場合によっては共通基盤とPlatform Teamを共存させるケースもありそうです。

Platform実装時の課題

Platform実装時の3つの課題とどのようにそれを乗り越えていくべきかが書かれています。

  1. Platform TeamはPlatformをProductとして扱い、ユーザーと一緒に開発していくべき

最も重要な観点として書かれています。フィードバックなしに機能をリリースしたり、トップダウンで利用を強制することはユーザーの抵抗を招き、価値を得られる機会を取り逃すと書かれています。そのため、立ち上げ時からProduct Managerを参加させることの重要と書かれています。これは従来型の共通基盤では十分に考慮されていなかった点とも言えると思います。

  1. Platform Teamは優先度と初期パートナーとなるアプリケーションチームを選ぶべき

Platformとして最初に提供する機能の選定は迷う部分ですが、パイプライン、データベース、オブザーバビリティなどの頻繁に利用される機能から始めるのがおすすめだそうです。また、最初に利用を開始してもらうアプリケーションチームの選定も重要ポイントだそうです。最初のフィードバックはPlatformのユーザー体験を決定するのに大きな影響を及ぼすのと、後々にそのアプリケーションチームからの評判がPlatformの普及に重要になるためということです。このことから、Platformは最初はパイロット型で小さくリリースしてフィードバックループをまわし、徐々に展開を行っていくというアプローチが想定されていることがわかります。

  1. Platformは企業リーダーシップを求め、バリューストリームのもたらす価値を証明すべき

多くの企業ではITインフラは価値提供から切り離されたコストであると認識されがちで、コスト制約を貸したり、リソースを抑制したりする傾向があるため、プロダクトチームの戦略パートナーとして、最終顧客への価値を提供する不可欠な存在であることをアピールして、企業リーダーの支援を得るべきだと書かれています。Platform Teamは直接収益を生むものではないので投資対効果の企業リーダーへの説明は悩ましい部分ですが、Platform Team単体の指標だけでなく、Platformユーザーであるプロダクトチームへの影響も説明すべきという話であり、その意味ではPlatformユーザーとの密接なコミュニケーションが重要と言えます。

Platform Teamの実現

Platform Teamを作ったところで認知的負荷の課題に対応しないといけない点は変わらない点が述べられています。認知的負荷は、サポートするチームの数と要求の多様性によって増大する特性があります。そのため、ビジネス特有の機能やユーザー体験に自分たちのやるべきことの焦点を当て、そのドメインに必要な要員を確保すると共に、Thinnest Viable Platform (TVP)、つまり価値提供を実現できる最小限のサイズにPlatformがなるようにバランスを取り、オープンソースフレームワークなど再利用できるものを活用することが重要ということです。

Platformの成功はどのように計測するのか

Platformが成功しているかの計測の重要性について書かれています。

Platformが価値を提供できているかを把握することは企業の重大な関心事ですし、プロダクトマネジメントの観点でも定量的および定性的にProduct（＝Platform）のパフォーマンスを計測することは重要であるためです。そのために、継続的にユーザーフィードバックを収集したり、ユーザーの利用状況を計測をする必要があります。

具体的な観点では以下の3つのメトリクスが提案されていますが、必要最小限の労力で収集できるものに留めるべきで、以下の3つのメトリクスよりもシンプルなサーベイやユーザー行動分析が最も価値がある可能性もあると述べられています。説得力を増すために、計測指標を増やし続けてしまう行動は企業内においてよくあるパターンだと思いますが、計測と評価に力を注いでも価値の向上には直接は繋がらないという点を考えると、この指摘は考えさせられます。

ユーザー満足度と生産性

1つ目のメトリクスです。ユーザー満足度としては、アクティブユーザー数とリテンションレートが挙げられます。これにはユーザー数以外に、実際にプロビジョニングされたサービス数で計測する方法もあります。他にはサーベイでNet Promoter Score（NPS）を計測する方法もあります。開発者の生産性については、SPACEフレームワークに基づき計測する方法が提案されています[2]。

組織の効率性

2つ目のメトリクスである組織の効率性は、手作業が必要だった共通作業部分を省力化し、安全性とコンプライアンスを確保しながらセルフサービス型で提供可能になることで実現できます。そのため、環境セットアップや要求からデプロイに至るライフサイクルのリードタイムの削減として計測できます。

製品と機能のデリバリー

3つ目のメトリクスです。Internal Platformの究極的な価値は、ビジネス価値を消費者に早く届けるということなので、製品と機能のリリースに関わる影響を計測することが重要です。指標としてはGoogleのDORA (DevOps Research and Assessment) Instituteの提案するメトリクスが言及されており[3]、具体的には「デプロイメント頻度」「変更のリードタイム」「障害発生時のサービス復旧時間」「変更の失敗率」が挙げられています。DevOpsの指標ですので、Devの指標だけでなくOpsの指標も含まれている点は注目したい点です。

Platformの機能

Platformの提供する機能について書かれています。

ここまで説明してきたように、Platformは社内インフラストラクチャやサードパーティの外部サービスを組み合わせて、アプリケーションチームに一貫したユーザー体験を提供し、内部的にはセキュリティ、パフォーマンス、コストなどのガバナンスを提供するという橋渡しの役割を担っています。

Platform interfaces & Platform Capabilities
画像出典：CNCF Platforms White Paper

Platfromが提供するものは、インターフェイス（Webポータルや文書、テンプレートなど）と機能（インフラストラクチャやメッセージング、認証やオブザーバビリティなど）に大別されますが、最終的にどの機能を提供すべきかはユーザーのニーズに基づいて優先度に基づき決定されるものと改めて言及されています。そのため、この図で示されている機能を網羅的に提供することは必ずしも目標にはなりえないと思えます。

White Paperには代表的な機能とその説明およびそれらを提供するCNCF/CDFプロジェクトがまとめられた表が掲載されていますので、そちらもPlatformの提供する機能の検討の際に参考になりそうです。

脚注

  1. Platform立ち上げの目安として、人数規模としては15人を超えたDevOpsエンジニアがいるかが判断の目安になりそうです（参考：「When do you need an Internal Developer Platform (IDP)? 」） ↩︎

  2. それ以上の詳細はこのWhite Paperには書かれていません。SPACEフレームワークについては原文へのリンクが張ってありますが、日本語では「開発者の生産性を測るためのフレームワーク'SPACE'について」が参考になりそうです ↩︎

  3. リンク先は「The 2019 Accelerate State of DevOps: Elite performance, productivity, and scaling」です。メトリクスは、ダウンロード可能なレポート本文に書かれているのかもしれません（リンク先のウェブページには書かれていなさそうでした）。 ↩︎

Discussion