Platform Engineering with CodeCatalyst

Slide 1

Slide 1 text

© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Platform Engineering on Serverless Amazon CodeCatalyst による実践編 S E R V E R L E SS M E ET U P O S A K A # 0 3 Kensuke Shimokawa Serverless Specialist Amazon Web Services Japan G.K.

Slide 2

Slide 2 text

Myself 2 Kensuke Shimokawa Amazon Web Services Serverless Specialist _kensh Slides https://speakerdeck.com/_kensh Qiita https://qiita.com/_kensh

Slide 3

Slide 3 text

Agenda • Platform Engineering on Serverless の “おさらい” • Platform Engineering on Serverless の “実践” • AWS が提供する Platform Engineering Service • X-as-a-Service モデルに沿った責任境界 • Golden Path の提供 • Catalog から Blue print を fork • Catalog version が update され App team に pull request 3

Slide 4

Slide 4 text

Platform Engineering on Serverless の “おさらい” 4

Slide 5

Slide 5 text

• プラットフォームチームがボトルネックになる § 管理の爆発 § チケッティングによるリードタイムの増加 • 責任分解点が定まっていない § アプリチームの求める抽象度を提供できていない 5 よくあるプラットフォームの課題

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Proxy pattern / Layered pattern 7 アプリチームプラットフォームチームがボトルネックにプラットフォームチームアプリチームアプリチームアプリ実行環境アプリ実行環境アプリ実行環境アプリ実行環境アプリ実行環境管理の爆発 Security Observability CI/CD Log Storage Network

Slide 8

Slide 8 text

X-as-a-Service pattern 8 アプリチームプラットフォームチームアプリチームアプリチームアプリ実行環境アプリ実行環境アプリ実行環境アプリ実行環境アプリ実行環境 X-as-a-Service：サービスとしてアプリチームに機能提供

Slide 9

Slide 9 text

self-service pattern 9 フィードバックの内容を受けて有⽤なソリューションを配布し、適⽤するチームを広げる API Gateway 関数 REST API CloudWatch Logs ログ管理ルーティングログ集約データ保護の有効化 AWS CDK コード AWS CDK cdk deploy 環境構築公開ストリームアラインドチーム利用プラットフォームチームプラットフォームチームの責任範囲ストリームアラインドチームの責任範囲 GitHub DynamoDB Traces

Slide 10

Slide 10 text

self-service + catalog DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration アプリケーションチームの責任範囲 10 よくあるパターン Catalog カタログ化セルフサービス利用プラットフォームチームの責任範囲 AWSの責任範囲 Security

Slide 11

Slide 11 text

Platform Engineering on Serverless の “実践” 11

Slide 12

Slide 12 text

Platform Engineering Principle • ⼩さく始めて、⼤きく育てる • ボトルネックシフトを避ける • ゲート(⾨番)ではなく、ガードレール(⼼理的安全性) • 中央集権(統制思考)から⾃治権(Ownership/Self-service)へ 12

Slide 13

Slide 13 text

Platform Engineering Principle • ⼩さく始めて、⼤きく育てる – 最初から誰が使ってくれるかも分からない重厚⻑⼤な Platform を作らない – Product としての Platform を意識 – Platform 利⽤者がどのように良くなっているか観測する • ボトルネックシフトを避ける – チームの負荷軽減のために別の負荷を導⼊しない – チームの負荷を別のチームの負荷に置き換えない – ボトルネックではない箇所に注⼒しても解消されない • ゲート(⾨番)ではなく、ガードレール(⼼理的安全性) • 中央集権(統制思考)から⾃治権(Ownership/Self-service)へ – 開発者がOwnershipを持つ 13

Slide 14

Slide 14 text

self-service + catalog DevOps、クラウドネイティブなチーム構成 CI/CD Observability ログ収集 Application Application インフラストラクチャ SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration ガードレール Configuration アプリケーションチームの責任範囲 14 よくあるパターン Catalog カタログ化セルフサービス利用プラットフォームチームの責任範囲 AWSの責任範囲 Security

Slide 15

Slide 15 text

AWS が提供する Platform Engineering Service 15

Slide 16

Slide 16 text

CodeCatalyst を使ったことありますか︖ 16

Slide 17

Slide 17 text

Amazon CodeCatalyst 17 ü マネージド ü オールインワン ü 統合されている ü セキュリティ重視 ü フレキシブル Code Build Test Deploy … Collaborate Project management Plan

Slide 18

Slide 18 text

プロジェクトのセットアップを加速 19 統合プロジェクトツールを数分でセットアップ適切に設計されたアプリケーションパターンのライブラリから選択 GitHub や Jira を使い続けることも可能既存のプロジェクトの作業を継続することも可

Slide 19

Slide 19 text

Blueprint の例 20 シングルページアプリケーション REST API ・基本的なウェブ 3層・Java/Node.js API ・データの ETL 処理・画像/⽂書処理などそのほかにも︕ これらをベースにしてすぐに開発が始められる

Slide 20

Slide 20 text

X-as-a-Service モデルに沿った責任境界 21

Slide 21

Slide 21 text

App Team と Platform Team の密結合ってどうやって解消するの︖ 22

Slide 22

Slide 22 text

Serverless Platform の責任共有モデル Application Application SNS SQS AppSync Step Functions EventBridge API Gateway Lambda Integration Configuration アプリケーションチームの責任範囲 23 CI/CD Observability ログ収集ガードレール Catalog プラットフォームチームの責任範囲 Security

Slide 23

Slide 23 text

24 CI/CD Observability ログ収集ガードレールプラットフォームチームの責任範囲アプリケーションの稼動中に作用する範囲 Catalog Security

Slide 24

Slide 24 text

25 CI/CD Observability ログ収集ガードレールプラットフォームチームの責任範囲アプリケーションの構築中に作用する範囲 Catalog Security

Slide 25

Slide 25 text

26 CI/CD Observability ログ収集ガードレール AWS Account Single Account 戦略？ Multi Stage delivery 戦略 • Development Stage • Staging Stage • Production Stage Stage ごとに Account 分けたいのでは？ Catalog Security 密結合に

Slide 26

Slide 26 text

Catalog 27 CI/CD Observability ログ収集ガードレール AWS Account Cross Account で別 Product 環境にあるカタログを取りに行く？ Multi Account 戦略 • Product A • Product B • Product C Product の Account 戦略にカタログ位置が依存しないようにしたいのでは？ Security 密結合に

Slide 27

Slide 27 text

28 CI/CD Observability ログ収集ガードレール Catalog Application AppSync Step Functions Lambda Integration Configuration API Gateway Security

Slide 28

Slide 28 text

29 CI/CD Catalog Amazon CodeCatalyst (Internal Developer Platform) Golden Path in IDP Observability ログ収集ガードレール Application AppSync Step Functions Lambda Integration Configuration API Gateway AWS Account Golden Path in Stack Blue Print Security

Slide 29

Slide 29 text

30 Workflow Catalog Amazon CodeCatalyst Documentation Issue Test Coverage Report Source repositories Identity, Permissions, Team Dev Environments (Internal Developer Platform) Golden Path in IDP Space, Project Observability ログ収集ガードレール Application AppSync Step Functions Lambda Integration Configuration API Gateway AWS Account Golden Path in Stack Blue Print Security

Slide 30

Slide 30 text

31 Workflow Catalog AWS Account Amazon CodeCatalyst Documentation Issue Test Coverage Report Source repositories Identity, Permissions, Team Dev Environments (Internal Developer Platform) Golden Path in IDP Space, Project Multi Accounts をサポート

Slide 31

Slide 31 text

32 Workflow Amazon CodeCatalyst Space, Project deploy, configure... 請求 • Space に AWS アカウントとの紐付けを設定することができる • 紐付けられた AWS アカウントに対しては以下ができるようになる • Workflow からの AWS リソースアクセス • Workflow からの VPC 接続 • 料⾦の請求および管理イベントのログの出⼒ (請求アカウントとして設定したアカウント) AWS Account 請求アカウント Dev AWS Account Staging AWS Account Prod AWS Account

Slide 32

Slide 32 text

33 Workflow Amazon CodeCatalyst Dev AWS Account AppSync Step Functions Lambda API Gateway IAM Role (Deployment) Action Action AWS Account (Dev) Space, Project Action どの AWS アカウントに接続するかどの IAM Role を引き受けるかを指定し一時クレデンシャルを取得アクセス先アカウントで利用可能な IAM Role の中から用途に応じた適切なものを選択して引き受け、AWS リソースにアクセス deploy, configure...

Slide 33

Slide 33 text

X-as-a-Service モデルのまとめ • ゲート(⾨番)ではなく、ガードレール(⼼理的安全性) § 統制系とアプリ系が密結合になると ”⾨番” 思考に • 中央集権(統制思考)から⾃治権(Ownership/Self-service)へ § 統制系とアプリ系が密結合になると ”中央集権” 思考に 34 構築中に作用する X-as-a-Service 要素については、開発環境、ステージ環境、商用環境から適切に切り離す

Slide 34

Slide 34 text

Golden Path の提供 35

Slide 35

Slide 35 text

Golden Path 36 • ストリームアラインドチームには膨⼤な学習コスト・認知負荷がかかる § 特に「開発チーム」に近い組織で、CI/CD、監視、セキュリティ、ポリシー準拠などにすべてに対応することが困難なケースが多いストリームアラインドチームの負荷を軽減組織のクラウドオペレーションをいかにモダナイズするか https://aws.amazon.com/jp/blogs/news/how-organizations-are-modernizing-for-cloud-operations/ • プラットフォームチームがツールセットやテンプレートを提供 • マネージド Internal Developer Platform (Service Catalog, CodeCatalyst, Backstage etc. ) の活⽤ • 再利⽤可能な中央リポジトリ内のテンプレートとドキュメントの管理

Slide 36

Slide 36 text

Golden Path の提供ってどうやってますか︖ 37

Slide 37

Slide 37 text

Catalog から Blue print を fork 39

Slide 38

Slide 38 text

Catalog から Blue print を fork 40 App team App Blue print platform team fork push push clone pull request merge Catalog

Slide 39

Slide 39 text

41 Catalog から blue printを選択しfork blue print には sercurity, reliability, cost optimise, CI/CD, performance の best practice が Golden Path としてカタログ化されている

Slide 40

Slide 40 text

42 選択する際に、blue print の詳細が確認できる self-service として機能するために App team 側で、機能・非機能要件を満たしているか判断できる必要な情報を platform team 側で記述する

Slide 41

Slide 41 text

43 blue print には App sourceだけでなく CI/CD pipeline も用意されていて初回は自動で trigger される

Slide 42

Slide 42 text

44 CodeCatalyst では開発環境も用意

Slide 43

Slide 43 text

45 CodeCatalyst service 内で host される instance にSSHで接続 Local の VS Code で開発

Slide 44

Slide 44 text

fork project から、merge (Catalog) 46 App team App Blue print platform team fork push push clone pull request merge Catalog blue print に bug や security issue があれば、platform team に pull request を送る

Slide 45

Slide 45 text

Catalog version が update され App team に pull request 47

Slide 46

Slide 46 text

Golden Path の更新ってどうやってますか︖ 48

Slide 47

Slide 47 text

Catalog update に伴う pull request 49 App team App Blue print platform team fork push clone push pull request merge Catalog V1 -> V2 V2

Slide 48

Slide 48 text

50 blue print には機能追加や bug fix が適用される適用時に version 選択と、diff を確認

Slide 49

Slide 49 text

52 blue print が更新された際に、pull request が App team に来るので diff をみて受け入れるか決定

Slide 50

Slide 50 text

Golden Path の提供のまとめ • ⼩さく始めて、⼤きく育てる – 最初から誰が使ってくれるかも分からない重厚⻑⼤な Platform を作らない – Product としての Platform を意識 – Platform 利⽤者がどのように良くなっているか観測する • ボトルネックシフトを避ける – チームの負荷軽減のために別の負荷を導⼊しない – チームの負荷を別のチームの負荷に置き換えない – ボトルネックではない箇所に注⼒しても解消されない 53

Slide 51

Slide 51 text

Key takeaways 54

Slide 52

Slide 52 text

Key takeaways • ⼩さく始めて、⼤きく育てる – 最初から誰が使ってくれるかも分からない重厚⻑⼤な Platform を作らない – Product としての Platform を意識 – Platform 利⽤者がどのように良くなっているか観測する • ボトルネックシフトを避ける – チームの負荷軽減のために別の負荷を導⼊しない – チームの負荷を別のチームの負荷に置き換えない – ボトルネックではない箇所に注⼒しても解消されない • ゲート(⾨番)ではなく、ガードレール(⼼理的安全性) • 中央集権(統制思考)から⾃治権(Ownership/Self-service)へ – 開発者がOwnershipを持つ 55 Readme/wiki, 開発環境の準備, AWS 提供のカタログ利用くらいから始めてみては？チームのボトルネックが何なのかを把握する CodeCatalystの全ての機能を利用しなくても良い X-as-a-service pattern で自走できる範囲を拡大する Platform team は御用聞ではない Platform team は監査員ではない

Slide 53

Slide 53 text

Thank you! 56 Kensuke Shimokawa Amazon Web Services Serverless Specialist _kensh Slides https://speakerdeck.com/_kensh Qiita https://qiita.com/_kensh