GitやOCIは「Source of Truth」ではなく「Source of Intent」だった
こうした経験を経て、Lajko氏のチームがたどり着いた結論は「Gitは単一の信頼できる情報源ではない」というものだ。
Gitに書かれているのはYAMLマニフェストやHelmのumbrella chartという「意図」に過ぎず、そこから参照されるプロバイダのHelm chartやコンテナイメージは外部にあり、しかもKyvernoのようなクラスタ上のコントローラがラベル付与などでリソースを書き換えてしまう。つまり本当の意図は、Gitにも、OCIにも、etcd（分散型のキーバリューストア）の実ストアにも完全な形では存在しない。
そこでチームは、GitやOCIを「Source of Truth」ではなく「Source of Intent（意図の源）」と呼び直すようになった。Gitは人間の協調作業や変更履歴の追跡に強い一方、状態ストアとしての機能はなく、外部依存とクラスタ側の変更によってドリフトが起きやすい。対するOCIは、レンダリング済みマニフェストを不変のアーティファクトとしてパッケージ化し、レジストリ経由で配布するのに向いている。“git clone”ではなく“git pull”で済むぶん同期も速い。
FluxコミュニティはこうしたGitの限界にいち早く気づき、2022年以降、望ましい状態をOCIアーティファクトとして扱う「Gitless GitOps」が広がってきた。Lajko氏はFluxのメンテナであるStefan Prodan氏が2022年に行った講演を引用し、CIパイプラインとマニフェストという構成要素自体は変わらないが、それをOCIのアーティファクトとして配置し、GitOpsエンジンがそこから“git pull”するという発想を紹介する。
こうした基盤の上で、複数のアーキテクチャパターンも確立されていった。中央のハブから複数のスポーク（クラスタ）を管理するHub & Spoke、クラスタごとに専用インスタンスを立てる方式、両者を組み合わせてArgo CDのようなGitOpsエンジンをハブに置きつつ開発者ごとのRBACを提供する方式、そしてシャーディングによる水平スケール。
エージェントベースのアーキテクチャも進化し、ハブがエージェントにpushする方式と、エージェント自身がハブから望ましい状態をpullする方式がある。特に半エアギャップ環境やセキュリティ要件の厳しい環境では、インバウンドの通信や資格情報を必要としないpullベースの方が適している。
IDP（内部開発者プラットフォーム）やBackstageをめぐる誤解
一方、2015年から2018年ごろにかけて「DevOpsは死んだ」と欧米で語られるようになった時期があった。だが実態は文化そのものが失われたわけではなく、DevOpsのツールチェーンが観測性・開発者・統合デリバリー・リソース・セキュリティという5つの「plane」を持つ内部プラットフォームエコシステムへと拡張しただけであり、多くの現場ではシステムエンジニアがDevOpsエンジニア、さらにプラットフォームエンジニアへと肩書きを変えただけだった。
それでも、同じチームに「開発者体験を高める」という新しい使命が課され、正しい抽象化レイヤーを通じてセルフサービスを提供しようと試みたが、この2年間の成果は芳しくなかったとLajko氏は明かす。
HackerNoon（Emmanuela Opurum氏調べ）のデータでは、IDP（内部開発者プラットフォーム）の構築に420万ユーロと18カ月を投じても、64％のエンジニアが結局プラットフォームを迂回してkubectlを直接使っていたという。Gartnerは2026年末までに大企業の80％がプラットフォームチームを持つと予測しているが、それだけの投資をしても定着しない現実がある。
その象徴が、Backstageをめぐる誤解だった。「Backstageを使えばいい、もうプロダクションレディだから」「ただのHelm chartでしょう」という声を、Lajko氏は数多く聞いてきたという。
しかし、実際にはBackstageはポータルを作るためのフレームワークであって、そのままで使えるIDP（内部開発者ポータル）ではない。公式のHelm chartすら存在せず（コミュニティ版はある）、細かなカスタマイズが必要で、しかもReactを書けることが前提になっている。
Spotifyがなぜこれを作ったのかという文脈を理解しないまま「デプロイするだけ」で済むと考えたことが、失敗の一因だった。何より根本的な反省は、開発者に何が必要かを一度も尋ねずに、自分たちが気に入った技術の話ばかりしていたことだったという。
