クラウドインテグレーション事業部の森です。
re:invent 2023 に現地参加しております。
SaaS アプリケーションにおける、ECS fargate のマルチテナント構成についてのセッションに参加したためレポートを共有します。
レポートは4つに分かれており、本記事は第3段になります。
Deploying multi-tenant Saas applications on Amazon ECS and AWS Fargate
SaaS を構築することは顧客の信頼を得ることと同等である
と断言しており、それらは以下4つの項目が言えることであると述べていました。
- I trust your software ”to be available when I need it”
- I trust your software ”to keep my data secure”
- I trust your software ”to get new features I need”
- I trust your business ”to be here for the long term”
確かにカスタマー目線では、可用性やデータセキュリティ、新機能の追加や長期間ビジネスが継続することはそのサービスを信頼するに足る項目だと言えます。
反対に、サービスを提供する側から見るとこの項目は実現が最も難しいものの一つに思えますが、サービス提供者はカスタマーファーストを最重要としてこの項目を認識することが重要だと感じました。
この後本セッションでは、上記4つについてそれぞれ細かく説明する内容となっていました。
本記事では以下についてレポートを共有いたします。
- I trust your software ”to get new features I need”
I trust your software ”to get new features I need”(私の欲しい機能を追加して！)
セッションでは、機能開発とメンテナンスのバランスをとることの重要性を強調しており、どちらかを無視すると潜在的な落とし穴があると述べていました。
特に述べていた内容で驚いたこととして、学習やメンテナンスよりも機能開発を優先するよう開発者に求める企業は、時代遅れのシステムや市場機会の損失につながっている、という箇所は示唆に富んでいて非常に興味深かったです。
ユーザー野求める新機能を開発し続けることが、ユーザーファーストではないことを学べました。
また、バランスとして新機能を実装する際のメンテナンスの重要性を強調して述べており、効率的なデプロイプロセスとワークフローの必要性を述べていました。
述べていたロジックとしては以下です。
- 新機能の実装は結局のところコードの変更である
- 変更には影響が大きい箇所もあり、新たな負担が発生する可能性がある
- その対処法を検討し、学習する必要がある
- そのため新機能を追加するのみでは次第にコードを維持するためのコストが増加していく
上記について、機能実装＝コードの変更であり、コードの変更だけ行うことは実質のところ自らメンテナンスコストを増加させているという学びが有りました。
上記の点から、ECS fargate のメンテナンス領域が小さいことやコンテナであることが、EC2よりもメリットがあると述べていました。
コメント
カスタマーファーストとは何かを本当に考えているAWSならではの考え方を学ぶことができました。
新機能というカスタマーにとっての一過性の喜びに注力しすぎる必要はなく、安定して新機能を提供し続けるだけの体制やアーキテクチャ、開発メンバーの能力開発が永続的な信頼性を生むという、ライフタイムバリューに近い考えに学びが有りました。
第4段はこちら
第4段の I trust your business ”to be here for the long term” については以下です。
