はじめに

こんばんは、ACS事業部の吉川です。
PlatformCon 2023 の気になるセッションを取り上げるブログとして、私からは 「Platform as Code: Simplifying developer platform design with reference architectures」 というセッションを取り上げたいと思います。

platformcon.com

セッション概要

このセッションは、現代の複雑になりすぎた環境とそれに伴う認知負荷の向上に対する解決策を、具体的なリファレンスアーキテクチャを示しつつ解説するという内容です。

アプリケーションの実行基盤としてはAWS上のEKSを使うというシナリオでしたが、特徴的なポイントとしては Humanitec社の Platform Orchestrator というプロダクトを用い、アプリケーション実行基盤の抽象化 を行っているという点が挙げられます。

アプリケーション実行基盤の抽象化

Humanitec の Platform Orchestrator がどんなものかという点については、公式YouTube動画があるのでこちらを観るとわかりやすいでしょう。

www.youtube.com

私なりの理解としては以下のように捉えています。

アプリケーションを動かすためには、

環境（パブリッククラウドやオンプレミス）
基盤（Kubernetesやデータベースの種類）
アプリケーションのデプロイ（Podを何個配置する、スペックはどうする etc...）

といったことを決定しなければいけません。現代的なやり方では、クラウド上のリソース作成には Terraform/Bicep/CloudFormationといったInfrastracture as Code、アプリケーションのデプロイにはKubernetesのマニフェストを記述するのが一般的になりつつあるでしょう。
では、これらを全てアプリケーション開発者が行うと考えたとき、覚えなくてはいけないこと、考慮すべきポイントがどんどん増えていき、肝心のアプリケーション開発のスピードは落ちていってしまいます。いわゆる 認知負荷の増大 の問題と言えるでしょう。

Humanitec の Platform Orchestrator はこの問題に対し、アプリケーションの実行に必要な情報を抽象化する というアプローチを可能とするものです。
このアプリケーションの実行に必要な情報、例えばコンテナイメージの名前や利用するデータベースの種類などといった最小限の情報を記述するのみで完結させてしまう、ということです。この最小限の情報を指して Score (スコア/楽譜) と表現しています。
当然このScoreに記述された最小限の情報では、実際のデプロイの情報としては不足しています。
ではどうするか。Platform Teamがあらかじめ定義したデータと組み合わせることで不足しているパラメータを補っています。
以下の図のようなイメージです。それぞれのチームからの入力情報を合成し、Orchestratorが基盤とアプリケーションのデプロイを担う、という形です。

※このツールを使ったことがあるわけではないので、詳しい方からのツッコミなどあればぜひご指摘お願いします。。。

役割分担

本記事で皆さんにお伝えしたいことは、「Humanitec の Platform Orchestrator すごい！」ということではありません。（もちろんPlatform Engineeringを体現する優れたツールだとは思うのですが、話の本筋ではない、ということです）
肝心なのは 開発チームとプラットフォームチームの役割分担 を適切に行うことであると考えます。
開発チームはアプリケーションの実行に必要なポイントのみを意識することで、認知負荷を低減させ開発効率の向上を狙います。
一方プラットフォームチーム側は、抽象化されたレイヤーを介すことで、ガバナンスを効かせた標準的な環境を公開することが可能となります。
Platform Engineeringにおいて大事なのはどんなツールを使うかではなく、適切な役割分担を行う事でそれぞれのチームの効率を上げることです。ツールはあくまでその分担を行うための道具にすぎないと私は考えます。