はじめに

昨今、様々なところで耳にする Platform Engineering。
一過性の流行り言葉で消えていくようなものではなく、今後の組織のあり方にも関わってきそうな様相が見えてきています。
そんな Platform Engineering について、登場の歴史的な背景を調べつつ、目指すべきゴールとその道筋を考察してみたいと思います。

登場の背景

増える開発エンジニアに求められる仕事

コンテナなどクラウドネイティブの浸透により、開発、インフラ、運用の垣根が曖昧になってきています。謂わゆる DevOps です。
昔はプログラムコードをインフラ担当者に引き渡すことで手離れできていたことも、今では基盤となるインフラレイヤーも、プログラムコードとどうようにコードで制御することも増えてきています。
そのようなモダナイズに伴って、CI/CD パイプラインの構築、インフラレイヤの進化への追従、セキュリティ対策などなど、やるべきことが増えています。

大変わかりやすいグラフがあったので引用させていただきますが、カテゴリも内容も急速に増え、高度化しています。

これは進化であり、知的好奇心を満たすネタを提供してくれると同時に、認知負荷が上がってくることで、開発エンジニアが本来やりたかった魅力的な機能の開発や、スピーディーな機能追加といったことを妨げることにもなりかねません。

Two-Pizza Teams

さらに DevOps では、小規模なチーム構成が向いていると言われます。
Amazon 社で取り入れられているもので、チームの規模は２枚のピザで足りる範囲（5-8 名）が望ましいとのことです。

チームが小規模化することで、認知負荷が量産されることになります。
各チームそれぞれで、CI/CD のパイプライン構築や、セキュリティ対策の検討、インフラレイヤに対する選定が行われることになります。

なお、認知負荷には以下の３種類があります。

  • 課題内在性負荷 … 複雑な作業に対する認知負荷。
  • 課題外在性負荷 … 直接、関係ない認知負荷。
  • 学習関連負荷 … 適切な認知負荷。

ここで問題視している認知負荷とは、例えば、パイプライン構築をするためにCI/CDツールの検証や評価といった課題内在性負荷であったり、セキュリティ対策を検討する際の守るべきガイドラインを探すような課題外在性負荷にあたります。

また、チームごとの作業は、サイロ化を引き起こしがちです。
チームによって、例えば CI/CD に Circle CI を採用したり、GitOps + ArgoCD を採用したりマチマチになりえます。
これが、チームが担うサービス特性を最大限考慮した結果であれば大きな問題ではないですが、担当者の好みやこれまでの経験のみでそうなることもままあります。
さらには、セキュリティ対策などが意図せずに漏れてしまうようなことも起こりえます。

共通していることがあるはず

各 DevOps チームで行っていることのうち、共通した事項を横断的に受け持つチームを作ることで、この課題を解決できるかもしれません。これが、Platform Engneering です。

専任に集約することで、底上げにもなりえます。この Platform Engneering においては、SRE などの運用やビジネスチームなど様々な部門・ロールのメンバーが横断的に関わることで、組織のコラボレーションが活性化するメリットもあります。

Platform Engineering の目指すもの

このように、Platform Engneering は、開発エンジニアチームに対して価値をもたらします。
DevOps のモダナイズ化に伴う副次的な作業と学習にかかる時間とストレスを最小化します。

どのようなことをするのか？

Platform Engneering を実現するために、以下のようなことが望まれます。

保守性の高いデプロイ先の提供

Platform Engneering によって、アプリケーションが動く共通基盤を提供することでインフラレイヤの構築を開発エンジニアから引き剥がすことができます。インフラレイヤの運用に対しても同様です。
様々な種類のシステムをデプロイできる必要があることから、汎用性の高い k8s が採用されることが多いです。

セキュリティの担保

プラットフォーム側に予め仕込んでおくことで、システム共通で担保すべきセキュリティ対策を施すことができます。
また、アプリケーションレイヤで対応すべきことをポリシーとして提供、モニタリングします。

Platform Engneering の中でセキュリティは、ガードレールと表現されることが多いです。
Platform Engneering によって、開発エンジニアが走りやすい道を提供し、その安全をガードレールの形で提供します。

ドキュメントの集約管理

よくある誤ったアジャイル開発の理解としてドキュメント不要論がありますが、システムの安定した運用や保守のためにはドキュメントは必要です。
Platform Engneering で、必要な情報を不足なく記載できるようにガイドすることで、開発エンジニアが不要で膨大なドキュメントを書くことを防ぎます。

Platform Engineering の実現

その実現のために、「ゴールデンパス」を提供します。

ゴールデンパス

CNAD (Cloud Native App Delivery) では、以下のように定義されています。

Capability Description Example CNCF/CDF Projects
Golden path templates and docs Templated compositions of well-integrated code and capabilities for rapid project development. ArtifactHub

よくあるタスクのためのセルフサービステンプレートと、Google Cloud の Blog では訳してくれています。わかりやすい！
IaC のテンプレートや、k8s の YAML、ポリシーガードレールなどがテンプレートとして提供されます。

ゴールデンパスにより、基盤を運用する SRE チームはモニタリング方式を統一したり、セキュリティエンジニアが一元管理することでガバナンスをきかすなど効率的かつ効果的なプラットフォーム運用が実現できます。

IDP と IDP

Platform Engineering では、２つの IDP が存在します。
Internal Developer Portal と Internal Developer Platform です。
ややこしい。。。

Platform Engineering で提供するプラットフォームが、Internal Developer Platform で、ユーザーである開発エンジニアは、Internal Developer Portal を介して利用します。

Internal Developer Platform には以下のような機能が期待されます。

  • アプリケーションの構成管理
  • インフラストラクチャのオーケストレーション
  • 環境の管理
  • デプロイメントの管理
  • ロール単位のアクセス制御

Internal Developer Portal には、Backstage, Skooner, Ortelius のようなものがあります。
Backstage がデファクトスタンダードになりつつあるようです。

Platform Engineering のロードマップ

以上のような Platform Engineering を構築するためには、以下のようなプロセスになると考えます。

  1. システムが稼働するシステム群の把握
  2. システム群の（ほぼ）全てに共通するシステム要件の汎化と、セキュリティ、運用要件の設計
  3. 汎化した共通プラットフォームの構築
  4. プラットフォームにデプロイする作業の効率化
  5. UI、セルフサービスの提供

とくに最初のシステム群の把握は重要です。
Platform Engineering が受け持つ組織によって、効果が最大限に出るプラットフォームは異なります。
開発エンジニアのニーズを広く正確に汲み取って、適切に優先度を付けながら効果的な対応を行なっていく必要があります。

長い道のりですが、一通り終わらないといけないものでもないです。
また、ウォーターフォールでなく、アジャイルやスパイラル的に部分的に行なっていって成長させていくこともできます。

まとめと考察

この記事を読んでいただいた方の中には、とくに後半の方でこんなこと本当にできるのだろうか？自身の組織にはそぐわないんじゃないか？と思われた方も居られるかも知れません。
事実、セルフサービスや Internal Developer Portal の開発・運用コストをペイするためには、相当数のユーザーとなる DevOps チームが必要となります。

ただし、Platform Engineering とは、先に述べたロードマップの完遂されないと効果がないものではありません。事実、アンチパターン的に以下のようなことも挙げられています。

  • 一気にゴールを目指さない。燃え尽きる。
  • 利用の強制はしない。利用したいと思われるものを提供する。

まずは、組織の分析を行い今後の本格導入に備えることでも効果はあります。
実際、ドキュメントフォーマットの統一化など、すでに行われて成果が上がっている組織もあると思います。
また、まずは自分のチームの範囲だけでも、開発とプラットフォームを切り離してみても気付きが得られるかも知れません。
表現としては意義を持たれる方も居られるかも知れませんが、私はそれも立派な Platform Engineering と考えます。
頭でっかちにあれこれと言葉の定義にとらわれて、行動を起こさないよりも、「Fail Fast!」

参考

https://www.infoq.com/articles/platform-engineering-primer/
https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html
https://www.gartner.co.jp/ja/articles/what-is-platform-engineering
https://tag-app-delivery.cncf.io/whitepapers/platforms/
https://cloud.google.com/blog/ja/products/application-development/golden-paths-for-engineering-execution-consistency