マイクロサービスを開発する理由の多くは，変更に対処する手段としてのアイソレーションの利用にある。サービス間でコードを共有してしまうと，サービスが互いに関連付けられ，アイソレーションのバリアが乗り越えられることになり，アイソレーションの効果と変更への対応能力は低減する - David Daweonはこのように書いて，DRY(Don't Repeat Yourself)の原則に疑問を呈している。
その名もSimplicityという会社のCEOである氏は，マイクロサービス開発の一般的な理由として，次のようなものを挙げている。
- 独立したスケーリング
- サービスの分離
- サービスのライフサイクルの分離
これらの理由はすべて，環境ないしコードベースの変更に対処するものだ，と氏は言う。サービスの分割を考える上において，変更が主要な指針となることも少なくない，というのが氏の意見だ。
一方，開発者の立場から見れば，マイクロサービス間でコードを共有する理由は決して少なくない。氏が考えるのは，次のようなものだ。
- 共有ライブラリなどによる，既存の技術的機能の活用。
- 同じクラスを使用するなどの方法による，データスキーマの共有。
- 別々のサービスから同じデータストアを使用するなど，データソースの共有。
ここで氏が強調するには，コードの共有が必然的に，そのコードを通じてサービスを結合することになる点だ。本当のソースをひとつだけ作成して，単一のサービス内でDRYの原則に従っているのであれば，内部的な結合は発生したとしても，単一の責任を持つサービスとして問題にはならない。これとは対照的に，サービスのバウンダリを越える場合には，例え同じような部分があったとしても，それぞれのコンテキストは異なっているのだから，異なるコードで実装し，異なるデータストアを使用する必要がある。いかに同じように見えようとも，サービスとサービスを結びつけるような行為には，我々は抵抗しなければならない，と氏は主張する。それがバウンダリやコンテキストを越えた結び付きを意味し，Big Ball of Mud(大きな泥団子)アーキテクチャに直結するからだ。
DRYの原則は，デザインパターンに匹敵するような，ソフトウェア開発の基本原理のひとつになったが，同時に“Don't Repeat Anything”や“Copy and Paste id bad”と曲解されているのではないか，と氏は考えている。そこでルーツに立ち戻って“The Pragmatic Programmer”を見ると，DRYの説明は次のようなものだ。
知識は，そのすべての部分が，システム内に単一で，明確で，信頼できる形で表現されなくてはなりません。
ここで重要なのは“知識”という概念であって，コピーや貼り付けではない，と氏は指摘する。この原則は特定の領域では有効ではあるが，用語がその文脈を離れて独り歩きしているのではないのだろうか，と言うのだ。マイクロサービスアーキテクチャにおいて，スキーマの共有のような高いレベルで適用された場合，DRYによってマイクロサービスが短絡されることになる。メリットは何もない，ただアーキテクチャのメンテナンスコストが残るだけなのだ。