CNCF Ambassadorであり、Platform Engineering TCGのオーガナイザーでもあるAtulpriya Sharmaは、プラットフォームエンジニアリングで最も重要な問いは、組織がプラットフォームを構築したかどうかではなく、開発者がその機能と実際にどのように関わっているかだと考えている。まだ正式なプラットフォームを持たない組織は、散在するスクリプトや個人の知識に依存することが多い。一方、開発者ポータル、CLIインターフェース、既成のパスを備えていても、依然としてリクエストを手作業で処理している組織もある。いずれの場合も、問題はチームがプラットフォームの機能を利用するインターフェースの成熟度にある。
この記事は、CNCFのプラットフォームエンジニアリング成熟度モデルに基づいている。このモデルは、投資、採用、インターフェース、運用、測定という5つの側面を独立して評価する。各側面には、暫定的、運用的、拡張可能、最適化という4つのレベルがある。このモデルでは、組織が一つの単位として一斉に進展するとは限らない。ある側面では進んでいても、別の側面では遅れている可能性がある。分析の焦点はインターフェース、つまり開発者が利用するテンプレート、CLIインターフェース、ポータル、APIに置かれている。
プラットフォームインターフェースの4段階
第1レベルでは、組織はカスタム手順に依存する。手作業のリクエスト、チームごとに異なるプロセス、個人から個人へ受け継がれる知識である。正式なプラットフォーム名が存在しないことは、実際にプラットフォームが存在しないことを意味しない。特定のエンジニアにデータベースのセットアップを繰り返し依頼するメッセージは、管理されていないとはいえ、現在のプラットフォームインターフェースを表している。
第2レベルは標準ツールである。ここでは、ゴールデンパスまたは舗装された道、文書、テンプレート、整合性のあるインターフェースが登場し、機能の提供と監視を行う。通常、結果は前向きに見える。採用率が上がり、新入社員のオンボーディングが速くなり、指標も改善する。しかし、想定されたパスから外れるリクエストには、依然としてプラットフォームチームの介入が必要である。そのため、インターフェースは統一されていても、自己完結してはいない。
第3レベルではセルフサービスソリューションが現れ、開発者はほとんどの定型的なリクエストをプラットフォームチームを介さずに実行できる。このレベルでは、指標だけでなくチームの行動を重視する。定型的なプロビジョニングのチケットが減少し、新しいエンジニアが直接プラットフォームを使い始め、プラットフォームチームの仕事は個別のリクエストを実行することから、それらを管理するフレームワークの改善へと変わる。筆者が挙げた例によれば、セルフサービスの設定オプションを追加した後、例外リクエストが40%から60%減少したと報告した組織がある。
第4レベルの統合サービスでは、プラットフォームの機能が日常的な作業ツールの透明な一部になる。新しいサービスを作成すると、監視、ロギング、セキュリティを自動的に統合できる。また、セキュリティポリシーは、開発者に手作業での交渉を求めるのではなく、プラットフォームを通じてルールを適用する。プラットフォームはほとんど見えなくなり、その成功は、開発者がインフラストラクチャーについて考えざるを得ない頻度の低さによって測られる。
なぜ組織は第2レベルで止まるのか
分析では、4つの反復的な問題が特定されている。1つ目はキューの問題である。ゴールデンパスは一般的なケースをカバーするが、大規模組織では例外的なケースが作業の30%を占めることがある。筆者は、Helm chartsとArgoCDを使ってKubernetesのデプロイ用ゴールデンパスを導入した小売組織の例を挙げている。6か月で採用率は85%に達したが、40件の例外ケースが蓄積し、チームの時間の60%をパス外の設定に費やすようになった。
2つ目は専門知識のギャップである。プラットフォームチームは汎用的な機能を構築するものの、専門チームのニーズに完全には適合しないことがあり、その結果、専門チームが独自の代替手段を開発する。3つ目はメンテナンスの罠である。新しい機能を追加するたびに、更新、テスト、脆弱性の発見やKubernetesのアップグレード時の修正を行う対象範囲が増える。筆者は、古いHelm chartsのインターフェース、クラウドプロバイダー固有の依存関係、ネットワークの前提条件が蓄積し、更新がリスクの高い作業になった事例を挙げている。
4つ目の問題は硬直化である。ゴールデンパスは設計時には正しかった前提を反映しているが、技術、プロセス、チームのニーズが変化すると、それらが制約に変わる可能性がある。その結果、例外やシャドーインフラストラクチャーが増殖し、プラットフォームチームは基盤となるインターフェースを改善するのではなく、個別ソリューションの工場になってしまう。
実際には何が変わるのか
第1レベルから第2レベルへ移行するために、筆者は新しいポータルを構築する前に、すでに存在するものに名前を付けることを提案している。最も頻繁に発生し、最も時間を消費し、最も標準化しやすいリクエストを把握し、カタログを拡大する前に、1つのゴールデンパスを選んで実際に改善する。
第2レベルから第3レベルへ移行するには、プラットフォームチームが必須の人的中継地点である状態をやめなければならない。そのためには、ゴールデンパスを設定可能にし、検証済みのオプションと、ハードコードされた値ではなくポリシーによって適用される制約を用意するとともに、正当なケースのための出口を提供する必要がある。分析では、リクエストを自動化する前に測定することも推奨している。メディア業界の例では、3か月間リクエストを記録した結果、リクエスト種別の20%が全体量の80%を占めることが判明した。そのため、まずこれらのパターンにセルフサービスを構築し、6か月で滞留分を60%削減した。
また、インターフェースを製品として扱う必要があり、バックエンドの機能だけを扱ってはならない。発見可能性、検証ルール、契約、予期しないリクエストへの対処方法は、すべて製品の一部である。第4レベルに近づくと、自動化は開発者が選択して実行するものから、Git、開発環境、CI/CDシステム内のポリシーによって適用されるスマートなデフォルトへと移行する。同時に、セキュリティ、データベース、監視の各チーム間で機能の所有権を、明確な契約に基づいて分担する。
certi.newsによる考察
この記事が指摘する実際の変化は、開発者プラットフォームの成功基準が、導入されたツールやパスの数から、ユーザーが得る自律性の程度へ、さらにそれらの機能がワークフローにどれほど統合されているかへと移行することである。これはプラットフォームチームにとって重要だ。表面的には採用率を高めながら、実行の負担を例外処理とメンテナンスのキューへ移している可能性があるためである。
ただし、ここで示された例と数値は、筆者が組織とのやり取りから得た観察として提示しているものであり、同じ割合がすべての組織に当てはまることを証明する独立した定量研究ではない。また、第4レベルへの到達には、契約、ポリシー、所有権の分担における成熟が前提となる。これらは、ポータルを購入したり、AIエージェントを追加したりするだけでは実現しない。結論では、重要な未解決の問いが提示されている。開発者向けに設計されたセルフサービスインターフェースは、必ずしもAIエージェントが利用できるインターフェースではない。AIエージェントは、人的なワークフローとは異なる頻度やパターンでAPIを扱うからである。そのため、マシンが利用可能なインターフェースの成熟度が、プラットフォームチームが次に測定する必要のある段階になる可能性がある。