第1回 Platform Engineering Meetupで発表した資料です。
#PFEM
PlatformEngineeringへの招待Platform Engineeringって何？ 何故今注目なの？
View Slide
Kazuto Kusama@jacopenSenior Solutions Engineer @HashiCorp JapanCo-Chair @CloudNative DaysOrganizer @PaaSJP
2012-2017 国内の通信事業者でPaaSの開発2012- PaaS勉強会のオーガナイザー2017-2021 Pivotal / VMwareで、Cloud FoundryやKubernetesのプロフェッショナルサービス およびプラットフォームチームづくりの支援2021 - HashiCorpでTerraformやVaultなどのプロダクトのソリューションエンジニア10年以上、プラットフォームに関連する仕事に携わってきましたこれまでやってきたこと
Platform Engineering、話題ですよね！
Gartnerガートナーのハイプサイクルに登場。『2026年までに、ソフトウェア・エンジニアリング組織の80%がプラットフォーム・エンジニアリング・チームを結成し、そのうち75%がセルフサービス開発者ポータルを取り入れる』と予測
そもそもPlatform Engineeringとは何か
Platform Engineeringとは決まった定義はまだないGartner:アプリケーションのデリバリとビジネス価値の創出を加速させるための、テクノロジに対する新しいアプローチプラットフォーム・エンジニアリングは、再利用可能なツールとセルフサービス機能を実装し、インフラストラクチャ・オペレーションを自動化することで、開発者のエクスペリエンスと生産性を向上させるPlatformengineering.org :クラウドネイティブ時代のソフトウェアエンジニアリング組織のセルフサービス機能を実現するツールチェーンとワークフローを設計・構築する分野プラットフォームエンジニアは、アプリケーションのライフサイクル全体の運用に必要なものを網羅する、「内部開発者プラットフォーム」と呼ばれる統合製品を提供することが多い。
Platform Engineeringとは開発者体験と生産性を向上させるためにセルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野さまざまな人の意見をまとめると、こんな感じでしょうか
背景Platform Engineeringを理解する前に、これまでの歴史を振り返ってみましょう
クラウド以前 (90s - early 2000s)Developer SysAdminクラウド登場以前は、開発者とシステム管理者が組織ごと分かれていて、アプリの公開には管理者に依頼を行う必要があったんです。組織を跨ぐのでコミュニケーションの時間がかかりますし、管理者がボトルネックになりやすい。
クラウドの登場とDevOpsDev OpsConfigureVerify Package Plan MonitorReleaseCreate PlanDevとOpsの垣根をなくし、ソフトウェアの開発とデリバリーを継続して行えるようにするアプローチ。このプロセスの中にセキュリティ対策を組み込むDevSecOpsというパターンも登場したそういった問題に対処するために、DevとOpsの垣根をなくしていこうという考えがDevOps。クラウドの登場とだいたい同じタイミングで出てきました。継続的にサイクルを続けていくという考え方がキーです。
真のDevOps“You build it, you run it”開発者が、アプリをエンドツーエンドでデプロイし、実行するDevOpsを突き詰めると、開発者が開発・テスト・デプロイまで全部やっちゃうことも可能です。ただし・・・
真のDevOps“You build it, you run it”開発者が、アプリをエンドツーエンドでデプロイし、実行するただし、多くの組織にとって現実的ではない現実のところ、それをやり切れる組織はほとんどありません。何故か
真のDevOps開発者が、アプリをエンドツーエンドでデプロイし、実行するただし、多くの組織にとって現実的ではないKubernetesBuildkitHelmDockerfileGrafanaPrometheusGitHubActionsReactNext.jsSecurityNode.jsTerraformArgoCD APMCompliance認知負荷が高すぎるこれをやり切れる人材は少ない
認知負荷の増大https://www.infoq.com/articles/platform-engineering-primer/ より引用実際、2010年初頭のPaaSの登場で下がった認知負荷が、クラウドネイティブ技術の発展と共に右肩上がりになってしまっています。
よく陥るアンチパターンOps Embedded in Dev TeamDevとOpsのサイロ化を防ごうとした結果、Devチームの中にOpsを担う人材を抱えるようになる多くの場合、幅広い知見を持つ、チームの中でもっとも価値のあるエンジニアがシャドーオペレーションを行う形になる結果として、チームの能力を最大限に発揮することができなくなるhttps://web.devopstopologies.com/#anti-typesより引用じゃあサイロに戻すかというとそれも微妙。ということで、多くの組織がこのアンチパターンにハマっていきます。
じゃあどうするか
Internal Developer Platformプラットフォームチームによって構築される、開発者のセルフサービスによる利用を可能にする基盤。さまざまな技術やツールによって構成され、コンテキストや基礎となる技術を抽象化することなく、開発者の認知負荷を軽減していくKubernetesBuildkitHelmDockerfileGrafanaPrometheusGitHub ActionsSecurityTerraformArgoCDAPMComplianceIDPDeveloperPlatform Teamself service略称IDPですが、Internal DeveloperPortalという別のものがあったり、IdentityProvider(IdP)とも紛らわしいので注意
Team Topologies価値のあるソフトウェアを素早く届けられるようにするための組織設計。4タイプのチーム定義と、3つのインタラクションモードが定義されている。Platform TeamがStream-aligned Teamに、XaaSの形で関与するのがIDPの話に近い。(実際にはもっとネストされたパターンもある)
注例では分かりやすさ優先でOSSのツールを並べているが、IDPは自前のツールやOSSに限る必要は無いパブリッククラウドを使いつつ、そのマネージドサービスを活用したゴールデンパスも普通にあり得る(むしろそっちがメジャー)KubernetesBuildkitHelmDockerfileGrafanaPrometheusGitHub ActionsSecurityTerraformArgoCDAPMComplianceIDP
IDPは分かったけど、これって別に新しい話じゃないよね？
共通プラットフォームは特に新しい話では無い業種業態問わず、ある一定の規模以上の会社であれば、共通のプラットフォームを作ろうという話が一度は出ているはず。(次世代|新)(共通|汎用|統合)(基盤|プラットフォーム)みたいな名称のプロジェクト、関与したことある人も多いのでは
Platform as a Service過去10年には「これを入れるだけで色々自動化ができる」というPaaSも数多くあった。無くなったものもあれば、今も使われているものもある。認知負荷を下げるという観点では、最高に効率がいいcf push
そのプラットフォーム上手くいきましたか？
上手くいくプラットフォーム作りは、本当に難しい● 4割の共通プラットフォームは、生まれながらに死んでいる● 4割の共通プラットフォームは、上手く運用出来ずに死んでいく● 成功するのは2割か、それ以下(注: jacopenの感覚値なので数字に根拠はありません！)
共通プラットフォームの失敗とは失敗したプラットフォーム = あまり使われないプラットフォーム
共通プラットフォームの失敗とは失敗したプラットフォーム = あまり使われないプラットフォーム何故使われないのか = そのプラットフォームに価値がないから
価値とは『誰にとっての価値か』が大事プラットフォームにとって、価値があるかないか判断をするのは『プラットフォームの利用者』 つまり 『開発者』開発者に価値を提供できなければ、そのプラットフォームは失敗している
誰に 何を どうやってプラットフォームを考えていく上で、誰に(Who)、何を(What)、どうやって(How)に分けて考えてみましょう。
誰に 何を どうやって失敗するプラットフォームはここばかり気にする
どうやって時代はマイクロサービスでしょVMは古い。今はコンテナ全社統一のセキュリティ コンプライアンス基準をリソースの利用率を向上させてコスト削減コンテナKubernetesサービスメッシュ分散トレーシングオブザーバビリティ失敗するプラットフォームの考え方はこうなんです。いろんなステークホルダーの思いをとりあえず突っ込んで、あれこれ新技術が詰め込まれたものが計画される
どうやって時代はマイクロサービスでしょVMは古い。今はコンテナ全社統一のセキュリティ コンプライアンス基準をリソースの利用率を向上させてコスト削減コンテナKubernetesサービスメッシュ分散トレーシングオブザーバビリティDeveloper別にコンテナにしなくても困ってないし、マイクロサービスにするフェーズじゃないし･･･セキュリティも、どうせあとでチェックシート記入求められるんでしょただ、顧客となる開発者の意見はこうだったりするのです。これじゃあ、使われないですよね。
プラットフォームの悲劇● 生まれながらに死んでいるパターン○ 開発者が欲しいものに全然マッチしてなかった○ 2年くらい頑張ったが、出したときには既に技術がオワコンになっていた● 上手く回せず死ぬパターン○ 特定の技術に依存してしまったため、技術が廃れるのと同時に使われなくなった○ 『プラットフォーム構築プロジェクト』が終わったらチームの半分が召し上げられてしまって、普段の運用で手一杯。だんだん時代遅れに○ コストセンターとみなされ、予算が割り振られなくなって縮小
自分の場合● 開発者の生産性を上げるため、認知負荷を下げられるプラットフォームは重要と考えていた● 簡単なコマンドでデプロイ出来るPaaSを使って、開発者に提供しようとした● 刺さる人には刺さって、期待通りの効果を上げることができた。● ただ、多くの人には刺さらず、組織全体の改善にはほとんど繋がらなかった● その後、コンテナ化の流れもあり、上手く要望に応えられないようになってしまった
自分の場合● 開発者の生産性を上げるため、認知負荷を下げられるプラットフォームは重要と考えていた● 簡単なコマンドでデプロイ出来るPaaSを使って、開発者に提供しようとした● 刺さる人には刺さって、期待通りの効果を上げることができた。● ただ、多くの人には刺さらず、組織全体の改善にはほとんど繋がらなかった● その後、コンテナ化の流れもあり、上手く要望に応えられないようになってしまったこれ自体は間違っていない便利なんだからみんなこれを使うべきだという、思い込みと押しつけライフサイクルを考慮できていなかった本当は何に困っているのか、正しく理解できていなかった
誰に 何を どうやってプラットフォームの利用者 ○○という価値を 技術ツールチェーンワークフローここにちゃんとフォーカスすることこれを継続的に回せることHowだけじゃなくて、WhoとWhatをしっかりつ突き詰めていく。それを続けていくことが重要です。
Platform as a Product● 開発者を『顧客』として考え、顧客にプラットフォームという『プロダクト』を提供していくというアプローチ● 世の中に提供されているさまざまなプロダクトと同じ管理手法を、プラットフォームにも取り込んでいく顧客PlatformProductプロダクトを提供プロダクトを提供プラットフォームチームそれをやっていくときに有用な考え方が、Platformas a Productです。あなたがプロダクトを世の中に公開するとしたら、ユーザーの調査からマーケティングから、ありとあらゆる工夫をしますよね。それを、プラットフォームにも適用するんです。
Platform as a Product顧客PlatformProductプロダクトを提供プロダクトを提供プラットフォームチームどういう価値を提供できれば使って貰えるか顧客が何に困っているかどうやってサポートしていくかどうやって教育していくかどうやって安定したチームを作るかプラットフォームによる効果がどのくらい出ているか何をいつまでに提供するか世の中のトレンドはどうなっているかプロダクトであるプラットフォームを広めていくために、こういうことを考えていく必要があります。
Platform as a Product顧客PlatformProductプロダクトを提供プロダクトを提供プロダクトマネージャープロダクトマネジメントの手法がそのまま使える。チームに専任のプロダクトマネージャーを置き、プロダクトとしてのプラットフォームの方向性を決めていくプロダクトマネジメントには、先人がたくさんいます。その知見を学んだPMを、プラットフォームチームに入れて回していきましょう。
まとめると真のDevOpsのために開発者の認知負荷を下げ、セルフサービスで利用できるプラットフォームを提供し迅速なアプリケーションの開発体験とデリバリーを実現する。そのために、顧客を正確に理解し、継続的なプラットフォームの開発体制をプロダクト開発の知見を取り入れながら作り上げていくのがPlatform Engineering
なのでちょっとクスっときたので取り上げたけど、『DevOpsオワコン、これからはPlatform Engineering』というのは明確に間違い。進化し続ける世の中の中で、本当に機能するDevOpsを実現していく延長線上にあるのがPlatform Engineering
めっちゃ大変じゃない？
めっちゃ大変じゃない？⇒めっちゃ大変ですよ
Engineeringとは何か工学とは、実際的な問題に対する効率的、経済的な解を見つけるための経験的、科学的なアプローチの応用のことであるそのために私たちは 学びのエキスパート 兼 複雑さ管理のエキスパート になる必要がある継続的デリバリーのソフトウェア工学－もっと早く、もっと良いソフトウェアを作るための秘訣より抜粋
は、プラットフォームエンジニアのみなさんが学びのエキスパート 兼 複雑さ管理のエキスパート になるために役立つ場と機会を提供します。
● 先人に学ぶ○ 言葉が流行る前から、プラットフォームエンジニアリングに取り組み、成功しているチームがあります。その知見を学びます● 失敗を学ぶ○ 共通プラットフォームに果敢にも取り組み、上手くいかなかった事例も沢山あります。どうして上手くいかなかったのか。上手くいくにはどうすれば良いかを振り返りながら学びます● マネジメントを学ぶ○ プロダクトマネジメントや人のマネジメントも重要です。そういったジャンルで活躍している人から学びます。● 技術を学ぶ○ 新しい技術を知ること、便利なツールを知ることも大事です。単に流行っているからだけでなく、技術の根底にある思想を学ぶことで、プラットフォームに生かせるようにします。今後、Platform Engineering Meetupは、こういう考えを大事に開催していきます。登壇者募集！
jacopen
line_developers_tw
yutaro527
orgachem
jkebertz
tomohisa
regonn
okunokentaro
shimashima35
megabitsenmzq
dskst
seike460
oogfranz
jacobian
jennybc
geoffreycrofte
matthewcrist
zakiyama
mojombo
jakevdp
holman
cassininazir
samlambert
keithpitt
smashingmag