マイクロサービス：MonolithFirst？

私はすべての長所と短所、いつ、なぜなどの高レベルの概要を取得しようとするマイクロサービスアーキテクチャを研究してきました。私が読んで/見ている情報の多くは、ThoughtWorks（Martin Fowler、Neal Fordなどからのものです） al）。

この問題に関するMartin Fowlerの仕事の大部分は数年前のものであり、Microservices（プログラミングの一般的な名称ではないが）がまだ若かったため、私はその多くを少しずつ理解しました。

特に、これは次のとおりです。

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

• 成功したマイクロサービスストーリーのほとんどすべては、大きくなりすぎて分割されたモノリスから始まりました。
• 最初からマイクロサービスシステムとして構築されたシステムについて聞いたほとんどすべての場合、それは深刻な問題に終わっています。

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

（参照：https : //martinfowler.com/bliki/MonolithFirst.html-彼らを強調）

さて、3年後、マイクロサービスがよりユビキタスな言葉になりましたが、新しいシステムは通常、最初により大きい（-microservice-but-smaller-than-monolith）サービスチャンクを用意し、それらは進化的測定の一部としてより細かく？

または、上記のステートメントとは対照的に、きめ細かなマイクロサービスアーキテクチャを使用してプロジェクトをゼロから開始する基準はありますか？

正気な一般的なアプローチのようですが、コミュニティの考えに興味があります。

あなたの会社がしばらくの間マイクロサービスを行っている場合、いくつかの部分はすでに構築されている可能性があり、単にそれらを組み込む必要があります。例としては、サービスとしての認証やblobデータの保存などが考えられます。その場合、すでに境界を定義しており、新しいアプリケーションでコードを再利用しています。それはいいことだ。

境界をどこに置く必要があるかわからない新しいコードの場合は、1つのサービスでビルドします。モジュール化しておくと、必要に応じてマイクロサービスを分割できます。特に、他のサービスとは異なるスケーリングが必要なサービスの一部を見つけた場合。

マイクロサービスの利点は、インスタンスを追加して、オンデマンドで実行される作業をスケーリングできることです。作業の一部が急増している場合は、それを独自のマイクロサービスに分離することは理にかなっています。

一般に：

• すでにマイクロサービスを構築している場合は、それらを再利用します
• 新しいものを構築する場合は、まずアイデアを機能させます
• 構築中は、一部のサービスを簡単に分割できるように、モジュール化を維持してください
• 構築しているときに、サービスの一部をオンデマンドで異なるレートでスケーリングできるようにする必要がある場合は、それを独自のサービスに分離します

マーティンファウラーのような評判の高い賢い人々から有用なガイドラインが聞こえ、それから、決してそれを揺るがすことのできない堅固な教義に変えることがよくあります。

あなたはそれらの意味するところの精神でそのような発言をしなければなりません。マーティンファウラーは、分析によって人々を麻痺から救い、最初に機能する何かを構築するように伝えようとしています。アプリケーションが実際にどのように機能するかについて理解できたら、いつでも分解できます。

マイクロサービスの最も直接的な価値のある利点は、単純なコードのモジュール化によって実現できます。持っているモジュールシステム（maven、npm、nugetなど）を使用して、機能のグループをモジュールに分離できます。各モジュールは、単一の目的を果たすことができ、独自のリポジトリーに配置し、独自のDBスキーマを使用し、独自の構成を管理し、独自の機能バックログとリリーススケジュールを設定できます。それらは一体としてモノリスに配置することができます。これは非常に管理しやすいオーバーヘッドであり、いくつかの良い利点があります。より大きなオーバーヘッドは、デプロイメントを分離することから生じます。これは、それを必要とするのに十分な規模がある場合にのみ本当に価値があります。コードがすでにモジュール化されている場合は、時期が来れば移行が容易になります。

私の意見では、最初にモノリスを開発すること（またはそれ以上：アプリケーションの一部をモノリスとして開発すること）は有益です。

ドメインと問題の境界がわからない場合があります（たとえば、船の管理サイトを構築したり、船サービスと艦隊サービスが必要ですか、それとも船サービスで十分ですか？）モノリスは開発が簡単です。

さまざまなテクノロジーを組み合わせる必要がある場合はこれをやめるべきです（たとえば、既存のパーツはC＃で記述されていますが、新しい問題には機械学習が必要ですが、Pythonを使用するのが最適です）。プロジェクトやモノリスの扱いを活性化します。たとえば、誰もがこのモノリスを構築し、個別のサービスの概念を押しつぶすだけです。

MFによるこの正確な記事には2、3の質問があったと思います。

私の考えはこれです：

メンテナンスやスケーラビリティの問題があるMonolithは、それをマイクロサービスに分解することで改善されます。このようなプロジェクトは、ほとんど常に「成功」​​します。小さなセクションを分割しても測定可能な利益が得られ、幸せなときにその下に線を引くことができるからです。

ハーフモノリス+メッセージキューといくつかのワーカープロセスが「マイクロサービスアーキテクチャ」としてカウントされるかどうかは、パブをダウンさせる論争ですが、プロジェクトについて話すとき、それを間違いなくそれと呼びます。

一方、選択したアーキテクチャに関係なく新しいプロジェクトを実行すると、期待に応えられないリスクが生じるため、当然、成功率は低くなります。さらに、「ベストプラクティスマイクロサービスアーキテクチャ」全体をゼロから作成することを目的としている場合は、新しいテクノロジーとマイクロサービスのハードビットに挑戦している可能性があります。

また、MFは大きなOOPの観点から書いていることを覚えておく必要があります。彼は当然、より現代的な分散型アプローチには懐疑的です。

この時代では、大規模なビジネスソリューションにマイクロサービスの要素を組み込むことを期待し、1つのデスクトップスタイルのアプリケーションを配布しない限り、愚か者だけが1つの巨大なモノリスアプリケーションを作成することを推奨します。

私の（vast）経験では、テクノロジーの問題よりも人の問題が原因で多くのプロジェクトが失敗するのを目にしました。残念ながら、人々は失敗を好まないので、失敗の理由を誤って報告し、テクノロジーのせいにする傾向があります。

私のドメイン、ファイナンスでは、最近のほとんどの新しいプロジェクトはマイクロサービスアーキテクチャに従っています。TCO（総所有コスト）の観点から見ると、これは成功するアーキテクチャのようです。これらのプロジェクトはそれほど頻繁に失敗しているようには見えません。また、プロジェクトが失敗した場合、アプリケーションアーキテクチャを問題として挙げることはあまりありません。