この記事は公開されてから1年以上経過しており、最新の内容に追従できていない可能性があります。
-
これはアプリケーションアーキテクチャのひとつ
-
ひとことでいうと、アプリケーション全体が単一のデプロイでできるような状態
- この記事ではECサイトを例に上げている。
- ショップとしてのフロントエンド
- アカウント管理
- 在庫管理
- 配送管理
- これらを単一のアプリケーションとして開発、デプロイする。
- この記事ではECサイトを例に上げている。
-
Monolithicのメリットは簡単でわかりやすいところにあるが、逆にデメリットにもなる。
- 開発は１箇所でよい
- 言語やフレームワークによる制約が生まれる
- コード量が大きくなる
- デプロイも１個でよい
- 開発の規模が増えるとデプロイ回数が増えていくが並行したデプロイが出来ずリリース調整みたいなことが必要
- スケールもまるごと増やせばよい
- コンポーネントによる負荷の調整が難しい（例えば、ある機能はCPUをよく使うが、別の機能はメモリをよく使う、とか…？）
- 開発は１箇所でよい
-
似た（同じレベル）のアーキテクチャとして、Microservice Architecture がある。
- これは次に読む。
-
例えば、アプリケーションがどうなっていくのか不明確なときとか、サクッと世の中に出していくぞ！みたいなときは簡単（いろいろなことを考えずに済む）なので、この選択はいいとおもう
- 最初から大規模な継続的な開発になることが見込まれる場合、これを選択するのは悪手なので、初手Microservie Architectureがいいんじゃないだろうか。
- とはいえ、最近のクラウド事情もどんどんスタイリッシュになっている。
- 例えばAPIやデータストアをGCPないしAWSを使う（Google Cloud RunとかAWS App Runnerで自分たちのアプリケーションをホスト出来る）
- で、フロントエンドをNetlifyやVercelで提供する。
- そうすると、自分たちでインフラストラクチャをメンテナンスしなくてよくなるので、よりアプリケーションに集中できる。
- みたいなこともできる。
- これは Microservices か？と言われるとわからない。
- APIとフロントエンドは分かれるが、APIもフロントエンドもそれぞれで全部入りに出来る。そうするとMonolithicなんじゃないだろうか。
- Microservicesの記事も読んでからまた考えたいけれど、Microservicesはアプリケーションの話だけではなくて、作っている人達、組織の話にも通じるんじゃないだろうか。
- クラウドネイティブ、な感じではあると思う。