まずは共有ライブラリとプラグインアーキテクチャから始めることだ，それらが不十分になって始めて，サービスバウンダリとマイクロサービスの導入を検討せよ - Robert C. Martin氏が先日の記事で行ったアドバイスである。これに対して異論を唱えているのがGiorgio Sironi氏だ。マイクロサービス間のインタラクションを，単一アプリケーション内のオブジェクト間のインタラクションを比較した場合の違いを強調しながら，既存のコードベースにマイクロサービスをレトロフィットすることの難しさを警告している。
Robert(アンクルBob)はマイクロサービスについて，httpとRESTを使った共通的な方法で対話する小さなスタンドアローンプログラムである，と説明する。より小さな部分のテストが可能であること，デプロイ操作が柔軟であること，データストレージなどインフラストラクチャコンポーネントがサービスごとに自由に選択できること，などがそのメリットだ。氏はこれを独立展開性(Independent Deployability)という言葉で要約し，実行時にロードされてリンクされるjarファイルやDLLのような共有ライブラリの使用では，これらメリットの大半は実現できない，と主張している。逆にマイクロサービスを使うことのデメリットのひとつとして氏が強調するのは，ソケットなどを使うサービス間のコミュニケーションが，共有ライブラリ内のオブジェクト間の直接的な対話に比較して非常に時間を要するという点だ。
氏はマイクロサービス全体に反対はしないものの，その利用には慎重を期すべきであり，プロセス間の通信コスト増大を回避する意味から，共有ライブラリで十分な場合も少なくない，と述べている。
これに対してイタリアの開発者であるGiorgioは，マイクロサービスを使用することによるメリットとして，サービスそれぞれが独立してスケール可能であること，異なる言語で記述できることを挙げる。さらに氏は，交換が必要と思われる高負荷なサーバを発見することの容易さや，マイクロサービスを新しいものに置き換えるだけでよいという，実装改善の簡潔さなども指摘している。
氏は1996年の論文を参照しながら，同期呼出しが分散システムに及ぼす可能性のある負の影響について言及する。代わりに氏が推奨するのは，マイクロサービスの統合にCommandとEventスタイルを使用して，オブジェクトの提供するインターフェースとはまったく異なる公開インターフェースを公開する方法だ。それゆえに氏は，まずプラグインアーキテクチャから始めるべきだとするRobertのアドバイスに反対する。
先日のTwitterフィードでRobertは，一部の参加者の間で始まった"モノリス対マイクロサービスの議論は，比較するものが間違っている"と主張した。
Peter Kriens氏は今年初め，自身がすでに４年前に，同一プロセス内で常時通信を行うサービスとして"OSGiマイクロサービス"を定義したと主張している。