モノリスファースト

マイクロサービスアーキテクチャを採用しているチームの話を聞いていると、共通のパターンに気づきました。

1. 成功したマイクロサービスの話はほとんどすべて、肥大化しすぎたモノリスを分割することから始まっています。
2. 最初からマイクロサービスシステムとして構築されたシステムで問題がなかったという話は、ほとんど聞いたことがありません。

このパターンから、たとえアプリケーションが十分に大きくなり、マイクロサービスにする価値があると確信している場合でも、新しいプロジェクトをマイクロサービスで始めるべきではないという主張が多くの同僚から出ています。

マイクロサービスは有用なアーキテクチャですが、その提唱者でさえ、それを使用すると大きなマイクロサービスプレミアムが発生すると言っています。つまり、より複雑なシステムでのみ有用ということです。このプレミアム（本質的にサービススイートの管理コスト）はチームの速度を低下させるため、単純なアプリケーションではモノリスが有利になります。このことから、マイクロサービスアーキテクチャが後で役立つ可能性があると思われる場合でも、最初に新しいアプリケーションをモノリスとして構築すべきであるという、モノリスファースト戦略を強力に主張することになります。

これの最初の理由は、古典的なYAGNIです。新しいアプリケーションを開始するとき、それがユーザーにとって有用であるとどれほど確信できますか？設計が不十分だが成功したソフトウェアシステムを拡張することは難しいかもしれませんが、その逆よりも良い状態です。今では認識されているように、ソフトウェアのアイデアが役立つかどうかを知る最良の方法は、その単純なバージョンを作成し、それがうまくいくかどうかを確認することです。この最初のフェーズでは、スピード（したがってフィードバックのサイクルタイム）を優先する必要があるため、マイクロサービスのプレミアムは避けるべきです。

マイクロサービスで始めることの2番目の問題は、サービス間の良好で安定した境界を思いついた場合にのみうまく機能するということです。これは本質的に、適切な境界コンテキストのセットを作成する作業です。サービス間の機能のリファクタリングは、モノリスよりもはるかに困難です。しかし、経験豊富なアーキテクトでさえ、使い慣れたドメインで作業する場合でも、最初から境界を正しく設定することは非常に困難です。最初にモノリスを構築することで、マイクロサービス設計がそれらの上に糖蜜の層を塗る前に、適切な境界が何であるかを理解できます。また、より細かいサービスに必要なマイクロサービス前提条件を開発する時間も与えられます。

モノリスファースト戦略を実行するさまざまな方法を聞いたことがあります。論理的な方法は、ソフトウェア内のモジュール性（API境界とデータの保存方法の両方）に注意を払いながら、モノリスを慎重に設計することです。これをうまく行えば、マイクロサービスへの移行は比較的簡単になります。ただし、このアプローチでうまくいったという話を十分に聞いたことがある場合は、このアプローチにずっと安心できます。[1]

より一般的なアプローチは、モノリスから始めて、エッジでマイクロサービスを徐々に剥がしていくことです。このようなアプローチでは、マイクロサービスアーキテクチャの中心にかなりのモノリスが残る可能性がありますが、モノリスが比較的静止している間、ほとんどの新しい開発はマイクロサービスで行われます。

もう1つの一般的なアプローチは、モノリスを完全に置き換えることです。これを誇りに思うアプローチと見なす人はほとんどいませんが、モノリスを使い捨てのアーキテクチャとして構築することには利点があります。特にモノリスが迅速な市場投入につながる場合は、破棄するモノリスを構築することを恐れないでください。

私が遭遇した別のルートは、最終的に到達する予定のものよりも大きい、いくつかの粗粒度のサービスから始めることです。これらの粗粒度のサービスを使用して、複数のサービスで作業することに慣れながら、このような粗い粒度によって、サービス間のリファクタリングの量を減らせるという事実を享受します。次に、境界が安定したら、より細かいサービスに分割します。[2]

私の連絡先の大部分はモノリスファーストアプローチを支持していますが、決して全会一致ではありません。反対の意見では、マイクロサービスから始めることで、マイクロサービス環境での開発のリズムに慣れることができると述べています。モノリスを、マイクロサービスに簡単に分割できるような十分にモジュール化された方法で構築するには、多くの規律、おそらく過剰な規律が必要になります。マイクロサービスから始めることで、誰もが最初から個別の小さなチームで開発することに慣れ、サービス境界で区切られたチームを持つことで、必要に応じて開発作業を拡大することがはるかに簡単になります。これは、早期に十分に安定した境界を思いつく可能性が高いシステム交換に特に有効です。証拠は乏しいですが、チームでマイクロサービスシステムを構築した適切な経験がない限り、マイクロサービスから始めるべきではないと感じています。

モノリスファースト戦略を使用するかどうかを決定する方法を明確に把握するための逸話がまだ不足していると感じています。これらはマイクロサービスにおける初期段階であり、学ぶべき逸話は比較的少ないです。そのため、これらのトピックに関する誰かのアドバイスは、どれほど自信を持って主張していても、暫定的なものと見なす必要があります。