記載内容は私個人の見解であり、所属する組織の公式見解ではありません。
はじめに
今注目される「マイクロサービス（Microservices）」とはという記事を投稿したのですが、同様に注目されても良い「モノリスファースト(Monolith First)」という考え方があることをご存じでしょうか？
なぜか、注目されないモノリスファーストについても解説しておきます。
モノリスファーストが求められる背景
先日の投稿でも記載しましたが、マイクロサービス（Microservices）という言葉は2014年5月にJames Lewis氏とMartin Fowler氏が執筆したMicroservices (martinfowler.com)というブログ（以降、”Microservicesブログ”と呼ぶ）で広く認知されるようになったと紹介しました。
しかし、Martin Fowler氏にとっては、マイクロサービスという言葉が想像以上に世の中に広まり、誤った解釈でマイクロサービスが解説されることが多く、それに警笛を鳴らす目的で2015年にMonolith Firstというブログを書いています。
モノリスファーストとは
このブログでは、マイクロサービスを採用したチームを観察して、以下のことが分かったと書かれています。
1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up
成功したマイクロサービスのストーリーは大きくなり過ぎたモノリスを再構築することから始まっている。
2.Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
スクラッチ(新しく開発するという意味)からマイクロサービスとして構築されたシステムのほとんどすべてのケースで深刻な問題に陥っている。
MicroservicesブログではNetflix社などデジタルビジネスで成功した企業が紹介され、Amazonでもマイクロサービスが採用されているという情報が先行し、DXという言葉の広まりと共に、DXを体現するシステムはマイクロサービスで構築するのがトレンドのように捉えられた時期がありました。
しかし、考えてみてください。現在のシステムで重要なのはリーンスタートアップやMVP（Minimum Viable Product）というアジャイル的な考え方であり、アイデアをすぐに形にして顧客に公開し、顧客のフィードバックをもらうことですよね。このような場合、マイクロサービスアーキテクチャのように、どのようなサービス単位にシステムを分割して構築すべきかを検討することに十分な時間を取る余裕は無いのです。
このため、まずは3階層システムのような単純な構成でモノリシックなシステムで構築したものを素早く顧客に公開して顧客からのフィードバックを得ることが必要になります。これがモノリスファーストの考え方です。
Monolith Firstの図が非常に面白いので以下に引用させていただきます。
これを見ていただくと分かるように「Going directly to a microservices architecture is risky」と記載されている線の横にドラゴンのような絵が描かれていますよね。
日本語で言えば「いばらの道」です。
モノリシックなシステムをいつマイクロサービス化するのか
最初はモノリシックなシステムとして素早く顧客にサービスを提供します。顧客の評判が良ければ、システムを顧客ニーズに合わせて拡張していくことにより、ビジネスも拡大していきます。
ただ、ビジネスが好調で、それに合わせてシステムも拡張していくと、ある時点で顧客ニーズに合わせたシステム改修が素早くできなくなるタイミングが訪れます。
システムの一部を修正しようとした時に、システムに与える影響調査のため、システムを利用している周囲の関係部門と調整し、リスクを考慮して修正適用日程を調整することでシステムを改修して顧客にサービスを届けるまでに時間がかかることになるのです。
このタイミングがマイクロサービスを検討するタイミングと言えます。マイクロサービスはシステムをビジネス単位に合わせて分割し、特定のビジネスに対する改修が他のビジネスのサービスに影響しないように分割するため、改修スピードが向上することが考えられます。
まとめ
マイクロサービスはモノリシックな既存システムの改修スピードを向上させるための、一つの手段と捉えるのが良いでしょう。
ただ、改修スピードが遅い理由は様々で、システム改修に必要な承認プロセスが多いだけかもしれないので、まずは改修スピードが遅いと感じたら、その原因を分析するのが良いでしょう。