モノリスとは何か?1つのcodebase、1つのdeploy
モノリスは、すべての機能が1つのcodebaseに存在し、1つのデプロイ可能な単位としてリリースされる単一のアプリケーションです。
モノリスはすべてを一緒に保持します。UI、ビジネスロジック、データアクセスが1つのartifactとしてコンパイルされdeployされます。ほとんどのシステムにとってデフォルトの出発点であり、分割することへの誇大宣伝にもかかわらず、よく構造化されたモノリスはしばしば正しい選択です。その単一artifactという形は、CI/CDに爽やかなほどシンプルな話をもたらします。
モノリスの姿
1つのリポジトリ、1つのbuild、1つのデプロイ可能なartifact。リクエストはネットワークホップではなくプロセス内の関数呼び出しを介して各層を流れることができるため、service discoveryもサービス間認証も、推論すべき分散障害もありません。
利点
- シンプルなdeploy: 1つのartifact、1つのrelease。
- 簡単なローカル開発: アプリ全体をラップトップ上で実行できます。
- ネットワークの往復ではなく高速なプロセス内呼び出し。
- 単一プロセスでの分かりやすいエンドツーエンドテスト。
限界が現れる場所
codebaseとチームが成長するにつれて、1つの共有buildがボトルネックになります。すべての変更がすべてを再buildし再deployし、スケールするにはアプリ全体を複製する必要があり、1つの悪いcommitがrelease全体をブロックする可能性があります。
CI/CDの構図
モノリスはちょうど1つのpipelineを持ち、推論しやすいですが遅くなりがちです。すべての変更でテストスイート全体が実行されるため、アプリが成長するにつれてbuild時間が徐々に増えます。caching、テストの並列化、選択的なテスト実行が、そのpipelineを速く保つための一般的なレバーです。
モノリスは雑然という意味ではない
モノリスでも内部的にきれいに階層化できます。区別はdeploymentの形であり、コードの品質ではありません。明確なモジュール境界を持つ整然としたモノリスは、定義の不十分なサービスの乱立よりも運用しやすいことがよくあります。
1つのpipelineを速く保つ
すべてが単一のpipelineで実行されるため、build時間が注視すべきものです。依存関係のcachingとwarmなrunner(Latchkeyが提供するような)は、そうでなければ大きなモノリシックbuildで積み重なるcold startの税金を削減します。
重要なポイント
- モノリスは、1つの単位としてbuildされdeployされる1つのcodebaseです。
- 最もシンプルなCI/CDの話をもたらしますが、成長するにつれて遅くなる単一のpipelineを持ちます。
- モノリスはdeploymentの形を表すものであり、コードがよく整理されているかどうかを表すものではありません。