マイクロサービス
モノリシックアーキテクチャと比較し、下記の欠点を上げている。
共通化基盤とコンポーネント境界をどこに定めるべきかが困難 - リリースや変更するサービス単位が境界になるがビジネスやマーケットに左右される。
インターフェース変更に伴うリファクタリング - サービス境界全体では変更が難しく、参加者間でインターフェイスの変更を調整する必要があり、かつ後方互換性のレイヤーを追加する必要があり、テストがより複雑になる。
複雑化されたコンポーネント - コンポーネントがきれいに構成されていない場合、コンポーネント内からコンポーネント間の接続へ複雑さがシフトしてしまいそれがさらに波及するリスクがある。
チームスキル - スキルが高いチームに効果的な技術は、スキルの低いチームでは必ずしも機能しない。この問題が一部のマイクロサービスに混入した場合、システム全体に影響する可能性がある。
2014年当初の提唱者らは「マイクロサービスがソフトウェアアーキテクチャの将来の方向性であると確信していると主張しているわけではない」と語る。
アプローチのひとつとしては、マイクロサービスアーキテクチャから始めるべきではないということ。代わりにモノリスで始め、モジュール化したままにし、モノリスが問題になったらマイクロサービスに移行・分割していく。
そして、自動化されたプロセスにより、自動ビルドと自動リリースが実行される。
マイクロサービスは、モノリシックなアプリケーション内にある1つのレイヤー(たとえば、ウェブコントローラや、フロントエンド向けバックエンド(backend-for-frontend))ではない。むしろ、自身のみでビジネス機能を提供する、明確なインターフェイスを持った小さなピースである(サービス内部のコンポーネントとしてレイヤーアーキテクチャを実装することさえある)。戦略的な観点からは、マイクロサービスは 「ただ1つのことをして、それをうまくやる」というUnix哲学に本質的には従っているものとして考えられる。マーティン・ファウラーは、マイクロサービス・アーキテクチャには次のような性質があると述べている。
当然のものとしてモジュラー(英語版)構造を強制する。
継続的デリバリーのソフトウェア開発プロセスに向いている。アプリケーションの小さなパーツを変更しても、1つか少数のサービスのみをリビルドして再デプロイすればよい。
きめ細かい粒度(英語版)のインターフェイス(デプロイ可能なサービスからは独立したもの)、ビジネス駆動開発(たとえば、ドメイン駆動設計など)などの、いくつかの定義された原則(principles)に従う。
なお、「マイクロサービス」という用語は、2011年5月にヴェネツィア近郊のソフトウェアアーキテクトのワークショップで議論され、参加者が最近調査した共通のアーキテクチャースタイルと見なした内容を提唱者らが説明している。2012年5月、同グループが最も適切な名前として「マイクロサービス」を決定した。