Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Platform Engineeringへの招待

Platform Engineeringへの招待

第1回 Platform Engineering Meetupで発表した資料です。

#PFEM

Kazuto Kusama

March 10, 2023
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

Transcript

  1. Platform
    Engineeringへの
    招待
    Platform Engineeringって何? 何故今注目なの?

    View Slide

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

    View Slide

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

    View Slide

  4. Platform Engineering、話題ですよね!

    View Slide

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

    View Slide

  6. そもそもPlatform Engineeringとは何か

    View Slide

  7. Platform Engineeringとは
    決まった定義はまだない
    Gartner:
    アプリケーションのデリバリとビジネス価値の創出を加速させるための、テクノロジに対する新しいアプロー

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  17. じゃあどうするか

    View Slide

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

    View Slide

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

    View Slide


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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  38. Platform as a Product
    顧客
    Platform
    Product
    プロダクトを提供
    プロダクトを提供
    プラットフォームチーム
    どういう価値を提供できれば
    使って貰えるか
    顧客が何に困っているか
    どうやってサポートしていく

    どうやって教育していくか
    どうやって安定したチームを
    作るか
    プラットフォームによる効果
    がどのくらい出ているか
    何をいつまでに提供するか
    世の中のトレンドはどうなっ
    ているか
    プロダクトであるプラットフォームを広めて
    いくために、こういうことを考えていく必要
    があります。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  42. めっちゃ大変じゃない?

    View Slide

  43. めっちゃ大変じゃない?
    ⇒めっちゃ大変ですよ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide