Slide 1

Slide 1 text

プラットフォームエンジニアリングとは何であり、なぜプ ラットフォームエンジニアリングなのか Platform Engineering Meetup #15

Slide 2

Slide 2 text

自己紹介 松浦隼人 ● X : dblmkt ● 本業 : オーティファイ株式会社 ● 趣味(副業) : 翻訳

Slide 3

Slide 3 text

著者 : Camille Fournier    Ian Nowland 出版 : オライリー・ジャパン 発売日 : 2025/11/29 ページ : 346 価格 : 4,400円 原著 : Platform Engineering O’Reilly / 2024年10月

Slide 4

Slide 4 text

第I部 プラットフォームエンジニアリングとは何であり、 なぜプラットフォームエンジニアリングなのか 1章 プラットフォームエンジニアリングが    重要になりつつある理由 2章 プラットフォームエンジニアリングの柱 第II部 プラットフォームエンジニアリングの実践 3章 どのように、そしていつ始めるか 4章 素晴らしいプラットフォームチームを作る 5章 プロダクトとしてのプラットフォーム 6章 プラットフォームの運用 7章 計画とデリバリ 8章 プラットフォームのリアーキテクチャ 9章 プラットフォームのマイグレーションと    廃止 10章 ステークホルダとの関係管理 第III部 プラットフォームエンジニアリングの成功指標 11章 プラットフォームに整合性がある 12章 プラットフォームが信頼されている 13章 プラットフォームが複雑性を管理している 14章 プラットフォームが愛されている

Slide 5

Slide 5 text

✖ Kubernetesその他ツールの使い方 ✖ コード ✖ 設定例 ✖ 使えるアーキテクチャ例 ⭕ いつどのように始めるか ⭕ 理想的なプラットフォームチームの   構成・失敗例 ⭕ プロダクトとしてプラットフォームを   作る考え方 ⭕ プラットフォームの計画・デリバリ・   運用・マイグレーション・廃止 ⭕ ステークホルダーとの   コミュニケーション ⭕ 成功指標

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

プラットフォームエンジニアリングとは ● プラットフォーム を開発・運用する技術分野 ○ プラットフォームとは ■ 自己完結型のAPI、ツール、サービス、知識、サポートを社内プロダクトとして 構成した基盤 ○ アプリケーションチームが手間をかけずに早いペースで製品を作れるようにする仕組み ● ビジネスにおけるレバレッジ を実現する ● システム全体の複雑さを管理 する ● プラットフォームをプロダクト として扱う

Slide 8

Slide 8 text

プラットフォームエンジニアリングとは ● ビジネスにおけるレバレッジを実現する ○ 少数のプラットフォームエンジニアの仕事によって、組織全体の業務を削減できる ■ 生産性の向上と、重複作業を減らす ● システム全体の複雑さを管理する ○ プラットフォーム内に複雑さを閉じ込める = 複雑さを管理する ● プラットフォームをプロダクトとして扱う ○ ツールを提供するだけでなく、ユーザを中心に考える ○ その上で、必要な機能・あえて作らない機能を選別して、洗練されたものを作る

Slide 9

Slide 9 text

なぜプラットフォームエンジニアリングが必要 なのか

Slide 10

Slide 10 text

プラットフォームがないと起こる問題 ● 選択肢の爆発的増加 ● グルーの蔓延 ● 保守コストの増大 ● 運用負荷の増加

Slide 11

Slide 11 text

選択肢の爆発的増加

Slide 12

Slide 12 text

グルーの蔓延→保守コスト増大・運用負荷増加

Slide 13

Slide 13 text

プラットフォームによる解決 ● 基本的機能の選択肢を制限 ● グルーの量を制限 ● マイグレーションコストの集約 ● 運用の簡素化

Slide 14

Slide 14 text

プラットフォームによる解決 アプリチームのタ スクの移譲・集約

Slide 15

Slide 15 text

プラットフォームをプラットフォーム たらしめる4つの柱

Slide 16

Slide 16 text

プロダクトとして扱う ● 厳選されたプロダクトアプローチ ○ プロダクト アプローチ=ユーザを中心に、必要な機能・体験を提供する ○ 厳選された アプローチ=プラットフォームの対象を明確にして、提供内容を厳選する ● 舗装道路型 ○ 既存システムとのギャップを埋めて多くのユーザをカバーできるようにする ○ どちらかというとユーザの自由度に重き ● 線路型 ○ 既存システムにはカバーされていない部分を埋める ○ どちらかというと型にはめる

Slide 17

Slide 17 text

ソフトウェアベースの抽象化 ● (OSSなど裏で動く仕組みの )複雑さを管理するには、ソフトウェアが必要 ○ 開発者が必要になる ● 注意点 ○ カプセル化と APIの提供 ○ シッククライアント ←→シンクライアント ○ OSSのカスタマイズ ○ メタデータの扱い

Slide 18

Slide 18 text

幅広いアプリケーション開発者向けの基盤 ● 個別最適ではなく、様々な開発者・チームをカバーできる必要 ○ セルフサービスな仕組み ○ ユーザから見たオブザーバビリティ ○ ガードレール ○ マルチテナンシー

Slide 19

Slide 19 text

運用の規律を持つ ● プラットフォームチームがプラットフォーム全体の責任を持つ ○ OSSなど自分が制御できない仕組みに依存しすぎると、責任を取れない

Slide 20

Slide 20 text

Kubernetes入れたら プラットフォームエンジニアリング ではない

Slide 21

Slide 21 text

開発者ポータル(IDP)作ったら プラットフォームエンジニアリング ではない

Slide 22

Slide 22 text

ツールやプロセスを導入することを プラットフォームエンジニアリングと いうなかれ

Slide 23

Slide 23 text

プラットフォームエンジニアリングとは、 Site Reliability EngineeringやDevOpsのように、 マインドセットあるいはパラダイム

Slide 24

Slide 24 text

No content