モノリスファースト

チームが マイクロサービスアーキテクチャ、私は共通のパターンに気づきました。

1. マイクロサービスの成功事例のほとんどは、モノリスが大きくなりすぎて分割されたことから始まった。
2. 私が聞いたマイクロサービスシステムとしてゼロから構築されたシステムのほとんどすべてのケースでは、深刻な問題に陥っています。

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

マイクロサービスは便利なアーキテクチャだが、その支持者でさえも、それを使用することで大きなコストがかかると言っている。
マイクロサービスプレミアムつまり、より複雑なシステムでのみ役立ちます。このプレミアム、つまり一連のサービスの管理コストはチームのスピードを低下させ、よりシンプルなアプリケーションにはモノリスが有利になります。これは、モノリスファースト戦略を支持する強力な議論につながります。つまり、後でマイクロサービス アーキテクチャのメリットが得られる可能性が高いと思われる場合でも、最初は新しいアプリケーションをモノリスとして構築する必要があります。

最初の理由は古典的なものだ ヤグニ新しいアプリケーションの開発を始めるとき、それがユーザーにとって役に立つかどうかはどの程度確信できますか? 設計が悪くても成功しているソフトウェア システムを拡張するのは難しいかもしれませんが、それでも逆の場合よりはましです。今認識しているように、ソフトウェアのアイデアが役に立つかどうかを調べる最善の方法は、多くの場合、そのシンプルなバージョンを構築して、それがどれだけうまく機能するかを確認することです。この最初のフェーズでは、速度 (つまりフィードバックのサイクル時間) を優先する必要があるため、マイクロサービスのプレミアムは不要です。

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

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

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

もう一つの一般的なアプローチは、モノリスを完全に置き換えることです。これを誇りに思う人はほとんどいませんが、モノリスを
犠牲的な建築特にモノリスによってすぐに市場に投入できる場合は、破棄することになるモノリスを構築することを恐れないでください。

私が見つけたもう 1 つの方法は、最終的に必要になると思われるサービスよりも大きい、粒度の粗いサービスをいくつか用意して開始することです。これらの粒度の粗いサービスを使用して、複数のサービスの操作に慣れると同時に、このような粒度の粗さによってサービス間のリファクタリングの量が減るという事実を楽しみます。その後、境界が安定したら、粒度の細かいサービスに分割します。

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

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

謝辞

この考えの多くは、同僚の James Lewis、Sam Newman、Thiyagu Palanisamy、Evan Bottcher から拝借したものです。以前の草稿に対する Stefan Tilkov のコメントは、私の考えを明確にする上で重要な役割を果たしました。Chad Currie は、美しいグリフィ ドラゴンを作成しました。Steven Lowe、Patrick Kua、Jean Robert D’amore、Chelsea Komlo、Ashok Subramanian、Dan Siwiec、Prasanna Pendse、Kief Morris、Chris Ford、Florian Sellmayr は、社内のメーリング リストで草稿について議論しました。