$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「共通基盤」を超えよ! 今、Platform Engineeringに取り組むべき理由
Search
Kazuto Kusama
April 11, 2024
Technology
27
11k
「共通基盤」を超えよ! 今、Platform Engineeringに取り組むべき理由
OpenShift.Runで登壇した資料です。
Kazuto Kusama
April 11, 2024
Tweet
Share
More Decks by Kazuto Kusama
See All by Kazuto Kusama
間違いだらけのポストモーテム - ホントに役立つレビューはこうだ!
jacopen
0
5
2024/10 PagerDuty機能アップデート
jacopen
1
37
ゲームから学ぶ、いちばん速いインシデント対応
jacopen
1
67
PEK2024 Recap
jacopen
2
140
クラウドネイティブの本質から考える、生産性と信頼性の両立
jacopen
3
850
「責任ある開発」を!フルサービスオーナーシップが変えるエンジニアリング文化
jacopen
11
2k
手を動かさないインシデント対応〜自動化で迅速・正確な運用を目指す〜
jacopen
3
430
エンジニアとしてのキャリアを支える自宅サーバー
jacopen
12
7.4k
Grafana x PagerDuty Better Together
jacopen
1
720
Other Decks in Technology
See All in Technology
PFN Company Deck
pfn
PRO
1
110
クラウドインフラ構築における.NETとその他IaCの比較
ymd65536
1
160
【CNDW2024】SIerで200人クラウドネイティブのファンを増やした話
yuta1979
0
160
セキュリティベンダー/ユーザー双方の視点で語る、 Attack Surface Managementの実践 - Finatextパート / cloudnative-architecture-of-asm
stajima
0
2.1k
SDNという名のデータプレーンプログラミングの歴史
ebiken
PRO
2
280
Bytebaseで実現する データベース管理の効率化
shogo452
1
100
241130紅白ぺぱ合戦LT「編集の技術」
toya524287
2
260
LLMを「速く」「安く」 動かすには / CloudNative Days Winter 2024
pfn
PRO
4
1k
A Tour of Anti-patterns for Functional Programming
guvalif
0
2.3k
そろそろOn-Callの通知音について考えてみよう (PagerDuty編)
tk3fftk
1
140
SDN の Hype Cycle を一通り経験してみて思うこと / Going through the Hype Cycle of SDN
mshindo
3
340
プルリクが全てじゃない!実は喜ばれるOSS貢献の方法8選
tkikuc
12
1.4k
Featured
See All Featured
How GitHub (no longer) Works
holman
310
140k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Visualization
eitanlees
145
15k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
BBQ
matthewcrist
85
9.3k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
24k
Transcript
「共通基盤」を超えよ! 今、Platform Engineeringに 取り組むべき理由
Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering
Meetup Founder @Cloud Native Innovators Association この四角枠は資料公開にあたって、登壇 中に喋った内容に近くするために補足で 追加したモノです
Platform Engineering推進の団体をやっています 一般社団法人 クラウドネイティブイノベーターズ協会 Platform Engineering Kaigi 2024 7/9開催!
Platform Engineeringとは 開発者体験と生産性を向上させるために セルフサービスで利用できるツールチェーンとワークフローを 設計・構築する分野 まずはおさらいから。 Gartnerをはじめ、いくつかの団体では このような定義がなされています
クラウドの登場とDevOps Dev Ops Configure Verify Package Plan Monitor Release Create
Plan DevとOpsの垣根をなくし、ソフトウェアの開発とデリバリーを継続して行えるよ うにするアプローチ。 このプロセスの中にセキュリティ対策を組み込むDevSecOpsというパターンも登 場した
真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub
Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が 高すぎる これをやり切れ る人材は少ない
認知負荷の増大 https://www.infoq.com/articles/platform-engineering-primer/ より引用 認知負荷が爆上がりな昨今。マイクロ サービスやクラウドネイティブ技術の発 展に伴って、開発者がやらないといけな いことがものすごく増えた
Internal Developer Platform プラットフォームチームによって構築される、開発者のセルフサービスによる利 用を可能にする基盤。 さまざまな技術やツールによって構成され、コンテキストや基礎となる技術を抽 象化することなく、開発者の認知負荷を軽減していく Kubernetes Buildkit Helm
Dockerfile Grafana Prometheus GitHub Actions Security Terraform ArgoCD APM Compliance IDP Developer Platform Team self service そこで提唱されている解決方法が、内 部開発者プラットフォーム。
ここまではいいんだけど
ブコメ 以前別の資料を公開したときについたブ コメ。実は重要なポイントを突いている
従来のプラットフォームは 夢を見て死んでいくものだった
共通プラットフォームは特に新しい話では無い 業種業態問わず、ある一定の規模以上の会社であれば、 共通のプラットフォームを作ろうという話が一度は出ているはず。 (次世代|新)(共通|汎用|統合)(基盤|プラットフォーム) みたいな名称のプロジェクト、関与したことある人も多いのでは
たとえば検索してみると GoogleでPlatform Engineering登場 以前の日付を指定して「共通基盤」 について検索すると、すごーくたく さん出てくる。でも、このうち生き 残っているのはどれだけあるのだろ う?
上手くいくプラットフォーム作りは、本当に難しい • 4割の共通プラットフォームは、生まれながらに死んでいる • 4割の共通プラットフォームは、上手く運用出来ずに死んでいく • 成功するのは2割か、それ以下 (注: jacopenの感覚値なので数字に根拠はありません!)
従来の『共通基盤』の視点 コスト削減 システム統合 OSS プロセス改善 運用一元化 ガバナンス 強化 中央管理 プロセス整備
標準化 一見合理的に見えるが・・・ 昔の共通基盤の取り組みについて事例を 見てみると、そのモチベーションはこの 2つに集約されていることが多いと気づ きました。
もしあなたが開発者だったとして・・・ コスト削減のために 共通基盤を使え ガバナンスのために 共通基盤を使え 突然こんなこと言われたら どう思いますか?
もしあなたが開発者だったとして・・・ コスト削減のために 共通基盤を使え ガバナンスのために 共通基盤を使え うるーせ馬鹿
もしあなたが開発者だったとして・・・ コスト削減のために 共通基盤を使え ガバナンスのために 共通基盤を使え うるーせ馬鹿 (渋い顔をしながら) はい、わかりました すごくいい取り組み だと思います!
ですが今回の案件は XXXがXXXでXXXX なので独自の環境で (以下長文) ぼくたちは大人なのでホンネは胸に押し 込みつつ、仕方なく受け入れるか、ある いは理由を立てて断るかのどっちかにな ります。これじゃぁ使われないのも当然
第一目的がコスト削減やガバナンス強化 な共通基盤を使いたがる人はいない
共通基盤でコストが下がるは幻想 システムA システムB システムC システムD 共通基盤 A B C 共通基盤に載ってこ
ないシステムもある この瞬間、一時的に コストが下がること はある
共通基盤でコストが下がるは幻想 システムA システムB システムC システムD 共通基盤 A B C 数
年 後 かつて共通基盤 だったもの A B C E F D G 新共通基盤 もはや 独自基盤 古い基盤に しびれを切 らして乗り 換え 新しい技術 が使いたい 新規事業 我が道を行く 中長期で見てコストは下がったのか?
共通基盤だから、投資をしつづけるべき 共通基盤 A B C D 最初は載らない ものもある 共通基盤 A
B 共通基盤 C D 半 年 後 投資 & 進化 X 年 後 投資 & 進化 進化により 載るように A C D E F B Good bye ノウハウ蓄積が あるので新規事 業も載りやすい 事業環境の変化 にも柔軟に対応 コスト削減を大義名分にする と、投資ができなくなる。 そして進化できずに死ぬ
とはいえ • 闇雲に投資すればいいわけではない • 闇雲に人を突っ込めばいいわけではない • とにかく機能を詰め込めばいいわけではない 従来の共通基盤の考え方と、Platform Engineeringの違い は、これを解決するアプローチに重点が置かれている点
Platform Engineeringとは 開発者の認知負荷を軽減し生産性を向上させる共通基盤を 『正しく』作り続けるための方法論
Platform Engineeringとは 開発者の認知負荷を軽減し生産性を向上させる共通基盤を 『正しく』作り続けるための方法論
開発者の認知負荷を軽減し生産性を向上させる共通基盤 Golden Path Internal Developer Portal Internal Developer Platform
Platform Engineeringとは 開発者の認知負荷を軽減し生産性を向上させる共通基盤を 『正しく』作り続けるための方法論
『正しい』とは何か • 絶対的な正解はない。 • 開発者の認知負荷を軽減し生産性を向上させる共通基盤 ◦ これを実現するための技術、規模、チームは 会社によって全く異なる ◦ 同じ組織であっても、状況の変化や時間経過で
正解は変わりうる • 正解が変わり続けることを前提に考えることが重要
こういうのは『正しい』? • 開発者の認知負荷増大が課題となっている • 開発者は運用側との調整に時間が取られ、本来の業務に 注力できていない • そこで、セルフサービスでワークロードをデプロイできる Kubernetes環境を提供する •
また、CI/CD環境を提供し、各オペレーションの 自動化を実現する • これをプラットフォームとして提供し、 ビジネスのアジリティ向上に貢献する
『正しい』とは何か 認知負荷を下げよう! アジリティを高めよう! Kubernetesでプラットフォーム組んで 実現! Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ オンプレはvSphereで、
クラウドはServerlessで、 特に課題感は無いんだけど?
『正しい』とは何か 認知負荷を下げよう! アジリティを高めよう! Kubernetesでプラットフォーム組んで 実現! Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ オンプレはvSphereで、
クラウドはServerlessで、 特に課題感は無いんだけど? いやこれがこれからの デファクトスタンダードなんだよ つかえよ
『正しい』とは何か 認知負荷を下げよう! アジリティを高めよう! Kubernetesでプラットフォーム組んで 実現! Platform Team 言っていることは分かるけど そもそも取り組む余裕がないよ オンプレはvSphereで、
クラウドはServerlessで、 特に課題感は無いんだけど? いやこれがこれからの デファクトスタンダードなんだよ つかえよ 使われるわけがない
誰に 何を どうやって 失敗するプラットフォームは ここばかり気にする
誰に 何を どうやって プラットフォーム の利用者 ◦◦という価値を 技術 ツールチェーン ワークフロー ここにちゃんとフォーカスすること
これを継続的に回せること
Platform as a Product • 開発者を『顧客』として考え、顧客にプラット フォームという『プロダクト』を提供していく というアプローチ • 世の中に提供されているさまざまなプロダクト
と同じ管理手法を、プラットフォームにも取り 込んでいく 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム
Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プラットフォームチーム
どういう価値を提供できれば 使って貰えるか 顧客が何に困っているか どうやってサポートしていく か どうやって教育していくか どうやって安定したチームを 作るか プラットフォームによる効果 がどのくらい出ているか 何をいつまでに提供するか 世の中のトレンドはどうなっ ているか
Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プロダクト
マネージャー プロダクトマネジメントの 手法がそのまま使える。 チームに専任のプロダクトマ ネージャーを置き、プロダク トとしてのプラットフォーム の方向性を決めていく
Platform as a Product 顧客 Platform Product プロダクトを提供 プロダクトを提供 プロダクト
マネージャー • プラットフォームが最も達成したい指標は何か ◦ North Star Metricsの策定 • 顧客は何にペインを感じているのか ◦ ユーザーヒアリング • 最も重要なものから実現し、TVP(Thinnest Viable Platform)を作る ◦ 実装する機能の優先順位付け • 社内にその存在を知ってもらう ◦ ブランディング、社内マーケティング
従来の『共通基盤』の視点 コスト削減 システム統合 OSS プロセス改善 運用一元化 ガバナンス 強化 中央管理 プロセス整備
標準化
共通基盤だから、投資をしつづけるべき 共通基盤 A B C D 最初は載らない ものもある 共通基盤 A
B 共通基盤 C D 半 年 後 投資 & 進化 X 年 後 投資 & 進化 進化により 載るように A C D E F B Good bye ノウハウ蓄積が あるので新規事 業も載りやすい 事業環境の変化 にも柔軟に対応 コスト削減を大義名分にする と、投資ができなくなる。 そして進化できずに死ぬ
コスト削減効果でROIを測らない コスト削減を第一の目標として共通基盤を作るのはNG いちどコスト削減したら、そのあとは「何もしない」ことが最適解となってしまい、継続的 な投資を受けられなくなってしまう可能性が高い 新しいものを導入する時に、ついついコスト削減効果でROIを算出しがちだが、安易な方向 に流れないように注意 • 導入する側: 内部の説得のためにコスト削減ROIを求めがち。でも、数年で使われなく なってしまい実績に繋がらない
• 提案する側: 短期間でChurnしてしまい残念な結果に
でも、ROIを考えるのは大事 • ROIを測って経営層の理解を得ることはとても大事。お金はユビキタス言語 • コスト削減では無く、どれだけ価値を生み出せたかでROIを測ろう ◦ ユーザー満足度と生産性 ▪ プラットフォームの利用者数(増加/減少) ▪
プラットフォーム利用者のNPS(Net Promoter Score) ▪ SPACEフレームワーク ◦ 組織としての効率 ▪ サービスのリクエストから提供までの待ち時間 ▪ 新しいサービスを本番環境にデプロイするまでの時間 ▪ 新規開発者が最初のコードをコミットするまでの時間 ◦ DevOpsチームのパフォーマンス ▪ Four Keys
これらの数値を金額換算 参考例: Productivity [Productivity Impact] = [Engineering hour saved] *
[Impact per engineering hour] Stability [Stability Impact] = [Impact per minute] * [Time to restore] Efficiency [Efficiency Impact] = [Cost saving] - [Negative Impact] Risk [Risk Impact] = [RIsk in money before] - [Risk in money after]
従来の『共通基盤』の視点 コスト削減 システム統合 OSS プロセス改善 運用一元化 ガバナンス 強化 中央管理 プロセス整備
標準化
ガバナンスも大事 • 統制が取れていて、セキュアな環境を提供するという考え方自体は正しい • ただ、「統制のためにここを使いなさい」という押しつけをしても、使われない ガバナンスのために 共通基盤を使え やだ 共通基盤 •
制限が強くやりたいことがやれない • 利用するのにいちいち申請しないといけない • 使ったところでセキュリティチェックシートは 出さないといけない
ガバナンスも大事 • セキュアバイデフォルト • あるべきガードレールをプラットフォーム側で実現することによって、 開発者側はパフォーマンスを発揮できる じゃあ使 おう あるべき共通基盤 •
開発者の業務を阻害しない形で、 きちんとセキュアに保たれている • プラットフォームチームのガードレールのも と、セルフサービスで必要な変更を行える • ここを使うことで、面倒なチェックシートは 不要になる ここを使えば、 簡単かつセキュア
今までとこれから 開発者 プラットフォームチーム Platform 押しつけ 開発者 技術の洪水 Platform Portal Tools
X-as-a-Service Collaboration Facilitation 立ち向かう 生産性を高める⤴
よろしくお願いします! Platform Engineering Kaigi 2024 7/9開催! 現在Proposal受付中!