ここ1年程，マイクロサービスに関する話題を数多く耳にする。 それをアーキテクチャの新たなアプローチと捉えるにせよ，SAOの単なる焼き直しと見るにせよ，このコンセプトが開発者コミュニティに嵐を起こしている事実は否定し難しい。Netflixなどによる実装例や文書の中で，その起源としてしばしば引き合いに出されるのがMartin Fowler氏のひとつの記事だ。その氏が先日，この話題を再び取り上げ，マイクロサービスを利用する上で検討すべき事を中心とした記事を書いた。
[マイクロサービスへの過大な期待がもたらす]結果のひとつとして私たちが目にするのは，開発チームがマイクロサービスを熱心に受け入れるあまり，それ自体がシステムを複雑にしている点に気付かない，という状況です。これがコストやリスクの拡大要因となって，プロジェクトが深刻なトラブルに陥ることも少なくありません。
氏は“マイクロサービス”という用語については，誇大宣伝の響きがあることは認めながらも，ここ最近普及しているアーキテクチャスタイルを表現する適当な表現だと考えている。しかしここで興味深いのが，氏がマイクロサービスについて，それをSOAの一種としては言及していない点である。これは，マイクロサービスの初期の実践者たちとは異なる見解だ。その名称は別として，さらに氏は，多くの開発者が抱く疑問に答える – 果たしてマイクロサービスアーキテクチャは，自分のシステムに適しているのだろうか？
マイクロサービスを使うかどうかの支柱となるのは，あなたの考えているシステムの複雑さです。マイクロサービスアプローチは複雑なシステムを扱うことを目的としますが，それゆえにアプローチ自体が複雑さを伴っています。マイクロサービスを使うためには，自動デプロイメントやモニタリング，障害対応，結果整合性など，分散システム導入に伴う仕事をしなくてはなりません。
氏は記事の中で，一般的なモノシリックアプローチと比較してマイクロサービスがいかに複雑かを，グラフを使って示している。この事実を基に，氏は次のことを推奨する。
モノシリックとして扱うには複雑すぎるシステムを所持しない限りは，マイクロサービスを考慮する必要さえありません。大半のソフトウェアシステムは，単一の，モノシリックアプリケーションとして構築するのが適当です。モノリス内のモジュール性に注意を払って，別々のサービスに分割しようとはしないことです。
開発者をマイクロサービス採用の方向へと押し進めそうなタイプの複雑性には，マルチテナンシや，別々に発展したりスケールアップするような複数のビジネス機能のサポートなどがある。しかし氏の見解では，マイクロサービス採用の可否を決める最大かつ唯一の事象は，モノリスが大きくなり過ぎて，修正やデプロイに支障を認めた場合だ。その一方では，InfoQが昨年レポートしたように，Simon Brown氏が興味深い観察をしている。
モノリシックなシステムを開発していて“大きな泥団子(Big Ball of Mud)”になりそうなら，ソフトウェアのアーキテクチャに十分な注意が払われているかを検討すべきです。開発中のソフトウェアの中心となる抽象構造を本当に理解しているか？ インターフェースや責務は明確か？ 明確でないとすれば，マイクロサービスアーキテクチャへの移行が有効だと，どうして言えるでしょう？ 確かに，サービスを物理的に分割することで，コードのショートカットを強制的に止めさせることはできるでしょう。しかし同じことが，モノリシック内でコンポーネントを分割しても実現できるはずです。
マイクロサービスとモノシリックシステムの関係を客観的に捉えている点は，Fowler氏と相通じるものがある。
モノリスに起因する問題の多くは，そのスタイルの本質的なものではありません。マイクロサービスが必要なのは，モノリスでは継続的デリバリが不可能だからだ，と言う声を多く耳にしますが，クッキーカッターデプロイメントで成功している企業もたくさんあります。有名なのはFacebookやEtsyの2例です。
氏はまた，システムのサイズが大きくなる程，交換部品(コンポーネント)を用意するためにマイクロサービスを検討せざるを得ない，とする理由は，事実として存在しないという点でも一致している。単一のモノリスでは十分に定義されたモジュール境界を持つことができない，とする正当な理由は存在しないのだ。しかしながら，実際には氏も，モノリスではバウンダリを違反することがあまりにも簡単にできるので，名前通りの大きな泥団子(Big Ball of Mud)になることが少なくないと考えている。そうではあるが，結論として氏は，マイクロサービスに飛びつく前に，システムのアーキテクチャや実装に関連するすべての要素について，時間を掛けて十分な検討を行ってほしいと考えている。
サイズやさまざまな複雑性に後押しされて，プロジェクトにマイクロサービスを導入すべきだという考えに至ったチームをたくさん見てきました。しかし，複雑さの問題に直面しているのでなければ，マイクロサービスの導入は高く付くために，かえって開発を相当遅らせる要因になる場合もあることを忘れてはなりません。ですから，システムを十分シンプルに保ってマイクロサービスの必要を回避できるのならば，そうしてください。