プラットフォームエンジニアリングとはモダンな標準化のこと

マイクロサービスによって起きた「標準化、死すべき」の揺り戻しとして、イマドキの標準化を実現するのがプラットフォームエンジニアリングなんだろうな、と思っています。JJUG CCC 2023 Fallで「アーキテクチャの進化から学ぶ、プラットフォームエンジニアリングへのアプローチ」という講演をするにあたり、今更ながらプラットフォームエンジニアリングについて整理をしてみました。

クラウドさえあればOpsチームはいらない？

DevOps Topologiesに記載されているDevOps Anti-Typesでは、以下の8つのアンチタイプが記載されています。

A: Dev and Ops Silos
B: DevOps Team Silo
C: Dev Don't Need Ops
D: DevOps as Tools Team
E: Rebranded SysAdmin
F: Ops Embedded in Dev Team
G: Dev and DBA Silos
H: Fake SRE

これらは、いくつかの類型化ができるのですが、C、D、Fなどは、組織の中で特定の開発チームが独自にDevOpsに取り組む状況かと思います。

そのチームはAWSやAzureなどのクラウドサービスを利用しますが、新規に払い出されたアカウントを利用し、既存のインフラ環境とは切り離されて実現されます。クラウドサービスの利用方法は、ある程度のドキュメント上のルールはあるものの、細かいところはチームに任されています。運用も、あるレベルまではチームの中で実現しており、既存の運用プロセスとは切り離されることもあります。

つまり、DevとOpsという業務は近づいたのですが、それは特定のチームの中だけで完結しています。これはAWSやAzureなどのクラウドサービスが広がったおかげで「クラウドサービスさえあれば、全てが自動化できるので、自分たちだけでDevOps /マイクロサービスができる」という考え方から発生します（多くの日本企業では「自分たち」の中に、自部門で雇えるベンダーを含みます）。

つまり、以下のような状態です。

DevとOpsを自分たちだけで完結するのは非効率

こうした状況の問題点は、コードを書く以外の作業群が非効率になる点です。もちろん、できないことはありません。確かに、世の中にはシステム運用を支えるための豊富な機能を持ったSaaSが数多く存在しており、ターンキーで使い始めることは可能です。そのため個別のチームやシステムでの導入も簡単です。

一方で、様々なツールを仕組みを使いこなし、継続的に改善し、新しい機能に対応するのは簡単なことではありません。そのためには、それなりにスキルを持った専門メンバーを配置する必要があり、チームには相応の規模が求められます。使い始めるのは簡単だが、使いこなして効率を上げようと思うと、専門人材が必要になるのです。

組織内にプラットフォームを用意しよう

それよりも、組織内においてチームを横断してある程度の基本的な仕組みはすでに用意されている状態の方が効率的だといえます。その際の仕組みについては、その組織の特性を踏まえた上での利用方法が選定されます。例えば、認証認可、コンテナ実行環境、データベース、運用監視ツール、Gitリポジトリ、CI/CDツールなどが、ある範囲でリスト化されており、すぐに使い始められるような状態です。こうした状態であれば、どんなに小さなチームであっても、すぐに開発を開始することが可能になります。

このような組織内で整備されるプラットフォームは、Internal Developer Platform（以下、IDP）と呼ぶのが一般的のようです（他に適切な呼び方を知っている人がいれば教えてください）。自組織内の開発チーム向けに整備されたプラットフォームという言葉だと理解しています。

IDPは、開発者がセルフサービスでシステム開発や運用運用に必要な要素を設定できるもので、運用チームによって構築されているものです。What is an Internal Developer Platform (IDP)? | Internal Developer Platform では、以下のように定義されています。

内部開発者プラットフォーム (IDP) は、運用チームによって構成され、開発者によって使用されます。運用チームは、どのリソースをどの環境で、またはどのような要求で起動するかを指定します。また、アプリケーション構成のベースラインテンプレートを設定し、アクセス許可を管理します。これにより、環境やリソースのスピンアップなどの定期的なタスクを自動化し、標準を適用することでセットアップの保守が容易になります。開発チームは、構成の変更、デプロイ、スピンによって自律性を獲得します

つまり、以下のような状態です（横から刺さっているチームはOps、CCoE、SRE、DevOpsチームなど、いろいろな呼び方があります）。

なぜ、プラットフォームエンジニアリングなのか

なぜ、プラットフォームエンジニアリングが注目されたかといえば、冒頭に書いたようにマイクロサービスによってもたらされた「標準化は悪である」というムーブメントの揺り戻しではないでしょうか。

マイクロサービスを世に広めた記事「Microservices」には9つの特性があげられていますが、その1つに「Decentralized Governance（分散ガバナンス）」というのがあります。説明としては「（プログラミング言語などの）単一技術で標準化するアプローチには限界がある」「文書に定義された標準は好かれていない」といった内容です。

もちろん、この説明は正しいですが、だからと言って「標準化は悪である」というのは早計です。前述のように、システム運用を個別のチームだけでやり切るのは大変だし、運用に関わるツールや設定を個別に考える必要性もあまりないからです。

一方で、プラットフォームエンジニアリングが曖昧な言葉になってしまっている気もします。おそらく、目的が「統制」「標準化」になるとエンジニアが嫌がるから、意図的に「開発生産性」「開発者体験」みたいな言葉を使っているのかなと思っています。

どんなプラットフォームがいいのか？

IDPに必要なのは、旧来型標準化の課題であったプロセスやアプリケーション技術要素の固定化を避けながら、運用やインフラに関わる標準化を実現することです。

技術要素において最も重要なのはコンテナの採用でしょう。コンテナであれば、アプリケーション実行環境を含む内側と、それを稼働させるインフラが完全に切り離されており、コンテナの内側でどのような実装言語やフレームワークを使おうが、インフラからは同一視することが可能です。コンテナ実行向けのプラットフォームは一般化しており、各クラウドサービスに用意されているものがありますので、運用レベルによって適切なものを選択することが可能です（運用の手間を避けたいなら、Kubernetesは採用しない方が良いでしょう）。

その他、サービスの稼働や運用に必要なさまざまなツールやルールが含まれます。また、エンジニア向けのオンボーティングに必要な「ゴールデンパス」と呼ばれる文書やテンプレートの整備も必要になります。例えば、以下のようなものが含まれます。