マイクロサービスの利点
上記までで見た構造の違いにより、マイクロサービスはモノリスの持つ多くの課題を解決します。その内容を以下の通り5つの分類（独立性、保守性、拡張性、可用性、再利用性）で整理しました。個別に見ていきましょう。
利点（1）独立性
モノリスであっても、アプリケーションは内部的にはパーツに分かれており、開発チームはそのパーツごとに構成されます。成果物や進捗の管理もその単位で行われるものの、あくまでアプリケーション全体は一枚岩となっているため、プログラムは独立しておらず依存関係があります。例えば、チームごとに並行開発している中で、あるチームが先に開発を完了しても、そのパーツのみマシンへリリースをすると、整合性がとれていないことからエラーとなってしまいます。そのため、あくまで他チームとタイミングをあわせてリリースする必要があります。
また、開発に使うプログラミング言語や製品なども共通のものを使用する必要があるため、個々のアプリケーションやチーム特性に対して最適化することはできず、あくまでアプリケーション全体に合う（最大公約数的な）ものを組織横断で選択しなければなりません。
マイクロサービスを適用していれば、モノリスと異なり環境自体が分かれているので、他チームの開発状況にかかわらずリリースすることができます。これにより、開発効率の向上につながるのはもちろんですが、ユーザーも速やかに対象機能を使うことができるようになります。
また、機能間の値の受け渡しさえルールに従えば、プログラミング言語や製品は各機能に最適なものを選択することができます。それによって、アプリケーションの特性やチームメンバーのスキルセットに合わせた柔軟な開発が可能です。
利点（2）保守性
完成後のアプリケーションに機能追加をする際、モノリスならプログラムたちが相互に呼び合うことができるため、そのつながりは複雑化しがちです。一般にはその対策として、プログラムの機能による参照範囲指定（スコープ定義など）や、デザインパターンを基にしたコーディング規約の適用で複雑さを回避するという手段もとられます。しかし、プログラムの持つ範囲指定では指定できる種類に限界があり、コーディング規約も指針でしかないため絶対的な拘束力はありません。その結果、保守を重ねるほどプログラムは複雑さを増していき、機能追加の影響が読みにくくなるため、難易度が高くなって（つまり開発工数が肥大化して）いきます。同様に、影響範囲が多いことで現行機能の保証テストも肥大化する、という課題を抱えています。
マイクロサービスにすれば、機能間の境界が明確になるため、機能追加における影響範囲は限定的で、かつ分かりやすくなります。修正の難易度は低くなり、テストも局所化できます。
利点（3）拡張性
アプリケーションの性能に課題がある場合、同じアプリケーションを複数のマシンに配置してリクエストを振り分けることで処理負荷を分散させる、またはマシン自体を高性能なものに入れ替えて性能を向上させるという対策をとることがあります。モノリスの場合、性能に課題を持つのがアプリケーションの一部機能に過ぎない場合でも、アプリケーションを丸ごと複数のマシンに配置したり、高性能マシンに載せ換えたりしなければならず、マシンという資源を効率的に使うことができませんでした。
マイクロサービスであれば、アクセスが多い特定の機能のみを複数のマシンに配置したり、即時にレスポンスを返したい機能のみ高性能マシンに載せたりという柔軟な構成が可能となります。
利点（4）可用性
一部機能の欠陥により障害が発生した場合、モノリスではアプリケーション全体が落ちてしまい、復旧まで全ての機能が使えない状態となります。
マイクロサービス化していれば、機能の切り離しが可能であるため、問題のある機能を使う処理のみ停止し、それ以外は処理を継続するという手段が取れます。これにより、障害発生時の業務影響を局所化できます。
利点（5）再利用性
ある新規アプリケーションを作る際に、過去のアプリケーションの一部機能と同等のものが必要になることがあります。例えば、生命保険に関するアプリケーションを作った後に損害保険のアプリケーションを作るとしたら、契約者管理の機能の大部分において、同等の処理が必要になる場合があるでしょう。生命保険と損害保険の商品特性は異なりますが、契約者はいずれも人間であり、氏名や住所など管理すべき情報も同じであるからです。
モノリスの場合、先に作った契約者管理機能は保険商品を管理する機能と一枚岩になっているため、その部分だけを新システムでも流用するということはできません。無理やり同じシステム内に新たな業務用の実装を追加すれば、不要な機能が入り混じってしまい、アプリケーションが複雑化することは目に見えています。そこで完全新規として作ることとし、その際に効率化を意図して先のアプリケーションのソースコードをコピー流用するというケースもよく目にしますが、これも問題の火種となるパターンです。基にしたのがモノリスであるため、不要な機能も持ってきてしまうことになるだけでなく、必要なものであっても同種の機能を複数のアプリケーション（コピー元、コピー先）に存在させてしまうことになります。これにより、バージョンが枝分かれした同種機能の二重メンテナンスを余儀なくされる事態に陥ってしまいます。
適切な機能分離を行ったマイクロサービスであれば、新しいアプリケーションを作る際に、複雑さを増すこともなく、また同種の機能を複数生み出すこともなく、そのまま利用することが可能となります。これによって開発範囲が減り、業務部門の要望にあわせて短期間で対応できるようになるため、ビジネスの俊敏性も高まります。
