マイクロサービスの利用は，モノシリックなアプリケーションの責務を分割して，疎結合化とデプロイの迅速化を行うひとつの方法だ。ただしそれは，唯一の方法でも，さらには最善の方法でもない – Todd Hoff氏は２つのアーキテクチャ的アプローチを比較して，このように述べている。
氏が言及するのは，今年始めにAdrian Cockcroft, Sam Newman, John Allspaw(Etsy)各氏らとTwitter上で交わした，マイクロサービスとモノシリックアプリケーションの長所と短所を比較した議論の内容である。この議論は，QCon Londonで行われたEtsyのプレゼンテーションに関してAdrianが，モノシリックアプリケーションには将来性がない，継続的でスケーラブルなデプロイメントを達成するにはマイクロサービスの使用が不可欠だという点に納得できた，と語ったことに端を発する。これに対してJohnが，選択肢の多いマイクロサービスは同時に制約も大きい，十分な理解の下でツールやパターンを用いる方が有効だ，と意見を述べた。
Toddは，150名の技術者がひとつのモノシリックアプリケーションに対して，1日に60回以上のデプロイに成功したEtsyでの例について説明している。モノシリックアプリケーションで多人数が作業するというのはアンチパターンではあるが，継続的インテグレーションやプッシュボタンデプロイメント，適切なモニタリング，基本的に常にメインブランチからのデプロイといったことを正しく実践した結果として，素晴らしいサイトが構築できた実例である，というのが氏の感想だ。
モノシリックアプリケーション問題に対するソリューションのひとつとしてのマイクロサービスへの分解は，疎結合の実現と，個別のデプロイを可能にすることを目標とする。しかしToddはこれに対して，マイクロサービスがこれらの目標達成のための最善の手段であるという点に疑問を呈すると同時に，Etsyで行ったような小さなリリースを１日に何度も繰り返す方法がその代替手段となるのではないか，と指摘している。
モノシリックアプリケーションを支持するToddが強調するのは，それが現在も実際に使用されている，という点だ。１枚の岩がそうであるように，サービスの中にも複雑性を見出すことはできる。氏はライブラリとサービスを比較して，インターフェースが安定している限り，どちらも独自のライフサイクルをもった製品として扱うことは可能だ，と説明する。インターフェースが変更されると新たなバージョンが作成されるのは，ライブラリを使ってもサービスであっても同じことだ。適切なソフトウェア技術に基づくことで，モノシリックなコードベースにも実用性がある，というのがToddの意見だ。