先日行われた「Platform Engineeringへの招待」という発表がとても話題になりました。この発表を見て以下２点について考えてみました。
- Platform EngineeringはSREを変えるのか
- Platform Engineeringは自組織のSREを変えるのか
Platform Engineeringの考えが（特に国内の）SREを変えるのでしょうか。結論としては変えないと思っています。その理由について記載していきます。
まずPlatform Engineeringの定義を発表スライドを引用させていただきながら簡単にご紹介します。一般的な定義はなく発表者の一つの解釈となります。まずはDevOpsについての説明です。
しかし多くのツールの活用を前提とする昨今では真のDevOpsは多くの組織で現実的ではないと主張しています。
そこで開発者の認知負荷を下げるためのプラットフォームが必要になります。そのプラットフォームはプロダクト開発のように開発者をユーザとして扱い、本当に必要で使われるものを作るべきだと主張しています。以下が当発表におけるPlatform Engineeringの定義です。
ではこのPlatform Engineeringの考えが国内のSREの考え方を変えるのでしょうか。私は変えないと思っています。なぜならSREは多様化しており、すでにPlatform Engineeringと似た考えを持つSREが存在するからです。
例えばマネーフォワードさんのPlatform SREやfreeeさんのPlatform/Enabling SREです。
より一般化した形としては7種類のSRE実践パターン - 株式会社X-Tech5の「6.プロダクト・サービスを提供する」や「7.プラットフォームを提供する」あたりのパターンが近いと思います。このような理由から特に大きな変化は起きないというのが個人的な意見です。
一方で、自組織のSREについては変わるかもしれないと思っています。（個人の妄想でこの整理を元にメンバとディスカッションしてみるつもりです。）
自組織SREのビジョンは以下です。
目指すのは真のDevOpsです。発表の中では信頼性には焦点を当てていませんが、Devと信頼性向上を目指すSREの垣根をなくすという意味で本質は同じだと思います。
そのため開発者が全部を担う真のDevOpsが多くの組織では現実的ではないという考えは大切だと思っています。理想を描きつつも現実に即した施策を実施するためにも重要なポイントです。
今まで基本的には民主化を意識しており、SREだけが触れるものを作らないという思想を持っていました。ただ、現実的には信頼性をセルフサービスで向上するプラットフォームをデザインする選択肢も必要なのではないかと考え始めています。引き続きチームメンバや開発者と話しながらより良い姿を模索していきたいです。
ポイントは開発者の認知負荷総量だと思います。Platform Engineeringでは認知負荷を下げるためにプラットフォームを作ることが前提にあります。抽象化した認知負荷量が多ければ、それらを実際に把握する専任のエンジニアも必要となるでしょう。
発表の中では認知負荷が高い一例としてKubernetesとDockerを挙げていました。一例ではありますがコンテナ開発のデファクトともいえるこれらプロダクトは大きな要因になっていると思います。これらを本当に素晴らしい抽象度で汎化したサービスがあります。はい、みんな大好きCloud Runです。
Kubernetesも好きな私の感覚で言うと要件さえ合えばかなりの認知負荷削減が実現できます。一応要件が合えばと書きましたが、個人的な意見を言うと本当に要件が合わないシステムは少ないのではないかと思ったりもします。Cloud Runを活用することで認知負荷観点では大きく削減できます。そこに専任エンジニアはいりません。Cloud Runは一例に過ぎませんがクラウドサービスにより今後も開発者の認知負荷を下げることでPlatform Engineeringが流行らない未来もあるのではないかと思ったりはします。
