ACS事業部 亀崎です。一応Star Wars世代なので5月4日はちょっとだけ特別な日。 そんな日に、Platform Engineeringについて掘り下げてみたいと思います。
本ブログでは何度か「Platform Engineering」について取り上げてきました。
今回はCloudの実行環境をプロビジョニングするケースを例に、Platform Engineeringのポイントについて考えてみたいと思います。
オンプレミスやCloud上のリソースをプロビジョニングする場合、従来は以下のようなモデルになっていたのではないかと思います。
Stream-aligned Team（開発チーム）はPlatform Team（インフラチーム）に運用環境（実行環境）の提供を依頼します。Platform Teamは依頼内容に沿って実行環境を作成し、それをStream-aligned Teamに払い出し、Stream-aligned Teamはこの環境上に開発したアプリケーションをデプロイして利用します。通常この実行環境はPlatform Teamが所有し、その運用に責任を持ちます。
従来はこの方法で十分に対応できていましたが、ビジネス実現のスピードをあげるためにアジャイル開発・マイクロサービス設計が取り入れられ、Platform Teamに依頼し環境を払い出してもらうフローではビジネス実現のためのフローが滞りがちになるという状況が発生しました。このために考えられたのがDevOpsであり、その改善型のPlatform Engineeringです。Platform Engineeringの中心にあるのは「依頼」ではなく「セルフサービス」による環境のプロビジョニングです。Stream-aligned Team（開発チーム）自身が実行環境をプロビジョニングし、その環境の運用も一定の責任を持つようにすることでした。
ではそうした「セルフサービス」はどのように実現するのでしょうか。個々のStream-aligned Teamがプロビジョニングのやり方を考えていては効率がよくありません。 次の図のように、Platform Teamがそのプロビジョニングのやり方をStream-aligned Teamに提供することで、Stream-aligned Teamが「セルフサービス」でそれを実行する、そうしたやり方が考えられます。
Platform Teamはプロビジョニングのやり方を記述したスクリプトやIaCファイルのコピーをStream-aligend Teamに提供します。そしてStream-aligned Teamがその内容を一部自分たちの要件に合わせて修正し、プロビジョニングします。つまり、このファイルの所有権はStream-aligned Teamに移ります。環境そのものの所有権もStream-aligned Teamに帰属します。
これで、Platform Engineeringで言われている「セルフサービス」やStream-aligned Teamによる「運用」が実現できます。
しかしこれで十分でしょうか。 もし、Platform Teamがプロビジョニング後に何かを追加・変更したい、と考えた場合はどうでしょうか？プロビジョニング用のファイルはすでにStream-aligned Team側に所有権が移っており、変更することが難しくなります。またそのファイルの修正ができるとしても、複数のStream-aligned Teamにそうしたファイルを配布している場合は、配布した数だけ更新も行っていかなければなりません。 また、Cloud側のバージョンアップ等の追従はどうでしょうか？運用方法の変更等はどうでしょうか。そうした変更をそれぞれのStream-aligned Teamができるでしょうか。 できることならStream-agligned Teamはビジネスの実現に注力したいものであり、その環境維持はできるだけ簡単にしたいものです。せっかく簡単にプロビジョニングできたとしてもその後の運用に手間がかかっては、Platform Engineeringの効果としては不十分です。
そこで、今回のタイトルである「共同責任モデル」と「関心事の分離」が重要になります。 概念としては次の図のようになります。
素早いビジネス実現、アジャイル開発という点ではStream-aglined Teamが一定の運用を担うべきです。しかし、実行環境のすべての運用を担う必要はありません。Cloudサービスで一般化したようにPlatform TeamとStream-aligned Teamの「共同責任モデル」を採用するべきだと思います。Platform Teamはチーム横断的な実行環境そのものの運用方法に責任を持ち、そうした情報やツールをStream-aligned Teamに提供します。環境の運用そのものまで責任を持つのか、情報やツールの提供に留めるのかは組織ごとに「共同責任モデル」として規定すればよいと考えます。
そして「共同責任モデル」を実現するために、スクリプト・IaCファイルで「関心事の分離」して定義できるようにします。Platform Teamが責任を持つ部分についてはPlatformTeamがそのファイルを管理し、Stream-aligned Teamはそれぞれのチームが責任を持つ部分のみを定義したコンフィグレーションファイルとして所有する。プロビジョニングする際は両者のファイルの最新バージョンをマージした形で実行します。こうすることで、後日Platform Teamが内容を更新する場合でも、それぞれのStream-aligned Teamでプロビジョニングを再実行するだけで適用することができるようになります。
こうした関心事の分離の実現するやり方が先日紹介した KubeVela やTerraformにおけるModule ではないかと考えています。
「責任共有モデル」も「関心事の分離」もすでに確立された一般的な概念です。そして KubeVela やTerraform Moduleなどの技術を利用して、その概念も実現できるものとなっています。
Platform Engineeringのやり方の１つとして、実際のツールなどを利用した形でこうした内容をもっとわかりやすく適用できるようになれば、と考えています。 そうした内容を今後またこのブログでご紹介したいと思います。
それでは最後にこの日のお約束の言葉を（これを言いたかっただけです）
May (the) force(4th) be with you.
