“Platform Engineering”という私的よく見かけるが意味を調べたことのない用語No.1のトピックについて書かれた本がO'Reillyからearly releaseされているので読んでる。まだ第一部しか公開されてない。
その中に出てくるアプリケーションチームがTerraformコードを管理することで起きがちな問題について共感したので紹介する
アプリケーションエンジニアリングチームがIaaSクラウドのあらゆるものを求めるようになったとき、多くの企業は、各チームに独自のクラウドインフラストラクチャを独自の構成でプロビジョニングする権限と責任を与えることが、摩擦の少ない方法だと判断しました。 実際には、これは、構成管理とインフラストラクチャプロビジョニングに精通した、兼業のクラウドエンジニアリングチームになることを意味していました。 繰り返し可能で、再構築可能で、セキュリティと検証が可能なインフラストラクチャが必要な場合は、Terraformなどの構成管理とプロビジョニングテンプレートが必要です。 したがって、アプリケーション開発チームにTerraformを学ばせることが一般的になりました。
Chapter 1. Why Platform Engineering Is Becoming Essential - Reducing Per-Application Glue(引用者訳)
アプリケーション開発者自身がインフラの自動化のコードを記述して開発のアジリティを高めるというのは現代ではよくある話。
しかし著者らの経験ではアプリケーションチームは新たにTerraformを学ぶことに積極的ではなく、特定の担当者がいつもタスクを行うようになっていった。Terraform担当大臣の誕生である（この表現は本書にでてくるのでなく単に私が呼んでる）。
書き手の少なさからタスクは次第にTerraform対応をする機能チームへの依頼という形に変化する。
機能チームはアプリケーションチームの背景を持たないので、運用を見据えた管理用のコードを構築することができるメンテナンスも煩雑化、やがてセキュリティインシデントにもつながる・・
これはTerraformに限った話でもなく一番有名なツールなので名前が登場するのだと思う。なので局所的に特定のメンバーに作業が偏りがちな条件がそろえば、CIや監視システムの担当大臣とかwebpack職人工房とか、なんでも発生しうるのだろう。
こういったアプリケーションとインフラストラクチャの複雑性から起こる問題を本書ではPlatform Engineeringの考えのもと解決をするという論調になっている。Terraform担当チームより広い枠組みの「プラットフォームを提供せよ」という具合に。
そもそもの背景として、パブリッククラウドやOSS（ミドルウェアやフレームワーク）が多様になってきてアプリケーション開発者側のニーズも複雑化しているので、アプリケーションとインフラストラクチャのグルーになるレイヤーが年々増えている。このグルー（コード）という言葉が本書のキーワードにもなっている。グルーを減らすためのエンジニアリングがPlatform Engineeringの中心と言える。
Platform Engineeringに取り組むチームはアプリケーションチームに対して抽象化したサービスを提供する制約を課すことでそれらのグルーを減らして事業のレバレッジを効かせること目指す。というのが第１章で書かれていることになる。
私の記憶では2010年代に技術基盤チームと呼ばれていた活動を思い出すが、そこからインフラ組織とDevOpsやSREとの目的や課題の違いも丁寧に比較表にしてあった。
興味深いのが「沼（Swamp）」というメタファーを使って現在の複雑化したクラウドインフラストラクチャの環境を説明している点。抜け出せなくなりどんどん深みにはまっていくような状況だろうか。「コンフィギュレーション沼」という言葉を聞いたことあるしこの比喩は良いと思った。
現バージョンでは２章の最後に生成AIモデルの開発にもPlatform Engineeringが重要だ！ という話が出てくるが、そこはちょっと強引な展開でないかと思った笑
