Slide 1

Slide 1 text

@AoToLog_ �� 開発者を支える Internal Developer Portal のイマとコレカラ 8th Sep, Platform Engineering Meetup #14 Speaker: Kento Kimura

Slide 2

Slide 2 text

@AoToLog_ �� 話すこと 01 さあ、アプリを開発しよう! 04 コレカラ:IDP はどこへ? 03 イマ:みんなの IDP 02 IDP ってなんだっけ? 05 まとめと紹介

Slide 3

Slide 3 text

@AoToLog_ �� 話すこと 01 さあ、アプリを開発しよう! 04 コレカラ:IDP はどこへ? 03 イマ:みんなの IDP 02 IDP ってなんだっけ? 話さないこと 05 まとめと紹介 XX Datadog の具体的な機能解説 XX IDP の歴史 XX Golden Path の話

Slide 4

Slide 4 text

@AoToLog_ �� 話すひと ● 所属: Technical Solutions / Sales Engineering ● 担当: パブリッククラウドのアーキテクト知識を活かした   Datadog のプリセールス技術支援 ● コミュニティ: Google Cloud のユーザーコミュニティ「Jagu'e'r」 Datadog のユーザーコミュニティ「JDDUG」 AWS のユーザーコミュニティ「JAWS」 ● カンファレンス: 初開催!Observability Conference Tokyo 2025 木村 健人 (Kento Kimura) Datadog Japan GK

Slide 5

Slide 5 text

@AoToLog_ �� さあ、アプリを開発しよう!

Slide 6

Slide 6 text

@AoToLog_ �� さあ、アプリを開発しよう! エディタを用意して、コードを書き初めて… コンテナイメージを作って、レジストリを準備して… テスト実行環境を用意して、CI/CD と繋げて… インフラを準備して、IaC 化して…

Slide 7

Slide 7 text

@AoToLog_ �� さあ、アプリを開発しよう! エディタを用意して、コードを書き初めて… コンテナイメージを作って、レジストリを準備して… テスト実行環境を用意して、CI/CD と繋げて… インフラを準備して、IaC 化して… いつデプロイできるの?

Slide 8

Slide 8 text

@AoToLog_ �� 開発者が最初に準備すること… やることと求められる知識 やること ● 開発環境構築 ● (アプリケーション)開発 ● (アプリケーション)ビルド ● (アプリケーション)デプロイ ● DevSecOps ● IaC ● AI コーディング 求められる知識 ● エディタ・IDE(統合開発環境) ● コーディング ● アプリケーション言語 ● ランタイム・コンテナ・OS ● CI/CD ● GitOps ● オブザーバビリティ ● Terraform, CloudFormation, CDK, ARM+Bicep ● AI コーディングエージェント … … … 開発者が注力したいもの

Slide 9

Slide 9 text

@AoToLog_ �� どのタイミングで必要なの? 1. 開発チームのオンボーディング ● 新入社員 ● チームへの合流 ● 新規開発 2. 組織内標準のアプローチ ● VM の払い出し ● チーム間のコミュニケーション手法 ● ベストプラクティスの共有 3. セキュリティ ● SBOM・署名の提供 ● オブザーバビリティの整備 プラットフォームが提供するもの: 開発上の本質ではない、組織上の制限や 特定の推奨事項の提供・プロダクトの統合 開発者が注力したいもの: 開発で重要視される、プロダクトの設計や 効率的なフレームワーク・ライブラリの選定、 パフォーマンス向上の工夫、外部 API の設計 組織共通のプラットフォームを通して、開発プロセスの効率化=ソフトウェアの整備 を行うことで、開発者の生産性が向上できそうなタイミング!

Slide 10

Slide 10 text

@AoToLog_ �� Platform Engineering とは 組織において有用な抽象化を行い、 セルフサービス インフラストラクチャを構築するアプローチ 有用な抽象化とは “ “ 迅速なプロジェクト開発に役立つ 巧みに統合されたコードと機能のテンプレート構成 “ “ 引用:『道を照らす: プラットフォーム エンジニアリング、ゴールデンパス、セルフサービスのパワー』 散乱したツールをまとめ、開発者の生産性を高める ● テンプレートの提供:スケルトンソースコード・IaC ファイル・Kubernetes yaml ファイル ● ドキュメントの整備:スタートアップガイド・リファレンス ● モニタリング標準化:依存関係の管理・オブザーバビリティの整備

Slide 11

Slide 11 text

@AoToLog_ �� IDP ってなんだっけ?

Slide 12

Slide 12 text

@AoToLog_ �� Platform Infrastructure 頻繁に語られる2つの IDP 開発・製品チームが迅速にソフトウェアを デプロイしサービスを提供するための… …単一のインターフェース →Internal Developer Portal  (社内開発者ポータル) …複雑性を排除した中心的な基盤 →Internal Developer Platform  (社内開発者プラットフォーム) Platform Engineering: プラットフォームと開発・製品チームを繋ぐ ID Portal を ID Platform を通して提供する Platform Tools Developer and Product Teams Internal Developer Platform (社内開発者プラットフォーム) Reusable Component Tools Platform Service Knowledge Internal Developer Portal (社内開発者ポータル) 推奨パス 例外パス

Slide 13

Slide 13 text

@AoToLog_ �� Platform Infrastructure IDP に求められるもの 開発・製品チームが共通して利用する ツールやサービスを見つけられる、 単一のインターフェース・UI Platform Tools Developer and Product Teams Internal Developer Platform (社内開発者プラットフォーム) Reusable Component Tools Platform Service Knowledge Internal Developer Portal (社内開発者ポータル) 推奨パス 例外パス プラットフォームチームが統制し、 ポータルに機能を提供する API を持つ 保守性・拡張性の高いサービス 意思決定を迅速にするガードレールと 例外を許容するブレークグラスを持つ 柔軟なツールとしてのエコシステム

Slide 14

Slide 14 text

@AoToLog_ �� Backstage: 最も有名な CNCF の IDP プロジェクト ● CNCF の incubating プロジェクト ● Spotify により2020年に寄贈 ● Internal Developer Portal を 構築するオープンフレームワーク ● コア・アプリ・プラグインの3つの コンポーネントで構成される ● インテグレーションとプラグインで のカスタマイズが可能 引用:Backstage『Software Catalog / Overview』『Software Template / Overview』『TechDocs / TechDocs Addons』

Slide 15

Slide 15 text

@AoToLog_ �� Backstage: 2つの IDP Platform Infrastructure Platform Tools Developer and Product Teams Internal Developer Platform (社内開発者プラットフォーム) Reusable Component Tools Platform Service Knowledge Internal Developer Portal (社内開発者ポータル) 推奨パス 例外パス Integrations Infrastructure Services Plugins Other Tools Backstage App Backstage Plugin Software Templates Software Catalog TechDocs 推奨パス 例外パス Backstage Core UI Backstage Plugin UI + Database

Slide 16

Slide 16 text

@AoToLog_ �� Backstage: IDP に求められるもの 開発・製品チームが共通して利用する ツールやサービスを見つけられる、 Backstage(+ Plugin) UI プラットフォームチームが統制し、 ポータルに機能を提供する App を持つ 保守性・拡張性の高い Core/App 意思決定を迅速にするガードレールと 例外を許容するブレークグラスを持つ 柔軟な Core/Integration/Plugin 引用:Backstage『Software Catalog / Overview』『Software Template / Overview』『TechDocs / TechDocs Addons』

Slide 17

Slide 17 text

@AoToLog_ �� 開発者を支える Internal Developer Portal のイマとコレカラ 8th Sep, Platform Engineering Meetup #14 Speaker: Kento Kimura

Slide 18

Slide 18 text

@AoToLog_ �� 開発者を支える Internal Developer Portal のイマとコレカラ 8th Sep, Platform Engineering Meetup #14 Speaker: Kento Kimura 開発者を支える Internal Developer Portal のイマとコレカラ 答えがある話ではないため、 カタカナで誤魔化しています…

Slide 19

Slide 19 text

@AoToLog_ �� イマ:みんなの IDP

Slide 20

Slide 20 text

@AoToLog_ �� IDP を導入・利用している方!!

Slide 21

Slide 21 text

@AoToLog_ �� IDP って本当に使われているの? IDP サービスを提供する Port 社が2024年に 欧米の企業を中心に行った調査レポートでは、 50%の企業が Internal Developer Portal を採用 ※150名以上の開発者を抱える企業の従業員100名 つまり… 日本の少数精鋭な中小企業ではもっと少なそう… 引用:Port.io『2024 State of internal developer portals』 考えられる理由として… ● Platform Engineering の取り組みはあるが、 専任のチームは存在しない ● ある程度の標準化や共通化が行われているが、 IDP と呼べるレベルものではない ● ある程度のドキュメント整備は行っているが、 稼働しているサービスの実態と乖離している

Slide 22

Slide 22 text

@AoToLog_ �� みんなのプラットフォームエンジニアリング 専任の Platform Engineer がいなくともできる取り組みから始める =プラットフォームより開発者体験を向上する取り組みを始める IDP がないと思っていても、プラットフォームは出来上がっているかも🤔 1. コードを本番環境に適用するまでの手法 2. インフラストラクチャをプロビジョニングする手順 3. 開発やプロダクトの関連する体系的な知見 4. 複数チームにまたがる承認フロー 既に出来上がったプロセス=「プラットフォーム」をモデル化・効率化する ソフトウェアを構築することが Platform Engineering となる!

Slide 23

Slide 23 text

@AoToLog_ �� CNCF:IDP の将来についての会話 2024年9月30日、CNCF ブログで貴重な Internal Developer Portal のトピック 【抄訳】 プラットフォームエンジニアリングで成功する鍵 ● 同じソフトウェア手法を各開発チームにも適用すること ● プラットフォームを製品として扱うこと ● 製品が達成しようとしていることを定義し、常に改善方法を模索すること ポータルの使いやすさと視覚的な性質が開発者の価値基準 ● フロントエンドからロジックを分離すること ● Infrastructure as Codeと宣言型の手法を用いてポータルを構築すること ● オープンソースプラグインの共有を通じてコミュニティと負荷を分担すること 参考:CNCF ブログ/コミュニティ投稿『社内開発者ポータル(IDP)の将来についての会話』 “ “ “ “

Slide 24

Slide 24 text

@AoToLog_ �� CNCF:IDP の将来についての会話 2024年9月30日、CNCF ブログで貴重な Internal Developer Portal のトピック 【抄訳】 プラットフォームエンジニアリングで成功する鍵 ● 同じソフトウェア手法を各開発チームにも適用すること ● プラットフォームを製品として扱うこと ● 製品が達成しようとしていることを定義し、常に改善方法を模索すること ポータルの使いやすさと視覚的な性質が開発者の価値基準 ● フロントエンドからロジックを分離すること ● Infrastructure as Codeと宣言型の手法を用いてポータルを構築すること ● オープンソースプラグインの共有を通じてコミュニティと負荷を分担すること 参考:CNCF ブログ/コミュニティ投稿『社内開発者ポータル(IDP)の将来についての会話』 “ “ “ “ プラットフォーム側も 楽しようね😇😇😇😇

Slide 25

Slide 25 text

@AoToLog_ �� コレカラ:IDP はどこへ?

Slide 26

Slide 26 text

@AoToLog_ �� IDP はどこへ? 開発・製品チームが利用したいのは Internal Developer Portal Internal Developer Platform の管理は IDP を導入する障壁 1. SaaS IDP IDP サービスを SaaS として 提供し、利用者が管理する 要素を極力削減する ex) Spotify for Backstage, Port.io 2. IDP in Cloud プラットフォームの基盤を 提供するクラウドサービス 自身が IDP 機能を提供する ex) Google Cloud App Hub, Cloud Hub 3. IDP in O11y ソフトウェアの実働状態を 把握できる O11y を通して IDP がサービス管理する ex) Datadog Internal Developer Portal プラットフォーム側も 楽しようね😇😇😇😇

Slide 27

Slide 27 text

@AoToLog_ �� Example: Spotify for Backstage IDP のオープンフレームワークである Backstage をその生みの親である Spotify が SaaS として標準機能を提供し、Platform の管理を不要にする IDP の導入の障壁であった Platform 側を意識することなく、必要な Portal のサービスが利用できる 引用:Spotify for Backstage『Putting Backstage into action』

Slide 28

Slide 28 text

@AoToLog_ �� Example: Google Cloud App Hub サービスとワークロードの標準化された論理構造である「アプリケーション」に定義し、 開発・製品・プラットフォームチームの管理範囲を明確にする デプロイされたサービスは自動検出され、アプリケーションからテンプレートをデプロイできる 引用:Google Cloud Blog『App Hub - トイルを排除したアプリケーション管理を実現』

Slide 29

Slide 29 text

@AoToLog_ �� Example: Datadog Internal Developer Portal 検出されたテレメトリーデータから標準化された「システム」と「サービス」を定義し、 開発・製品・プラットフォームチームに必要なセルフサービスアクションを提供する オブザーバビリティの力でサービスの実態を把握し、同一のプラットフォームで実際のアクションに繋げる 引用:Datadog Documentation『Internal Developer Portal』

Slide 30

Slide 30 text

@AoToLog_ �� Internal Developer Portal のその先 Platform Engineering は開発者体験の 向上が目的だが、IDP の構築が目的に なると本末転倒… PFE 側も楽をして、SaaS や他プラット フォーム上の ID Platform の活用で、 最小限の管理リソースで開発者ための インターフェースである ID Portal を 提供できる!! 結論:みんな幸せ Developer and Product Teams Internal Developer Platform (社内開発者プラットフォーム) 管理不要 Internal Developer Portal (社内開発者ポータル) 推奨パス 例外パス

Slide 31

Slide 31 text

@AoToLog_ �� まとめ

Slide 32

Slide 32 text

@AoToLog_ �� まとめ ● Internal Developer Portal はさまざまなツールやサービスを 開発・製品チームが利用できるようにするインターフェース ● Internal Developer Portal を導入することを目的にすると、 Platform Engineering の目的(開発者生産性の向上)からは離れてしまう ● IDP はさまざまな方法で Platform の管理が不要になるよう進化し、 専任 Platform Engineer 不要で開発者が有用な抽象化ができる

Slide 33

Slide 33 text

@AoToLog_ �� 宣伝

Slide 34

Slide 34 text

@AoToLog_ ��

Slide 35

Slide 35 text

@AoToLog_ �� OCT 16, 2025

Slide 36

Slide 36 text

@AoToLog_ �� OCT 16, 2025

Slide 37

Slide 37 text

@AoToLog_ �� Thank you!