我々はモノリスのようなソフトウェアの大きな塊の構築を続けた末に，SOAへと移行した。それでも問題は解決せず，今はマイクロサービスに移りつつある — 先日のJavaプラットフォームによる耐脆性(anti-fragile)マイクロサービスの設計と開発を紹介する中で，Russ Miles氏はソフトウェア開発の現状をこのように説明した。
氏は岩盤，岩，小石を比較する。モノリスはあたかも岩盤のように，変更も移行も極めて難しい。SOAは岩のようで，同じように移行が難しい上，期待するほどのメリットは実際には得られていない。マイクロサービスは小石のように，自由に変更することができる。
氏が述べている耐脆性とは，システムの破棄を厭わない，ということだ。 変化を抱擁するだけではなく，それを糧としてこそ我々は成長できる。これを達成するための出発点として氏が挙げるのは，同じ目的のためにひとつの仕事を行う多数の小さなパーツ，という簡潔な構造だ。シンプルなコンポーネント，シンプルなシステム設計こそが，マイクロサービスに移行するための鍵となる。重視すべきはコンポーネントの発展であり，発展と変化を可能にするシステム構築方法なのだ。
氏が考えるマイクロサービスとは，実行時と設計時において重視すべき問題を検討してシステムの進化をサポートする上で，適切な粒度の処理が可能な，単一目的のサービスのことである。そこで重視されるのは，アーキテクチャの全体的変更による変化をサポート可能な詳細さを持って初めて適応可能な，ソフトウェア構造を構築することだ。
マイクロサービスはSOAとして正しい方法なのだろうか？ SOAで氏が問題とするのは，SOAという名称自体が非常な重荷になっているのではないか，という点だ。SOAとマイクロサービスのアーキテクチャ的な最大の違いは，システムを通じたデータの流れにある，と氏は主張する。UNIXパイプラインと同じく，重要な抽象化としてのデータパイプラインである。氏はこのパイプラインを，マイクロサービス開発を推進する理由として非常に重要なものだと考えている。レイヤ構成されるサービス階層が一般的なSOAでは，このデータフローはサービス内で編成されるため，外部から認識することはできないのだ。
マイクロサービスについて氏が耳にする大きな不満のひとつは，システムを多数の小システムに分解することで管理や監視面に問題があるのではないか，というものだ。それに対して氏は，OKやエラーを送信するようなサービスを開発してはならないとアドバイスする。そうではなくて"実行情報"，つまり問題の内容とともに対処手段も返送することが必要だ。