モノリシックASP.NET Webアプリケーションと比較して、マイクロサービスアーキテクチャはどの時点で「それに値する」のでしょうか。
私はASP.NET WebFormsアプリケーションのメンテナーであり、いくつかのレガシーライブラリへの依存を排除し、いくつかの機能を追加し、アプリケーションの動作が実際のビジネスと適切に一致しない一部の領域を修正するために、アプリケーションの更新を検討しています現在のベストプラクティスを調べて、このような比較的小さなWebアプリケーションにとって何が意味があるのかを理解しようとしています。
私はDockerについて聞いたことがあります（以前は使用されていませんでした）。このように、私はマイクロサービスアーキテクチャとAPIゲートウェイを誰もが新しいこととして推奨しているさまざまな資料に出くわしました。もう少し学ぶと、このアプローチがこのサイズのアプリケーションに過剰であるかどうか疑問に思います。
最終的に私の質問は次のようになります。小規模な内部向けWebアプリケーションのコンテキストで、マイクロサービスアーキテクチャの追加の開発オーバーヘッドがアーキテクチャのメリットによって正当化されるかどうかを判断するためにどの基準を使用しますか？
サイズの参考として、現在のモノリシックWebFormsアプリケーションは次のもので構成されています。
- ASP.NETメンバーシップおよびロールフレームワークによって生成されたテーブルを含む、最大30のデータベーステーブル
- 〜30の.aspxページ
- 〜60人のアクティブユーザーがいます
私が見ているように、アプリケーションのサイズは実際にはマイクロサービスパターンとはあまり関係がありません。結局のところ、数個の大きなモノリスを構築するか、多数の小さなライブラリからモノリスを構築して意味のある場所に構築するか、modules/namespaces/packages/whatever-your-language-offersを使用して1つの大きなコードベースに維持することを常に選択できます。 。
マイクロサービスの使用例は、操作の複雑さを減らし、アーキテクチャの俊敏性を増やすことです。
運用上の複雑さは、コアソフトウェアがそれほど複雑ではないが、日々深刻な課題がある場合です。例としてTwitterを考えてください。標準的な基幹業務アプリケーションは、おそらくTwitterよりも難しい問題を解決しています。結局のところ、週末に簡単なマイクロブログアプリケーションを作成することができます。 Twitterを差別化するのは、非常に明確な課題につながる数十億のサービスです。マイクロサービスは、選択的なスケーリングを可能にすることで役立ちます。隔壁や回路ブレーカーなどの他のパターンと組み合わせることで、システムの一部に障害やエラーを簡単に含めることができます。他の例もありますが、これが良いアイデアになることを願っています。
アーキテクチャの俊敏性は、多くのチームが同じシステムで作業している場合に重要です。特に、すべての内容や理由が必ずしもうまく機能していない場合は特に重要です。チームが作業中にお互いのつま先を踏む可能性が低くなるように、アーティファクトによってコードベースをセグメント化する機能。さらに、モノリスではできない方法で複数の言語とフレームワークを組み合わせることができます。
もちろん、これらの利点には代償が伴い（すべての魔法には代償が伴うため）、その代償として、システムに複雑さが追加されます。問題は、その複雑さによって、運用と俊敏性の点で十分価値があるかどうかにあります。それはあなたのユースケースに非常に特有です。数年後には、クラウドインフラストラクチャ上でモノリスを実行し、次に、製品が意味のあるものを選択し、目標に応じてマイクロサービススペクトルを上下に移動する2つの間のより微妙なバランスがとれると思います。