MicrosoftのPlatform Engineeringガイドを読んで実際になにかやってみた

Slide 1

Slide 1 text

MicrosoftのPlatform Engineeringガイドを読んで実際になにかやってみた 1

Slide 2

Slide 2 text

● 自己紹介 ● プラットフォームエンジニアリングとは ○ 背景 ○ 補足：プラットフォームエンジニアリングの誤解 ○ 概要 ○ 要するにどういうこと ○ もうちょっと踏み込んで ● 内部開発者ってなんですか ○ 内部開発者とは ○ 2つのIDP ● ゴールデンパスとか認知負荷ってなんですか ○ ゴールデンパスとは ○ ゴールデンパスを作るとどうなるか ○ ゴールデンパスを作るタイミング ○ 認知負荷とは ○ 補足：認知負荷にまつわる話話すこと 2 ● プラットフォームエンジニアリングの原則 ○ 顧客に優先順位を付ける ○ 製品マインドセットを採用する ○ セルフサービスによる強化 ○ 検出可能性を向上させる ● で、具体的になにしたらええの ○ ドキュメントを整理する ○ 問題領域を定義する ○ プラットフォームチームを構築する ○ 開発者テンプレートを作る ■ 具体例1 ■ 具体例2 ■ 具体例3 ■ 具体例4 ● まとめ ● Tips

Slide 3

Slide 3 text

自己紹介 3 Kento.Yamada ● クラウドの運用分析・MSP向けのシステム開発・社内技術者向けの技術提供 ● github＠ymd65536 ● Microsoft MVP for Developer Technologies（2024年〜） ● 他 ● Google Cloud Partner Tech Blog Challenge 2023 Cloud AI/ML 部門受賞 ● LAPRAS OUTPUT AWARD 2024 01

Slide 4

Slide 4 text

プラットフォームエンジニアリングとは 4

Slide 5

Slide 5 text

“自分で作ったものは自分で運用する” というアプローチは、複雑な現代のソフトウェアスタックではもはや実現不可能 5

Slide 6

Slide 6 text

背景 6 求められている技術スタック・概念が多い。複雑化！

Slide 7

Slide 7 text

背景 7 求められている技術スタック・概念が多い。幅広い専門分野における熟練した技術が必要コンテナネットワークセキュリティ DevOps 仮想化クラウド CI/CD マイクロサービス AI 機械学習 IaC DR対応データベースデータ分析 QA 設計マネジメント自動テスト可用性

Slide 8

Slide 8 text

背景 8 求められることが多すぎる！1人何役こなすんだ！コンテナネットワークセキュリティ DevOps 仮想化クラウド CI/CD マイクロサービス AI 機械学習 IaC DR対応データベースデータ分析 QA 設計マネジメント自動テスト可用性

Slide 9

Slide 9 text

背景 9 技術が増えると生産性が上がるかというと… 技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術

Slide 10

Slide 10 text

背景 10 技術が増えると生産性が上がるかというと…そうでもない生産性要因：学習コストの増加、役割の多様化、コミュニケーションコストの増加技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術

Slide 11

Slide 11 text

背景 11 技術が増えると生産性が上がるかというと…そうでもない生産性つまりは認知負荷が高いので生産性が下がっている！技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術技術

Slide 12

Slide 12 text

背景 12 人を増やして生産性を上げればイイかというとなかなかそうもいかない！コスト

Slide 13

Slide 13 text

コスト認知負荷背景 13 そもそも認知負荷が高いことが原因なので人を増やすのは逆効果そして、必ずしも生産性が上がるとは限らない。

Slide 14

Slide 14 text

背景 14 認知負荷を下げつつ、生産性を上げる方法としてプラットフォームエンジニアリングが生まれた。「みんなで共通プラットフォームを構築して生産性を上げていこうぜ」という取り組み簡単にいえば 👉プラットフォームエンジニアリング

Slide 15

Slide 15 text

補足：プラットフォームエンジニアリングの誤解 15 Web検索でだいたいの情報は出てくる。それこそAIに聞けば、生産性の問題は解決できるのでは？プラットフォームエンジニアリングは組織内で標準化されたベストプラクティスを簡単に利用できるようにしていく活動（とも言える） 👉「技術的な観点で調べればできる」や「AIに聞けばよい」という話ではないこと 👉「組織のポリシーに沿っているか」という観点があること 👉オンボーディングの観点でいえば、誰もが想定された開発環境で開発ができること

Slide 16

Slide 16 text

プラットフォームエンジニアリングとは 16 引用：プラットフォームエンジニアリングとは | Microsoft Learn なにいってんのかまったくわからない。つらい。

Slide 17

Slide 17 text

要するにどういうこと 17 プラットフォームエンジニアリングの活動は組織の大きさを問わない。内部開発者の負担が軽減される活動内部開発者のエクスペリエンスを向上させる活動サービスを提供するまでにかかる時間を最小限にする活動

Slide 18

Slide 18 text

もうちょっと踏み込んで 18 ● 内部開発者のニーズを特定したうえで最小限のセルフサービスを実装すること ● 内部開発者が自身の作業を自己解決できるようにすること ● 内部開発者を主軸とした開発プロセスを定義してゴールデンパスを作ること ● 内部開発者が再利用可能なことを低い認知負荷ですぐに活用できるようにすること内部開発者？ゴールデンパス？認知負荷？

Slide 19

Slide 19 text

内部開発者ってなんですか 19

Slide 20

Slide 20 text

内部開発者（Internal Developer）とはプロダクトやサービス開発に携わる/関わる者として定義される。 ※必ずしも開発者（ソフトウェアデベロッパー）とは限らないところがポイント ● デザイナー ● プロジェクトマネージャー ● 運用担当者 ● エンジニア（種類は問わない） ● データサイエンス ● etc 内部開発者はポータルを通してプラットフォームを操作する。 20

Slide 21

Slide 21 text

2つのIDP 21 内部開発者プラットフォーム内部開発者ポータルユーザーインターフェイス基盤内部開発者ポータル（IDP）※ Microsoft Learnでは単に「ポータル」と表現 ※内部開発者プラットフォーム（IDP）はポータルのバックエンドに位置

Slide 22

Slide 22 text

ゴールデンパスとか認知負荷ってなんですか 22

Slide 23

Slide 23 text

ゴールデンパス（舗装された道路）とは迅速なプロジェクト開発に役立つコードと機能のテンプレートとドキュメントもしくは実際のプロダクト/サービス開発に至るまでの道、標準化され、自動化された手順 23

Slide 24

Slide 24 text

ゴールデンパスを作るとどうなるか ● ストリームアラインドチームの認知負荷が低減される ● 本来のコーディング業務に専念できる ● スキル習得に専念できる 👆これらはプラットフォームチームの役割 24 ※ストリームアラインドチーム：製品を開発して責任を持つチーム

Slide 25

Slide 25 text

ゴールデンパスを作るタイミング ● 例：インフラの複雑さに悩まされ、高い認知負荷を抱えているとき ● 例：運用チームが常にトラブルに直面しているとき ● 例：ドキュメントや個々人のやり方がバラバラで統一されていないとき 25

Slide 26

Slide 26 text

認知負荷（Cognitive load）とは認識における脳の負荷のこと 26

Slide 27

Slide 27 text

認知負荷（Cognitive load）とは認識における脳の負荷のこと 27 課題外在性負荷 👉

Slide 28

Slide 28 text

認知負荷（Cognitive load）とは認識における脳の負荷のこと 28 課題外在性負荷課題内在性負荷 👉

Slide 29

Slide 29 text

認知負荷（Cognitive load）とは認識における脳の負荷のこと 29 課題外在性負荷課題内在性負荷学習関連負荷 👉

Slide 30

Slide 30 text

認知負荷の具体例課題外・課題内在性負荷が比較的に高い状態 =新しいことを学ぶことについては苦しくない。一方で業務に取り組む際に難易度が高すぎて困難 30 課題外在性負荷課題内在性負荷学習関連負荷高高低

Slide 31

Slide 31 text

認知負荷の具体例課題外在性負荷が比較的に高い状態＝業務の難易度はさほど高くない。課題達成のための制約が多いことで課題の遂行が困難 31 課題外在性負荷課題内在性負荷学習関連負荷高低低

Slide 32

Slide 32 text

認知負荷の具体例課題内在性負荷が比較的に高い状態＝課題に取り組む人と取り組んでいる課題の難易度がマッチしていない 32 課題外在性負荷課題内在性負荷学習関連負荷低高低

Slide 33

Slide 33 text

補足：認知負荷にまつわる話 33 課題に着手するまでに20秒以上経過してしまうと人はその課題をやらなくなってしまう。 20秒以内 20秒以上ある意味で認知負荷が高い状態ある意味で認知負荷が低い状態

Slide 34

Slide 34 text

（再掲）もうちょっと踏み込んで 34 ● 内部開発者のニーズを特定したうえで最小限のセルフサービスを実装すること ○ つまり、今必要とされていることを認識してサービスを実装すること ● 内部開発者が自身の作業を自己解決できるようにすること ○ つまり、ベースとなる作業はすべて自己解決できるようにすること ● 内部開発者を主軸とした開発プロセスを定義してゴールデンパスを作ること ○ つまり、実務に携わるときに準備のプロセスを「道」として示すこと ● 内部開発者が再利用可能なことを低い認知負荷ですぐに活用できるようにすること ○ つまり、ほぼ何も考えずに本当にやりたいことに集中できること

Slide 35

Slide 35 text

プラットフォームエンジニアリングの原則 35 ここからMicrosoft Learnを参考にプラットフォームエンジニアリングの原則をみていくYo!

Slide 36

Slide 36 text

プラットフォームエンジニアリングの原則 1. 顧客に優先順位を付ける 2. 製品マインドセットを採用する 3. セルフサービスによる強化 4. 検出可能性を向上させる 36

Slide 37

Slide 37 text

顧客に優先順位を付けるプラットフォームを整備するエンジニアは内部開発者をお客さんとして見る。実装のニーズを見極め、優先順位をつけ、合意を取ったうえで小規模に始める。また、お客さんがよく使うツールに合わせてプラットフォーム（あるいはポータル）を調整する。 37 内部開発者プラットフォームエンジニア顧客中心のアプローチをとる。

Slide 38

Slide 38 text

製品マインドセットを採用する 38 実際に開発者のエクスペリエンスが向上しなければ、作る意味がない。また、プラットフォームを作っても使ってくれるとは限らない。利用しているか活用しているかどうかを計測して効果を見る。 Dev Ops プラットフォームが効果的に働くかどうかを一貫した測定方法で測定する。

Slide 39

Slide 39 text

セルフサービスによる強化 39 ゴールデンパスを作ったとしてもそれが組織のポリシーと合致しているかどうかわからない。安全のためにセキュリティの有識者と協力してセルフサービスを作り、ガードレールを設置する。ゴールデンパスだけでなく、セルフサービスを提供ゴールデンパスにガードレールを構築する！開発者ポリシーポリシー開発者

Slide 40

Slide 40 text

検出可能性を向上させる 40 組織内でチームが分裂して管理が複雑になっていくと、となりで何が起きているかがわからなくなったりする。たとえば、同じフレームワークを作っていたり、消してイイのかよくわからないインスタンスが建っていたりする。プラットフォームエンジニアはこれらを追跡する必要がある。フレームワークAを作った。フレームワークAを作った。うわ、あっちと被っとるやんテスト用に特大インスタンス建てよう（記録なし）新入社員：知らないインスタンスが建っているけどこれ大丈夫かなこのPJできるのは俺だけ！俺的神リポジトリを作ったぜウェイ！よく使うインフラテンプレートを作ったぜこれメンテされてんのか？

Slide 41

Slide 41 text

で、具体的になにしたらええの 41

Slide 42

Slide 42 text

ドキュメントを整理する一番最初にできて、最も簡単なアプローチ ● Private GitHub Pagesで社内ページを作成する ● GitHub organizationにプライベートリポジトリを作成する ● Azure DevOpsのWikiを整備する＝＞社内で使い慣れた製品を使って資料を作成するいずれにしても作ったら有識者を集めてレビューをしてもらう！ 42

Slide 43

Slide 43 text

問題領域を定義する内部開発者にとって何が課題となっているかを特定する。 Thinnest Viable Platform（最低限のプラットフォーム）を定義して Minimum Viable Product（実用最小限の製品）を開発する。例：「ドキュメントが読みにくいもしくは整理されていないことが一番の問題である場合」 👉ドキュメントを整理すれば解決する可能性があるため、ポータルは作成せず最小限でかつ実用的なアクションで済ませる。 43

Slide 44

Slide 44 text

プラットフォームチームを構築する ● Ops（運用）と製品のマインドセットを理解したメンバーで構成する ○ メンバーそれぞれの技術的バックグラウンドは重要ではないプラットフォームエンジニアリングの目的を明確にする意味でもナレッジがまとまっていない場合はチームの構築よりも先にドキュメントを作成する。 44 ※本の翻訳者による発表『チームトポロジー』と Platform Engineering https://speakerdeck.com/miholovesq/team-topologies-with-platform-engineering 引用：チームトポロジー（単行本）価値あるソフトウェアをすばやく届ける適応型組織設計 https://pub.jmam.co.jp/book/b593881. html

Slide 45

Slide 45 text

開発者テンプレートを作る一貫性のある開発環境でチーム開発の統制をとりたい 45 活用できそうなサービス ● Dev Containers ● GitHub Codespaces ● Azure Developer CLI（azd） ● Azure Deployment Environments（ADE） ● Dev Box + Visual Studio ● Terraform Cloud + GitHub ● Backstage

Slide 46

Slide 46 text

具体例1: Dev ContainersとGitHub Codespaces 引用：超高速で構築するクラウド開発環境 https://github.co.jp/features/codespaces 46 ● devcontainer.jsonとCodespacesによる環境提供でゴールデンパスとセルフサービスを提供する設定が書き込まれたjsonとGitHubアカウントがあれば、すぐに動く環境が手に入る状態

Slide 47

Slide 47 text

具体例2: azdとADE 47 ● azdとADEによる環境提供でゴールデンパスとセルフサービスを提供する ● azdで.NET Aspireを使うと、OTelのモニタリング設定までついてくるインフラの環境を保存したテンプレートを保存するADE、インフラとアプリケーションを展開するazd Azure Developer CLI support for Azure Deployment Environments https://learn.microsoft.com/ja-jp/azure/developer/azure-developer-cli/ade-integration

Slide 48

Slide 48 text

具体例3: Dev Box + Visual Studio 48 引用：Microsoft Dev Box を構成する https://learn.microsoft.com/ja-jp/azure/dev-box/quickstart-conﬁgure-dev-box-service 開発環境をOSまるごと提供する。Visual Studioで開発をコラボレーション

Slide 49

Slide 49 text

49 2022/11/22投稿 Microsoft Dev Box を使ってみよう！〜詳細編〜| Azure 入門 56 [# くらでべ ] https://youtu.be/lCPwtC5w1k8?feature=shared&t=759

Slide 50

Slide 50 text

具体例4: Terraform Cloud + GitHub 50 ● Terraform Cloud：ステート管理、プロバイダの統一、Registryの利用 ● GitHub：アプリケーションレイヤーのテストをGitHub Actions ● インフラのテスト：Terraform Cloud上で担保※ ● アプリケーションのテスト：GitHub Actions + その他で担保 ※Azureの可能性を引き出せ！Terraform活用で変わるインフラ構築術 - connpass https://youtu.be/eyAuD797AnE?feature=shared&t=1470

Slide 51

Slide 51 text

まとめ ● プラットフォームエンジニアリングは組織内で標準化されたベストプラクティスを簡単に利用できるようにしていく活動といえる（なお、定義はさまざま） ● 「DevOps、内部開発者、IDP、認知負荷、ゴールデンパス、セルフサービス、テンプレート」などがプラットフォームエンジニアリングにとりかかる上で重要になりそう ● Microsoftにはプラットフォームエンジニアリングを実現するサービスが揃っている ○ 他のクラウドと比較しても揃っている印象を受けた ● プラットフォームエンジニアリングを実現する際は使い慣れたツールを使う ○ Azureに限定する必要はない 51

Slide 52

Slide 52 text

プラットフォームエンジニアの役割（まとめ） ● 内部開発者を顧客としてみるアプローチ ● ざまざまなユースケースで負担となっている点を特定すること ● チームのプレイヤーであること ● 絶えず学び、新しい技術のエバンジェリストになること ● 問題解決志向、細部に気を配る、チーム間コミュニケーション ● 内部開発者プラットフォームを宣伝、訴求 ● DevSecOpsのプラクティスに精通していること 52

Slide 53

Slide 53 text

53 ここから先はプラットフォームエンジニアリングで参考になる資料集 Tips

Slide 54

Slide 54 text

54 Platform reference architecture on Azure https://humanitec.com/reference-architectures/azure GitHub：https://github.com/humanitec-architecture/reference-architecture-azure

Slide 55

Slide 55 text

55 Platform reference architecture on Google Cloud https://github.com/humanitec-architecture/reference-architecture-gcp

Slide 56

Slide 56 text

56 プラットフォームの組織構造 https://cloud.google.com/architecture/enterprise-application-blueprint/dev eloper-platform-controls?hl=ja

Slide 57

Slide 57 text

57 Platform reference architecture on AWS https://github.com/humanitec-architecture/reference-architecture-aws

Slide 58

Slide 58 text

58 Platform tooling landscape https://platformengineering.org/platform-tooling

Slide 59

Slide 59 text

59 Internal Developer Platform https://internaldeveloperplatform.org/

Slide 60

Slide 60 text

60 What Is an Internal Developer Platform https://humanitec.com/blog/what-is-an-internal-developer-platform