Platform Engineeringへの招待

by Kazuto Kusama

Slide 1

Slide 1 text

Platform Engineeringへの招待 Platform Engineeringって何？何故今注目なの？

Slide 2

Slide 2 text

Kazuto Kusama @jacopen Senior Solutions Engineer @HashiCorp Japan Co-Chair @CloudNative Days Organizer @PaaSJP

Slide 3

Slide 3 text

2012-2017 国内の通信事業者でPaaSの開発 2012- PaaS勉強会のオーガナイザー 2017-2021 Pivotal / VMwareで、Cloud FoundryやKubernetesのプロフェッショナルサービスおよびプラットフォームチームづくりの支援 2021 - HashiCorpでTerraformやVaultなどのプロダクトのソリューションエンジニア 10年以上、プラットフォームに関連する仕事に携わってきましたこれまでやってきたこと

Slide 4

Slide 4 text

Platform Engineering、話題ですよね！

Slide 5

Slide 5 text

Gartner ガートナーのハイプサイクルに登場。『2026年までに、ソフトウェア・エンジニアリング組織の80%がプラットフォーム・エンジニアリング・チームを結成し、そのうち75%がセルフサービス開発者ポータルを取り入れる』と予測

Slide 6

Slide 6 text

そもそもPlatform Engineeringとは何か

Slide 7

Slide 7 text

Platform Engineeringとは決まった定義はまだない Gartner: アプリケーションのデリバリとビジネス価値の創出を加速させるための、テクノロジに対する新しいアプローチプラットフォーム・エンジニアリングは、再利用可能なツールとセルフサービス機能を実装し、インフラストラクチャ・オペレーションを自動化することで、開発者のエクスペリエンスと生産性を向上させる Platformengineering.org : クラウドネイティブ時代のソフトウェアエンジニアリング組織のセルフサービス機能を実現するツールチェーンとワークフローを設計・構築する分野プラットフォームエンジニアは、アプリケーションのライフサイクル全体の運用に必要なものを網羅する、「内部開発者プラットフォーム」と呼ばれる統合製品を提供することが多い。

Slide 8

Slide 8 text

Platform Engineeringとは開発者体験と生産性を向上させるためにセルフサービスで利用できるツールチェーンとワークフローを設計・構築する分野さまざまな人の意見をまとめると、こんな感じでしょうか

Slide 9

Slide 9 text

背景 Platform Engineeringを理解する前に、これまでの歴史を振り返ってみましょう

Slide 10

Slide 10 text

クラウド以前 (90s - early 2000s) Developer SysAdmin クラウド登場以前は、開発者とシステム管理者が組織ごと分かれていて、アプリの公開には管理者に依頼を行う必要があったんです。組織を跨ぐのでコミュニケーションの時間がかかりますし、管理者がボトルネックになりやすい。

Slide 11

Slide 11 text

クラウドの登場とDevOps Dev Ops Conﬁgure Verify Package Plan Monitor Release Create Plan DevとOpsの垣根をなくし、ソフトウェアの開発とデリバリーを継続して行えるようにするアプローチ。このプロセスの中にセキュリティ対策を組み込むDevSecOpsというパターンも登場したそういった問題に対処するために、 DevとOpsの垣根をなくしていこうという考えがDevOps。クラウドの登場とだいたい同じタイミングで出てきました。継続的にサイクルを続けていくという考え方がキーです。

Slide 12

Slide 12 text

真のDevOps “You build it, you run it” 開発者が、アプリをエンドツーエンドでデプロイし、実行する DevOpsを突き詰めると、開発者が開発・テスト・デプロイまで全部やっちゃうことも可能です。ただし・・・

Slide 13

Slide 13 text

真のDevOps “You build it, you run it” 開発者が、アプリをエンドツーエンドでデプロイし、実行するただし、多くの組織にとって現実的ではない現実のところ、それをやり切れる組織はほとんどありません。何故か

Slide 14

Slide 14 text

真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行するただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerﬁle Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が高すぎるこれをやり切れる人材は少ない

Slide 15

Slide 15 text

認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用実際、2010年初頭のPaaSの登場で下がった認知負荷が、クラウドネイティブ技術の発展と共に右肩上がりになってしまっています。

Slide 16

Slide 16 text

よく陥るアンチパターン Ops Embedded in Dev Team DevとOpsのサイロ化を防ごうとした結果、Devチームの中にOpsを担う人材を抱えるようになる多くの場合、幅広い知見を持つ、チームの中でもっとも価値のあるエンジニアがシャドーオペレーションを行う形になる結果として、チームの能力を最大限に発揮することができなくなる https://web.devopstopologies.com/#anti-types より引用じゃあサイロに戻すかというとそれも微妙。ということで、多くの組織がこのアンチパターンにハマっていきます。

Slide 17

Slide 17 text

じゃあどうするか

Slide 18

Slide 18 text

Internal Developer Platform プラットフォームチームによって構築される、開発者のセルフサービスによる利用を可能にする基盤。さまざまな技術やツールによって構成され、コンテキストや基礎となる技術を抽象化することなく、開発者の認知負荷を軽減していく Kubernetes Buildkit Helm Dockerﬁle Grafana Prometheus GitHub Actions Security Terraform ArgoCD APM Compliance IDP Developer Platform Team self service 略称IDPですが、Internal Developer Portalという別のものがあったり、 Identity Provider(IdP)とも紛らわしいので注意

Slide 19

Slide 19 text

Team Topologies 価値のあるソフトウェアを素早く届けられるようにするための組織設計。 4タイプのチーム定義と、3つのインタラクションモードが定義されている。 Platform TeamがStream-aligned Teamに、 XaaSの形で関与するのがIDPの話に近い。 (実際にはもっとネストされたパターンもある)

Slide 20

Slide 20 text

注例では分かりやすさ優先でOSSのツールを並べているが、IDPは自前のツールやOSSに限る必要は無いパブリッククラウドを使いつつ、そのマネージドサービスを活用したゴールデンパスも普通にあり得る (むしろそっちがメジャー) Kubernetes Buildkit Helm Dockerﬁle Grafana Prometheus GitHub Actions Security Terraform ArgoCD APM Compliance IDP

Slide 21

Slide 21 text

IDPは分かったけど、これって別に新しい話じゃないよね？

Slide 22

Slide 22 text

共通プラットフォームは特に新しい話では無い業種業態問わず、ある一定の規模以上の会社であれば、共通のプラットフォームを作ろうという話が一度は出ているはず。 (次世代|新)(共通|汎用|統合)(基盤|プラットフォーム) みたいな名称のプロジェクト、関与したことある人も多いのでは

Slide 23

Slide 23 text

Platform as a Service 過去10年には「これを入れるだけで色々自動化ができる」というPaaSも数多くあった。無くなったものもあれば、今も使われているものもある。認知負荷を下げるという観点では、最高に効率がいい cf push

Slide 24

Slide 24 text

そのプラットフォーム上手くいきましたか？

Slide 25

Slide 25 text

上手くいくプラットフォーム作りは、本当に難しい ● 4割の共通プラットフォームは、生まれながらに死んでいる ● 4割の共通プラットフォームは、上手く運用出来ずに死んでいく ● 成功するのは2割か、それ以下 (注: jacopenの感覚値なので数字に根拠はありません！)

Slide 26

Slide 26 text

共通プラットフォームの失敗とは失敗したプラットフォーム = あまり使われないプラットフォーム

Slide 27

Slide 27 text

共通プラットフォームの失敗とは失敗したプラットフォーム = あまり使われないプラットフォーム何故使われないのか = そのプラットフォームに価値がないから

Slide 28

Slide 28 text

価値とは『誰にとっての価値か』が大事プラットフォームにとって、価値があるかないか判断をするのは『プラットフォームの利用者』つまり『開発者』開発者に価値を提供できなければ、そのプラットフォームは失敗している

Slide 29

Slide 29 text

誰に何をどうやってプラットフォームを考えていく上で、誰に (Who)、何を(What)、どうやって(How)に分けて考えてみましょう。

Slide 30

Slide 30 text

誰に何をどうやって失敗するプラットフォームはここばかり気にする

Slide 31

Slide 31 text

どうやって時代はマイクロサービスでしょ VMは古い。今はコンテナ全社統一のセキュリティコンプライアンス基準をリソースの利用率を向上させてコスト削減コンテナ Kubernetes サービスメッシュ分散トレーシングオブザーバビリティ失敗するプラットフォームの考え方はこうなんです。いろんなステークホルダーの思いをとりあえず突っ込んで、あれこれ新技術が詰め込まれたものが計画される

Slide 32

Slide 32 text

どうやって時代はマイクロサービスでしょ VMは古い。今はコンテナ全社統一のセキュリティコンプライアンス基準をリソースの利用率を向上させてコスト削減コンテナ Kubernetes サービスメッシュ分散トレーシングオブザーバビリティ Developer 別にコンテナにしなくても困ってないし、マイクロサービスにするフェーズじゃないし･･･セキュリティも、どうせあとでチェックシート記入求められるんでしょただ、顧客となる開発者の意見はこうだったりするのです。これじゃあ、使われないですよね。

Slide 33

Slide 33 text

プラットフォームの悲劇 ● 生まれながらに死んでいるパターン ○ 開発者が欲しいものに全然マッチしてなかった ○ 2年くらい頑張ったが、出したときには既に技術がオワコンになっていた ● 上手く回せず死ぬパターン ○ 特定の技術に依存してしまったため、技術が廃れるのと同時に使われなくなった ○ 『プラットフォーム構築プロジェクト』が終わったらチームの半分が召し上げられてしまって、普段の運用で手一杯。だんだん時代遅れに ○ コストセンターとみなされ、予算が割り振られなくなって縮小

Slide 34

Slide 34 text

Slide 35

Slide 35 text

自分の場合 ● 開発者の生産性を上げるため、認知負荷を下げられるプラットフォームは重要と考えていた ● 簡単なコマンドでデプロイ出来るPaaSを使って、開発者に提供しようとした ● 刺さる人には刺さって、期待通りの効果を上げることができた。 ● ただ、多くの人には刺さらず、組織全体の改善にはほとんど繋がらなかった ● その後、コンテナ化の流れもあり、上手く要望に応えられないようになってしまったこれ自体は間違っていない便利なんだからみんなこれを使うべきだという、思い込みと押しつけライフサイクルを考慮できていなかった本当は何に困っているのか、正しく理解できていなかった

Slide 36

Slide 36 text

誰に何をどうやってプラットフォームの利用者 ○○という価値を技術ツールチェーンワークフローここにちゃんとフォーカスすることこれを継続的に回せること Howだけじゃなくて、WhoとWhatをしっかりつ突き詰めていく。それを続けていくことが重要です。

Slide 37

Slide 37 text

Platform as a Product ● 開発者を『顧客』として考え、顧客にプラットフォームという『プロダクト』を提供していくというアプローチ ● 世の中に提供されているさまざまなプロダクトと同じ管理手法を、プラットフォームにも取り込んでいく顧客 Platform Product プロダクトを提供プロダクトを提供プラットフォームチームそれをやっていくときに有用な考え方が、 Platform as a Productです。あなたがプロダクトを世の中に公開するとしたら、ユーザーの調査からマーケティングから、ありとあらゆる工夫をしますよね。それを、プラットフォームにも適用するんです。

Slide 38

Slide 38 text

Platform as a Product 顧客 Platform Product プロダクトを提供プロダクトを提供プラットフォームチームどういう価値を提供できれば使って貰えるか顧客が何に困っているかどうやってサポートしていくかどうやって教育していくかどうやって安定したチームを作るかプラットフォームによる効果がどのくらい出ているか何をいつまでに提供するか世の中のトレンドはどうなっているかプロダクトであるプラットフォームを広めていくために、こういうことを考えていく必要があります。

Slide 39

Slide 39 text

Platform as a Product 顧客 Platform Product プロダクトを提供プロダクトを提供プロダクトマネージャープロダクトマネジメントの手法がそのまま使える。チームに専任のプロダクトマネージャーを置き、プロダクトとしてのプラットフォームの方向性を決めていくプロダクトマネジメントには、先人がたくさんいます。その知見を学んだ PMを、プラットフォームチームに入れて回していきましょう。

Slide 40

Slide 40 text

まとめると真のDevOpsのために開発者の認知負荷を下げ、セルフサービスで利用できるプラットフォームを提供し迅速なアプリケーションの開発体験とデリバリーを実現する。そのために、顧客を正確に理解し、継続的なプラットフォームの開発体制をプロダクト開発の知見を取り入れながら作り上げていくのがPlatform Engineering

Slide 41

Slide 41 text

なのでちょっとクスっときたので取り上げたけど、『DevOpsオワコン、これからはPlatform Engineering』というのは明確に間違い。進化し続ける世の中の中で、本当に機能するDevOpsを実現していく延長線上にあるのがPlatform Engineering

Slide 42

Slide 42 text

めっちゃ大変じゃない？

Slide 43

Slide 43 text

めっちゃ大変じゃない？ ⇒めっちゃ大変ですよ

Slide 44

Slide 44 text

Engineeringとは何か工学とは、実際的な問題に対する効率的、経済的な解を見つけるための経験的、科学的なアプローチの応用のことであるそのために私たちは学びのエキスパート兼複雑さ管理のエキスパートになる必要がある継続的デリバリーのソフトウェア工学－もっと早く、もっと良いソフトウェアを作るための秘訣より抜粋

Slide 45

Slide 45 text

は、プラットフォームエンジニアのみなさんが学びのエキスパート兼複雑さ管理のエキスパートになるために役立つ場と機会を提供します。

Slide 46

Slide 46 text

● 先人に学ぶ ○ 言葉が流行る前から、プラットフォームエンジニアリングに取り組み、成功しているチームがあります。その知見を学びます ● 失敗を学ぶ ○ 共通プラットフォームに果敢にも取り組み、上手くいかなかった事例も沢山あります。どうして上手くいかなかったのか。上手くいくにはどうすれば良いかを振り返りながら学びます ● マネジメントを学ぶ ○ プロダクトマネジメントや人のマネジメントも重要です。そういったジャンルで活躍している人から学びます。 ● 技術を学ぶ ○ 新しい技術を知ること、便利なツールを知ることも大事です。単に流行っているからだけでなく、技術の根底にある思想を学ぶことで、プラットフォームに生かせるようにします。今後、Platform Engineering Meetup は、こういう考えを大事に開催していきます。登壇者募集！