Platform Engineering on Serverless

Slide 1

Slide 1 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kensuke Shimokawa Amazon Web Services Serverless Specialist Platform Engineering on Serverless P L AT F O R M E N G I N E E R I N G K A IG I 2 0 2 4 AWS における Platform Engineering の推進

Slide 2

Slide 2 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Myself.. 2 Kensuke Shimokawa Amazon Web Services Japan Serverless Specialist X: _kensh Slides https://speakerdeck.com/_kensh Qiita https://qiita.com/_kensh

Slide 3

Slide 3 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Platform Engineering とは 01 Platform Engineering の適用例 04 Agenda プラットフォームの設計フロー 03 Platform の考え方と課題の整理 02 Platform Engineering の実践 05 まとめ 06 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「引き継ぎ」の発⽣するコラボレーションモデル 6 開発チームアプリケーション開発運用チーム成果物の投げわたしアプリケーション開発アプリケーション開発手順書に沿った開発、運用環境の構築アプリケーションの設定、デプロイモニタリング環境の構築アプリケーション、インフラのオンコール保守開発開発 → 運用

Slide 7

Slide 7 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 「引き継ぎ」コラボレーションモデルの課題 7 • 運⽤チームの負荷がスケールしない § 開発チームのリクエスト数 (アプリ更新など) 増加 § 開発チームの増加 • 運⽤と開発が利益相反しやすい § 開発は早く要件を実装してどんどんデプロイしたい § 運⽤はなるべく環境を変更したくない運用チーム開発チーム開発チーム

Slide 8

Slide 8 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 共通基盤 - サイロ化したチームモデルの負荷分散 8 開発チームアプリケーション開発 IT 運用チーム共通基盤で負荷分散開発標準、言語フレームワーク開発ツール、IDE、IDE プラグインデプロイパイプライン共通のインフラと運用保守開発環境作成、DB スキーマ変更などの申請チケットフォーム

Slide 9

Slide 9 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 共通基盤だけではコラボレーションが改善しない 9 • 要件の反映 • ( 開発チーム) 新しい技術を使いたい • 新しい⾔語バージョン • クラウドサービスでサポートされた新機能 • (運⽤チーム) 全ての開発チームに影響する変更を追加したい • ⾔語バージョンやフレームワークの変更 • Kubernetes のバージョン更新 • クラウドネイティブ開発の対応 • インフラを⽤意してアプリを載せる、というスタイルとは限らない • AWS Lambda、Amazon SQS、AWS Step Functions, AWS IAM, etc. • インフラとアプリの垣根があいまいに開発チームアプリケーション開発運用チーム共通のインフラと運用保守開発

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. DevOps とクラウドネイティブな開発 11 • アプリケーションとインフラストラクチャーの垣根があいまいに § 開発チームと運⽤チームがよりよくコラボレーションする⽂化の重要性 • チームの役割⾃体も変わる必要がある開発チーム運用チームインフラストラクチャーアプリケーション

Slide 12

Slide 12 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 逆コンウェイの法則とチームの役割 12 • コンウェイの法則 § システムのアーキテクチャは組織構造やチーム間のコミュニケーションを反映したものになる • 逆コンウェイの法則 § 理想的なアーキテクチャを実現したいなら、アーキテクチャに沿ったチーム構成をとればいいクラウドネイティブなアーキテクチャにはクラウドネイティブなチーム構成が必要

Slide 13

Slide 13 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブではないチーム構成 13 開発チームアプリケーション開発運用チーム成果物の引き継ぎインフラ構築、運用保守開発プロジェクト管理チーム成果物の引き継ぎ要件定義スケジュール調整複雑で明確に定義されていないコミュニケーションパス依存関係が定義されていない、密結合なアーキテクチャのチーム構成

Slide 14

Slide 14 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブで疎結合なチーム構成 14 凝集性の⾼いストリームアラインドチームストリームアラインドチームインフラ構築、運用保守開発要件定義スケジュール調整アプリケーション開発ストリームアラインドチームインフラ構築、運用保守開発要件定義スケジュール調整アプリケーション開発 • 価値のあるサービス、ユーザーストーリー設計、開発、運用を一貫して行う • ビジネスのドメインを取り扱う • 「引き継ぎ」が発生しない • 自己完結できる、明確な責任の境界をもつ • = 高い凝集性引き継ぎなく設計から運用まで担当するため、膨大な学習コストと認知負荷がかかる

Slide 15

Slide 15 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブで疎結合なチーム構成 15 ストリームアラインドチームの負荷を軽減するサポート型チームストリームアラインドチームインフラ構築、運用保守開発要件定義スケジュール調整アプリケーション開発明確に定義されたチーム API サポートチーム負荷の吸収、軽減 • UX スペシャリストアプリケーションのユーザビリティを検証 • セキュリティスペシャリストアプリケーションのアーキテクチャをレビュー • サブシステム構築再利用が容易、または特殊な専門知識が必要になる認証やアルゴリズム基盤などを再利用可能なサブシステムとして提供 • トレーニングストリームアラインドチームの自走を支援 • プラットフォームの提供アプリケーションが企業や業界のポリシーに準拠できるよう「ガードレール」を設定アプリのネットワークやコンピューティングなど下位レイヤを抽象化

Slide 16

Slide 16 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. サポート型チームのプラットフォーム構築 16 プラットフォームチームによりストリームアラインドチームの負荷を軽減ストリームアラインドチームインフラ構築、運用保守開発要件定義スケジュール調整アプリケーション開発明確に定義されたチーム API プラットフォームチーム負荷の吸収、軽減 • プラットフォームの提供アプリケーションが企業や業界のポリシーに準拠できるよう「ガードレール」を設定アプリのネットワークやコンピューティングなど下位レイヤを抽象化プラットフォームエンジニアリング

Slide 17

Slide 17 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームエンジニアリング 17 2022年ごろから注⽬を集めるプラットフォーム構築のアプローチ https://www.gartner.co.jp/ja/articles/what-is- platform-engineering • DevOps / クラウドネイティブなチームが前提 • 「ストリームアラインドチームの負荷を軽減する」が出発点 • 「開発者体験」が最重要視される「プラットフォーム・エンジニアリング」とは、アプリケーションのデリバリとビジネス価値の創出を加速させるための、テクノロジに対する新しいアプローチですインフラストラクチャ・オペレーションの自動化とセルフサービス機能により、開発者エクスペリエンスと生産性を向上させます

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kubernetes プラットフォーム Kubernetes を使ってシステムを管理するプラットフォームを構築 Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage Kubernetes 20

Slide 21

Slide 21 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kubernetes プラットフォーム Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage Kubernetes プラットフォームチームの責任範囲アプリケーションチームの責任範囲 21

Slide 22

Slide 22 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless プラットフォーム Serverless を使ってシステムを管理するプラットフォームを構築 Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage SNS SQS AppSync Step Functions EventBridge API Gateway Lambda 22

Slide 23

Slide 23 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless プラットフォーム Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage SNS SQS AppSync Step Functions EventBridge API Gateway Lambda ユーザーの責任範囲 AWS の責任範囲 ※ サービスに関してはどのサービスを選択し、どのように設定するか 23

Slide 24

Slide 24 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless プラットフォーム︖ これでいい︖ Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage SNS SQS AppSync Step Functions EventBridge API Gateway Lambda プラットフォームチームの責任範囲 AWS の責任範囲アプリケーションチームの責任範囲 24

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリチームとプラットフォームチーム 28 アプリチームプラットフォームチームがボトルネックにプラットフォームチームアプリチームアプリチームアプリ実行環境アプリ実行環境アプリ実行環境アプリ実行環境アプリ実行環境管理の爆発 Security Observability CI/CD Log Storage Network

Slide 29

Slide 29 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. X-as-a-Service / プラットフォームチーム 29 アプリチームプラットフォームチームアプリチームアプリチームアプリ実行環境アプリ実行環境アプリ実行環境アプリ実行環境アプリ実行環境 X-as-a-Service：サービスとしてアプリチームに機能提供

Slide 30

Slide 30 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless プラットフォームがワークしない例 DevOps、クラウドネイティブなチーム構成ではない Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage SNS SQS AppSync Step Functions EventBridge API Gateway Lambda プラットフォームチームの責任範囲 AWS の責任範囲アプリケーションチームの責任範囲 30

Slide 31

Slide 31 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリチームとプラットフォームチーム 31 アプリチーム Application Security Observability CI/CD Log Storage Network プラットフォームチームサービス統合のやり方を変更したい… チケットカスタム対応プラットフォームチームがボトルネックに Integration

Slide 32

Slide 32 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームがワークしない例 DevOps、クラウドネイティブなチーム構成ではない Worker Node Worker Node CI/CD Observability ログ収集 Application Application Log Network Storage SNS SQS AppSync Step Functions EventBridge API Gateway Lambda プラットフォームチームの責任範囲 AWS の責任範囲アプリケーションチームの責任範囲 32

Slide 33

Slide 33 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless 向きなプラットフォーム DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration プラットフォームチームの責任範囲 AWS の責任範囲アプリケーションチームの責任範囲 33

Slide 34

Slide 34 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. • プラットフォームチームがボトルネックになる § 管理の爆発 § チケッティングによるリードタイムの増加 • 責任分解点が定まっていない § アプリチームの求める抽象度を提供できていない 34 よくあるプラットフォームの課題 / 解決提案 X-as-a-Service Self-service のためのカタログ化

Slide 35

Slide 35 text

Slide 36

Slide 36 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームがワークしなかった例 36 Serverless でアプリケーション開発、運用自動化の仕組みを構築したプラットフォームチーム承認ベースの手続きが残っているアプリケーションビジネスロジックにより、サービス統合方法が千差万別で自動化されないサーバーレスサービス利用選定をアプリチームで実施したいプラットフォームチーム選定のアーキテクチャの利用方法が分からない、効果を実感できない、etc. ストリームアラインドチーム構築したプラットフォームが利用されない

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームは開発チームの「邪魔にならない」ようにする。開発チームが開発する上での前提条件をなるべく少なくするのだ。新しい開発者がプラットフォームを使い始めるのがどれだけ簡単かどうかは、 Developer Experience の達成状況についての良いテストになるチームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計 38

Slide 39

Slide 39 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームの設計フロー 39 1. ストリームアラインドチームを一つ選定 2. チームのボトルネック特定 3. ボトルネックの改善を KPI で測る 4. KPI を達成できたら、結果を社内で周知 5. 基盤の活用方法などの勉強会など 6. 他チームに横展開プラットフォームチームプラットフォームストリームアラインドチームアプリケーション

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. ストリームアラインドチームの認知負荷の例 41 • ストリームアラインドチームの負荷 § CI/CD の構築 § セキュリティ対策 • CloudWatch Logs へアクセスできるユーザーを限定する • CloudWatch Logs のデータ保護機能を有効化する • アプリケーションで使⽤しているライブラリの脆弱性をスキャンする § 監視の構築 • トレース、メトリック § etc. プラットフォームチームでどのようにサポートするか

Slide 42

Slide 42 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless 向きなプラットフォーム DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration アプリケーションチームの責任範囲 42 よくあるパターンプラットフォームチームの責任範囲

Slide 43

Slide 43 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Serverless 向きなプラットフォーム DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration アプリケーションチームの責任範囲 43 よくあるパターンカタログカタログ化セルフサービス利用プラットフォームチームの責任範囲

Slide 44

Slide 44 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS で Self Service化 44 https://shorturl.at/9s9KT AWS Service Catalog Amazon CodeCatalyst 音楽配信サービス世界最大手のSpotifyが開発し、2020年に OSSとして公開された開発者ポータルサービスのカタログを作成・管理一貫性のあるガバナンスを達成し、制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイ統合ソフトウェア開発サービス課題の管理・コードリポジトリ、プルリクエストやCI/CD ワークフローとチーム開発に必要な機能の一通りを提供よりマネージド

Slide 45

Slide 45 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Construct Hub / ⼩さなプラットフォーム 45 CDK コンストラクトを発見/共有するポータルを提供 AWS CDK、CDK for Kubernetes (CDK8s)、 CDK for Terraform (CDKTF)、およびその他のコンストラクトベースのツール用に定義されたクラウドアプリケーション設計パターンとリファレンスアーキテクチャを発見/共有するためのポータル

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 有⽤なソリューションや IaC コードの配布 48 フィードバックの内容を受けて有⽤なソリューションを配布し、適⽤するチームを広げる API Gateway 関数 REST API CloudWatch Logs ログ管理ルーティングログ集約データ保護の有効化 AWS CDK コード AWS CDK cdk deploy 環境構築公開ストリームアラインドチーム利用プラットフォームチームプラットフォームチームの責任範囲ストリームアラインドチームの責任範囲 GitHub DynamoDB Traces

Slide 49

Slide 49 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 有⽤なソリューションや IaC コードの配布 49 フィードバックの内容を受けて有⽤なソリューションを配布し、適⽤するチームを広げる AWS CDK コード AWS CDK cdk deploy 環境構築公開ストリームアラインドチーム利用プラットフォームチームプラットフォームチームの責任範囲ストリームアラインドチームの責任範囲 GitHub Application Load Balancer コンテナ Amazon ECS AWS Fargate ロードバランサー CloudWatch Logs ログ管理 HTTP 負荷分散ログ集約データ保護の有効化 ECS/EKS/Serverlessといった選択はアプリチームが決定権を持つ ※ プラットフォームの押し付けは避ける

Slide 50

Slide 50 text

Slide 51

Slide 51 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. ゴールデンパスとテンプレートストリームアラインドチームには膨⼤な学習コスト・認知負荷がかかる特に「開発チーム」に近い組織で、 CI/CD、監視、セキュリティ、ポリシー準拠などにすべてに対応することが困難なケースが多いプラットフォームチームがツールセットやテンプレートを提供 • マネージド IaC オーケストレーションサービス (AWS Service Catalog、Amazon CodeCatalyst など) の活⽤ • カスタム内部開発者プラットフォームの構築 (Backstage、または⾃社構築) • GitOps モデルとツール (Flux、ArgoCD など) の実装 • 再利⽤可能な中央リポジトリ内のテンプレートとドキュメントの管理 • カスタムライブラリあるいはモジュールの構築 (AWS Cloud Development Kit (CDK) コンストラクト/ライブラリ、Terraform モジュールなど) ストリームアラインドチームの負荷を軽減 51 組織のクラウドオペレーションをいかにモダナイズするか https://aws.amazon.com/jp/blogs/news/how- organizations-are-modernizing-for-cloud-operations/

Slide 52

Slide 52 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. セルフサービス化チームを疎結合に保ちつつ、ゴールデンパスを提供する – チームが⾃律的に開発、設計、運⽤できるようにする 52 ストリームアラインドチームインフラ構築、運用保守開発要件定義スケジュール調整アプリケーション開発明確に定義されたチーム API プラットフォームチーム負荷の吸収、軽減 • プラットフォームチームの目的ストリームアラインドチームの負荷を下げて、自律的に設計、開発できるようにする「いちばんシンプルなプラットフォームは、下位のコンポーネントやサービスについて書いた単なるWikiページ上のリストだ。下位のコンポーネントやサービスが常に確実に動作するのであれば、フルタイムのプラットフォームチームは必要ない」チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計

Slide 53

Slide 53 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 内部開発者プラットフォーム/ポータル 53 Internal Developer Portal – 簡単にゴールデンパスに乗れるプラットフォーム内部開発者ポータル Web サービス PUB/SUB サービス機械学習 IaC テンプレート Application Integration ストリームアラインドチームテンプレート選択 IaC ツールの実行、サービス統合の構築プラットフォームチームプラットフォームの構築運用内部開発者プラットフォーム AWS Lambda AWS CodeDeploy サービス統合

Slide 54

Slide 54 text

Slide 55

Slide 55 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ • 最初から誰が使うかもわからない巨⼤なプラットフォームを作らない • プラットフォームも “プロダクト” であり、ユーザーであるアプリケーションチームからのフィードバックによって進化させていく • 何をプラットフォームチームがサポートすべきかはビジネスやプロダクトに依存するので、最⼩限のプラットフォームから始める 55

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームの構築と維持のコスト 58 マルチテナント型 • ⼀つの環境を、複数のチームに共有メリット • トラッキングが楽 • 新機能導⼊、メンテにより全チームが恩恵保守、構築のコスト • 影響範囲の調査、互換性の担保 • テナントの管理 • リソース、権限シングルテナント型プラットフォームチーム A チーム B 環境チーム A チーム B プラットフォーム環境 • 環境を作成してチームに払い出すメリット § 影響範囲が限定的トラッキングのコスト § 各環境が今、どうなっているのかの追跡 § どのチームがどういう環境を使っているのか § 各環境のパッチ当て、アップグレード § 各環境個別の障害調査

Slide 59

Slide 59 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kubernetes を利⽤した共通基盤の例クラウドネイティブな開発に対応していない 59 共通基盤開発チーム運用チーム Kubernetes クラスター Amazon SQS AWS IAM Amazon RDS Kubernetes API の呼び出しクラスターのメンテナンス k8s オートスケール etc. • Kubernetes の習熟が必要 • Kubernetes 外のインフラは申請ベースで変更依頼 • Kubernetes の機能、API は運用チーム向けで、開発チームの負荷が高い • 開発フローの短縮にならない

Slide 60

Slide 60 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 中央集権型のプラットフォームモデル 60 統制を強化できるがチームやワークロードの種類が増えるとプラットフォームチーム負荷が課題になりやすい Application Load Balancer コンテナ Amazon EKS AWS Fargate ロードバランサー CloudWatch Logs ログ管理 HTTP 負荷分散ログ集約イメージレジストリ Amazon ECR コンテナイメージデータ保護の有効化 AWS CDK cdk deploy 環境構築ストリームアラインドチームプラットフォームチームアプリケーションをコンテナイメージとして保存ストリームアラインドチームの責任範囲プラットフォームチームの責任範囲

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブなチーム • プラットフォームチーム § ECSベースで、Terraformのコードに開発ロジックが⼊っている § ECSタスクの数は依頼ベース – EKSで、マニフェストで解消している – マニフェストを開発者に提供しようとしている § プラットフォームから開発チームへの移転 • ストリームアラインドチームチームは、頼まれた仕事に対して、効果的でタイムリーな対応ができているか ︖ 63

Slide 64

Slide 64 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブなチーム • プラットフォームチーム • 認知負荷が⾼い • 引き継ぎが発⽣する • ストリームアラインドチーム負荷の種類 • シンプル • 作業⼿順に従えばいい • 煩雑 • 依頼された変更に対して分析、検討が必要 • 複雑 • 依頼された変更に対して実験、探索を何度も試⾏する特に認知負荷が⾼い、複雑な業務は何か ︖ 64

Slide 65

Slide 65 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. クラウドネイティブなチーム • プラットフォームチーム • ストリームアラインドチーム負荷の種類 • シンプル • 作業⼿順に従えばいい • 煩雑 • 依頼された変更に対して分析、検討が必要 • 複雑 • 依頼された変更に対して実験、探索を何度も試⾏する複雑な業務をプラットフォーム、⾃動化、トレーニング、チーム分割などで解消できるか 65

Slide 66

Slide 66 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. プラットフォームのインターフェース 66 • As-Is • プラットフォームチームのAPI • ストリームアラインチームのAPI • 頑張れば、アプリケーションのメトリクス • コンテナの設定、ルーティングの設定がコミュニケーションベースなので • To-Be • プラットフォームチームのAPI • インフラのピュアな部分 • KubernetesのAPI⾃体がチーム API • ストリームアラインチームのAPI チーム間の契約、API、コミュニケーションパスは何か、チームの関⼼事が明確に分離されているか