AIアプリを支えるチームの最適な開発環境を整備する / / Optimizing AI Development Environment with Platform/DevOps Engineers

Microsoft AI Tour Tuesday, Feb 20
https://envision.microsoft.com/ja-JP/sessions/3bd5b460-a8fe-406c-8d5a-f7268b6afb9a?source=sessions

AIを使ったアプリを開発する際に個々のソフトウェアエンジニアにどのような環境を用意していますか？これまでローカルPC上の環境だけで開発できたソフトウェアエンジニアは、このAIの時代で様々なAPI連携、ミドルウェア、大規模データを利用することになり、開発環境が複雑になりました。これまでの開発生産性を落とさない AI 時代に必要な開発環境について、これまでチーム開発の環境作りで挑戦と失敗ししながら改善を行っていた経験を元にプラットフォームエンジニアやDevOps、インフラエンジニアからみた視点でご紹介できればと思います。

Transcript

1. 12:50 PM-1:05 PM
2. 12:50 PM-1:05 PM AI アプリを支えるチームの 最適な開発環境を整備する Kodai Sakabe @koudaiii Tuesday, February 20 12:50 PM-1:05 PM
3. 12:50 PM-1:05 PM 本セッションについて  話すこと  AI アプリにおける CICD とフィーチャーフラグ  Azure におけるマネージドサービスから OSS まで様々な手段を紹介  Radius / OpenFeature / Azue Development Environment  話さないこと  Azure OpenAI といった AI 関連のマネージドサービス  本番環境のリファレンスアーキテクチャ  Azure 以外の Microsoft の製品 資料は Speaker Deck サンプルコードは GitHub でご確認いただけます AI を組み込んだアプリは、従来のアプリケーションに比べて複雑なアーキテクチャになることは避けられません。
4. 12:50 PM-1:05 PM Agenda  AI アプリの特徴  Developer Environment  Azure Developer  Appendix  OpenFeature  Radius
5. 12:50 PM-1:05 PM AI アプリの特徴
6. 12:50 PM-1:05 PM AI とアプリの境界点 データフローの分離 Baseline OpenAI end-to-end chat reference architecture https://learn.microsoft.com/azure/architecture/ai-ml/architecture/baseline-openai-e2e-chat
7. 12:50 PM-1:05 PM 本番環境での変化(主に見直しされるポイント) SLO  AI とアプリでアーキテクチャ を疎結合  それぞれスケールできるアー キテクチャ  セキュリティとガバナンス対 策、ネットワークを準備  ミドルウェアや API 外部連 携による SLA の低下 Cost  新規ミドルウェア  外部連携  データ量  ネットワーク  モデル  セキュリティ End-to-end simulation  モデル調製  カテゴリ  評価  Side-by-side  プロンプト  OpenFeature CICD  新規デリバリー  ミドルウェアの CICD  A/B テスト  データによる意思決定
8. 12:50 PM-1:05 PM Building for the future: The enterprise generative AI application lifecycle with Azure AI https://azure.microsoft.com/en-us/blog/building-for-the-future-the-enterprise-generative-ai-application-lifecycle-with-azure-ai/
9. 12:50 PM-1:05 PM LLMOps process flow https://learn.microsoft.com/azure/machine-learning/prompt-flow/how-to-end-to-end-llmops-with-prompt-flow?view=azureml-api-2
10. 12:50 PM-1:05 PM Achieve generative AI operational excellence with the LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/
11. 12:50 PM-1:05 PM Initial  様々な発表がある中で使 うモデルを決め、サービスへ の導入開始  ガイダンスやドキュメントを 見つけること自体が難しい 状態ながらモニタリング Defined  新製品やフレームワークのコ ンポーネントの正しい組み 合せ改善  RAG などの組み合わせを 行い、制度の改善開始 Managed  大規模言語モデルは固有 のデータは知らないことから Prompt の改善と評価を リアルタイムで実施。  さまざまなユースケースにモ デルの最適化 Optimized  ソリューション全体としてプ ライバシー、セキュリティ、ガ バナンスの整備  ソリューション全体として評 価、改善、検証するための 経験やツール  スケールと運用経験の知 見を専用 CICD までの仕 組み LLMOps におけるレベル別 Achieve Generative AI operational excellence with the LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/
12. 12:50 PM-1:05 PM Developer Environment
13. 12:50 PM-1:05 PM 組織のパフォーマンスに 影響ある Four keys metrics Deployment frequency デプロイの頻度 Change lead time コード変更からデプロイするまでの時間 Change failure rate デプロイによる障害率 Failed deployment recovery time デプロイ失敗から復旧にかかる時間 Accelerate State of DevOps 2023 P12 https://cloud.google.com/devops/state-of-devops
14. 12:50 PM-1:05 PM 継続的改善の仕組みを導入期に作れるかが重要 Initial  様々な発表がある中で使 うモデルを決め、サービスへ の導入開始  ガイダンスやドキュメントを 見つけること自体が難しい 状態ながらモニタリング Defined  新製品やフレームワークのコ ンポーネントの正しい組み 合せ改善  RAG などの組み合わせを 行い、制度の改善開始  Developer experience Managed  大規模言語モデルは固有 のデータは知らないことから Prompt の改善と評価を リアルタイムで実施。  さまざまなユースケースにモ デルの最適化  Feature flag で on/off  シームレスな Demo Optimized  ソリューション全体としてプ ライバシー、セキュリティ、ガ バナンスの整備  ソリューション全体として評 価、改善、検証するための 経験やツール  スケールと運用経験の知 見を専用 CICD までの仕 組み Achieve Generative AI operational excellence with the LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/ 継続的改善の仕組み準備
15. 12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。 Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal （https://devportal.microsoft.com/） Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion
16. 12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。 Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal （https://devportal.microsoft.com/） Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion
17. 12:50 PM-1:05 PM Azure Developer
18. 12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。 Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal （https://devportal.microsoft.com/） Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion
19. 12:50 PM-1:05 PM Azure Developer を支える開発環境 Dev Center Microsoft Dev Box ならびに Azure Deployment Environments をプロジェクト単位 にまとめチーム利用可能にし、開発者ポータルを提 供。 Azure Deployment Environments 専用の環境を新規作成。 ARM テンプレートなら びに Azure RBAC の利用できるためセルフサービス ができる Microsoft Dev Box イメージギャラリーを使った VM 起動 GitHub Codespaces Remote Container Azure Virtual Desktop Windows DaaS 環境。マルチセッション可能 Windows 365 マネージド AVD に近いビジネスユーザー利用 DevTest Lab 2016 年リリースした開発用 VM
20. 12:50 PM-1:05 PM Azure Developer を支える開発環境 Dev Center Microsoft Dev Box ならびに Azure Deployment Environments をプロジェクト単位 にまとめチーム利用可能にし、開発者ポータルを提 供。 Azure Deployment Environments 専用の環境を新規作成。 ARM テンプレートなら びに Azure RBAC の利用できるためセルフサービス ができる Microsoft Dev Box イメージギャラリーを使った VM 起動 GitHub Codespaces Remote Container Azure Virtual Desktop Windows DaaS 環境。マルチセッション可能 Windows 365 マネージド AVD に近いビジネスユーザー利用 DevTest Lab 2016 年リリースした開発用 VM
21. 12:50 PM-1:05 PM LLMOps process flow https://learn.microsoft.com/azure/machine-learning/prompt-flow/how-to-end-to-end-llmops-with-prompt-flow?view=azureml-api-2
22. 12:50 PM-1:05 PM https://github.com/koudaiii/my-devcenter
23. 12:50 PM-1:05 PM Deploy environments in CI/CD by using GitHub GitHub Actions で環境の構築 https://devportal.microsoft.com
24. 12:50 PM-1:05 PM Cost 計算は AI に
25. 12:50 PM-1:05 PM Dev Centers / Azure Deployment Environments  Dev Center からプロジェクトが作られ、配下にリソースグループ、サブスクリプシ ョン等が紐づけされる  Azure Deployment Environments は、 azd で作れる環境を Dev Center 配下に provisioning する  リソースグループに環境ができるため  リソースグループ単位でコスト管理ができる  リソースグループ単位で権限も管理ができる  Developer portal ができ、 Ops や Infra エンジニアによって IaC や Azure portal 上で厳密に管理された領域を触れずに利用できる  開発チーム単位または個人単位で Azure 全体を利用実現
26. 12:50 PM-1:05 PM 継続的改善の仕組みを導入期に作れるかが重要 Initial  様々な発表がある中で使 うモデルを決め、サービスへ の導入開始  ガイダンスやドキュメントを 見つけること自体が難しい 状態ながらモニタリング  Developer experience Defined  新製品やフレームワークのコ ンポーネントの正しい組み 合せ改善  RAG などの組み合わせを 行い、制度の改善開始 Managed  大規模言語モデルは固有 のデータは知らないことから Prompt の改善と評価を リアルタイムで実施。  さまざまなユースケースにモ デルの最適化  Feature flag で on/off  シームレスな Demo Optimized  ソリューション全体としてプ ライバシー、セキュリティ、ガ バナンスの整備  ソリューション全体として評 価、改善、検証するための 経験やツール  スケールと運用経験の知 見を専用 CICD までの仕 組み Achieve Generative AI operational excellence with the LLMOps maturity model https://azure.microsoft.com/blog/achieve-generative-ai-operational-excellence-with-the-llmops-maturity-model/ 継続的改善の仕組み準備
27. 12:50 PM-1:05 PM 本セッションについて  話すこと  AI アプリにおける CICD とフィーチャーフラグ  Azure におけるマネージドサービスから OSS まで様々な手段を紹介  Radius / OpenFeature / Azue Development Environment  話さないこと  Azure OpenAI といった AI 関連のマネージドサービス  本番環境のリファレンスアーキテクチャ  Azure 以外の Microsoft の製品 資料は Speaker Deck サンプルコードは GitHub でご確認いただけます AI を組み込んだアプリは、従来のアプリケーションに比べて複雑なアーキテクチャになることは避けられません。
28. 12:50 PM-1:05 PM © Copyright Microsoft Corporation. All rights reserved.
29. 12:50 PM-1:05 PM Appendix: OpenFeature
30. 12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。 Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal （https://devportal.microsoft.com/） Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion
31. 12:50 PM-1:05 PM OpenFeature What's a Feature Flag?  フィーチャーフラグは、ソースコード を変更することなく、製品やサー ビスの特定の機能やコードパス の動作を有効化、無効化、変 更することを可能にするソフト ウェア開発手法 What's OpenFeature?  OpenFeature は、コミュニティ 主導のフィーチャーフラグのAPIを 提供する CNCF Sandbox で あり、フラグ管理ツールと連動で きる Why standardize?  フィーチャーフラグを標準化するこ とで、ツールやベンダーを共通の インターフェイスで統一し、コード レベルでのベンダーロックインを 避けることができる。また、コミュ ニティ全体で共有できる拡張 機能や統合機能を構築するた めのフレームワークを提供する。 https://openfeature.dev/
32. 12:50 PM-1:05 PM OpenFeature https://openfeature.dev/docs/reference/intro/ https://openfeature.dev/ecosystem/
33. 12:50 PM-1:05 PM https://github.com/koudaiii/gostart
34. 12:50 PM-1:05 PM リアルタイムのフラグ管理 main.go func main() { // Use flagd as the OpenFeature provider openfeature.SetProvider(flagd.NewProvider()) // Initialize OpenFeature client client := openfeature.NewClient("GoStartApp") // Initialize Go Gin engine := gin.Default() // Setup a simple endpoint engine.GET("/hello", func(c *gin.Context) { // Evaluate welcome-message feature flag welcomeMessage, _ := client.BooleanValue( context.Background(), "welcome-message", false, openfeature.EvaluationContext{}, ) if welcomeMessage { c.JSON(http.StatusOK, gin.H{"message": newWelcomeMessage}) return } else { c.JSON(http.StatusOK, gin.H{"message": defaultMessage}) return } }) Client と Provider(flagd) 導入 Sample https://github.com/koudaiii/gostart
35. 12:50 PM-1:05 PM flagd server https://github.com/open- feature/flagd OpenFeature 公式のフラグ管理 のプロバイダー。 json ファイルと docker run するだけ。 プロバイダー用 SDK があるため自 作可能。クライアント側でイベント 、フックが提供されているため、イ ベント駆動で処理を追加すること やプロバイダーのステータスからハン ドリング可能。 Flags.flagd.json { "flags": { "welcome-message": { "variants": { "on": true, "off": false }, "state": "ENABLED", "defaultVariant": "off" } } } “on” にファイル上書きで無停止切替
36. 12:50 PM-1:05 PM 新しい機能をサービスに安全に追加するための9つのステップ 1. Create a new runtime configuration directive : 新しい機能のための config を作成し、 default は false に設定。 2. Release a new binary : 参照がない状態でリリース 3. Update the configuration file : config を更新して見えるようにする。ユーザーの導線なし。 4. Update the canary jobs : カナリージョブのみで config を有効にする 5. Update all jobs : 全部公開。この時点で新しい機能が有効。 6. Change the default flag value : flag を default で true になるように変更。 7. Update the configuration file again : config を更新して、 config 参照をなくします。 8. Edit the conditional code execution : 条件付きのコード実行を常に実行するように編集します。 9. Remove the now-unused code : 今は使われていないコードを削除します。 https://www.usenix.org/system/files/login/articles/login_1410_05_klein.pdf Daniel V. Klein、Dina M. Betser、Mathew G. Monroe
37. 12:50 PM-1:05 PM OpenFeature  AI の機能を安全にリリースするためのフィーチャーフラグ  リアルタイムで制御可能な仕組み  その他 secrets や環境変数と分離できる  最適なモデル検証のため flag 利用  API on/off  プレビュー機能として実現 on/off
38. 12:50 PM-1:05 PM Appendix: Radius
39. 12:50 PM-1:05 PM リソースへのアクセスは VPN またはトンネルを張る 等でセキュアにアクセス。または IP 制限や認証認 可。 Developer では、 Dev Portal よりオンボーディン グの環境払い出しと権限付きのリモートアクセスし て利用。 a b a 考慮事項 Dev Portal は Azure 管理者が用意した個々人 のセットアップできる申請サイト。サブスクリプション を分けることで適切な権限委譲とコスト管理可能。 c Microsoft Dev Box は、VM の払い出し。自動 停止やイメージギャラリーを利用できる。 Proxy と して PaaS までをトンネルを張ることでローカル上で 確認できる。IaaS 環境が主な用途。 d Azure Development Environment は、 ARM テンプレートを用いて Azure を払い出しできる。空 テンプレートから作成可能なため、権限委譲するこ とで自由に Developer が環境できる e インフラであれば事前確認して、その後本番に適 用させるといったインフラをインクリメンタルに開発 可能。追加作業について、 azd で可能。 f Azure portal 側の管理は、 Admin またはインフ ラチームのみにし、広い権限と Azure Portal での 情報などの絞り込みができる。 Dev Center のメ ンテナンスする。 g Developer 本番サブスクリプション 検証サブスクリプション *疑似本番サブスクリプション 運用サブスクリプション 開発サブスクリプション ML Ops Dev Center Azure Portal Dev Portal （https://devportal.microsoft.com/） Azure Deployment Environment Microsoft Dev Box b c d e f g Project: QA Project: Production Project: Develop Prompt Gateway Bastion
40. 12:50 PM-1:05 PM Cloud-native application platform that works on any cloud https://radapp.io/
41. 12:50 PM-1:05 PM Why is building and running microservice apps hard?  Complex architectures  Cross-platform portability Enforcing best-practices Troubleshooting experiences
42. 12:50 PM-1:05 PM Standardized “app” layer across platforms On-premises
43. 12:50 PM-1:05 PM
44. 12:50 PM-1:05 PM Envrironment XXX_URL には、 接続可能であ れば、 Docker や AWS RDS や Azure SQL DB 利用可能であり 、 Application と Environment が切り離されている状態を radius が行っている。 func main() { ctx := context.Background() // cf. "sqlserver://sa:pa@localhost:1433?database=db" mssqldbURL := os.Getenv("MSSQL_SERVER_URL") // Open a MSSQL database. sqldb, err := sql.Open("sqlserver", mssqldbURL) if err != nil { panic(err) } ・・・ main.go
45. 12:50 PM-1:05 PM https://github.com/koudaiii/first-app
46. 12:50 PM-1:05 PM rad init Console on MacOS $ curl -fsSL "https://raw.githubusercontent.com/radius-project/radius/main/deploy/install.sh" | /bin/bash $ rad init Initializing Radius. This may take a minute or two... Install Radius v0.30.0 - Kubernetes cluster: minikube - Kubernetes namespace: radius-system Create new environment default - Kubernetes namespace: default - Recipe pack: local-dev Scaffold application first-app Update local configuration Initialization complete! Have a RAD time
47. 12:50 PM-1:05 PM radius-system and recipes Console on MacOS $ kubectl get deployments -n radius-system NAME READY UP-TO-DATE AVAILABLE AGE applications-rp 1/1 1 1 2d21h bicep-de 1/1 1 1 2d21h contour-contour 1/1 1 1 2d21h controller 1/1 1 1 2d21h ucp 1/1 1 1 2d21h $ rad recipe list RECIPE TYPE TEMPLATE KIND TEMPLATE VERSION TEMPLATE default Applications.Datastores/redisCaches bicep ghcr.io/radius-project/recipes/local-dev/rediscaches:0.30 default Applications.Datastores/sqlDatabases bicep ghcr.io/radius-project/recipes/local-dev/sqldatabases:0.30 default Applications.Messaging/rabbitMQQueues bicep ghcr.io/radius-project/recipes/local-dev/rabbitmqqueues:0.30 default Applications.Dapr/pubSubBrokers bicep ghcr.io/radius-project/recipes/local-dev/pubsubbrokers:0.30 default Applications.Dapr/secretStores bicep ghcr.io/radius-project/recipes/local-dev/secretstores:0.30 default Applications.Dapr/stateStores bicep ghcr.io/radius-project/recipes/local-dev/statestores:0.30 default Applications.Datastores/mongoDatabases bicep ghcr.io/radius-project/recipes/local-dev/mongodatabases:0.30
48. 12:50 PM-1:05 PM radius getting started guide app.bicep import radius as radius @description('The Radius Application ID. Injected automatically by the rad CLI.') param application string resource demo 'Applications.Core/containers@2023-10-01-preview' = { name: 'demo’ properties: { application: application container: { image: 'ghcr.io/radius-project/samples/demo:latest’ ports: { web: { containerPort: 3000 } } } } } https://docs.radapp.io/getting-started/
49. 12:50 PM-1:05 PM connection rad run app.bicep $ rad run app.bicep Building app.bicep... Deploying template 'app.bicep' for application 'first-app' and environment 'default' from workspace 'default'... Deployment In Progress... Completed db Applications.Datastores/redisCaches . demo Applications.Core/containers Deployment Complete Resources: demo Applications.Core/containers db Applications.Datastores/redisCaches Starting log stream... + redis-r5tcrra3d7uh6-5489d59f5-2gmbw › redis + redis-r5tcrra3d7uh6-5489d59f5-2gmbw › redis-monitor https://docs.radapp.io/getting-started/ https://github.com/koudaiii/first-app
50. 12:50 PM-1:05 PM Radius on GitHub Codespaces
51. 12:50 PM-1:05 PM Radius  マイクロサービスで複雑になったアーキテクチャをシンプルなプラットフォーム実現  軽量の Kubernetes を利用して GitHub Codespaces 上で実行可能  Kubernetes を利用した開発環境  Bicep を local に対して実行するため、 Bicep がよりインフラからアプリエンジニ アに対して利用しやすい  Application と Environment を分離、 Environment は rad switch コマン ドで環境切替