ソフトウェアの目標は，プラスのビジネスインパクトを得るためのリードタイムを最小化し，持続することだ。その他はすべて些細なことに過ぎない – QCon Londonカンファレンスで行ったプレゼンテーションの中で，Dan North氏はこのように訴えて，プログラミングに対する論理的な理由付けと，その結果としてのマイクロサービスに適したアーキテクチャスタイルへの移行について説明した。
IT業界の思想的リーダのひとりであるNorth氏が考えるソフトウェア開発の目的とは，ビジネスインパクト(Business Impact)の創造だ – Gojko Adzic氏が著書“Impact Mapping”で一般に広めた言葉を借りて，氏はこのように説明する。ビジネスインパクトとは，新規顧客や運用コスト削減といった，組織において認知可能な効果である。ソフトウェア開発の目標は，このビジネスインパクトを達成することにある。より具体的に言えば，チャンスの発見からソリューションを作り上げるまでのリードタイムを削減することだ。これを何度か行うことは簡単だが，困難なのは持続することである。最初に挙げた，North氏のソフトウェア開発の目標に関する説明は，そのような理由からのものなのだ。
North氏はプログラムコードを３つのタイプに分類する。最近自分が作成して，熟知しているコード。全員が知っている，十分にテストとドキュメント化されたようなコード。そして３つめは，氏がファブリック(fabric，織物)と呼ぶ，誰にも分からないまま存在し，依存関係も不明で，変更すればまったく関係のない部分に影響が出そうなコードだ。ソフトウェア開発の最大かつ唯一の問題として氏が指摘するのは，この第３のタイプのコードがほとんどを占めていることだ。誰も理解できない，コストと議論の対象になるコードである。コードは安定させるか，さもなくば破棄されるべきだ，とするこのNorth氏の主張からは，コードがこの第３の状態，すなわち未知のコード化することは許されない。氏が到達した，この考え方を支持するためのいくつかのパターンが，マイクロサービスへと結び付くのだ。
最初のパターンは，不安定な原子の崩壊速度を表す物理学用語を借用した，“ソフトウェア半減期の短縮”というものだ。コードは極めて短いソフトウェア半減期を持つべきだ，とNorth氏は考える。そのためには論証の可能な，明確な目標がコードにあることが重要だ。それがあれば，時間を掛けてコードを安定させるか，あるいは破棄するか，いずれかが可能になる。コードの目的を理解すること，それが非常に重要なのだ。
氏が挙げるふたつめのパターンは，James Lewis氏の発案による“頭に馴染む”コード，というものだ。このパターンは，コードを論証する能力に関するものだ。大規模なシステムの場合，それを論証する方法のひとつは，問題を単純化する，あるいは一度に注目する部分を限定して他を無視する，などの方法で，システムをブレークダウンすることだ。同じ原則を用いれば，さまざまな規模のシステムを対象に，メソッドはどのように機能するのか，モジュールはどう動作するのか，モジュール同士はどのように通信するのか，といったことの論証が可能になる。
このような理由から氏は，“置換可能なコンポーネントアーキテクチャ”と呼ぶアーキテクチャスタイルを定義している。これは，“ソフトウェアの半減期短縮”のアイデアに加えて，“頭に馴染む”というアイデアにも，文脈的な一貫性を持ってうまく折り込まれるものだ。すべてのコンポーネントは完全に交換可能で，内部詳細を隠ぺいしたAPIでラップされ，メッセージを送り合ってコミュニケーションする。これらのコンポーネントは，メッセージを送り合う小さなコンピュータのようなものだ。まさにAlan Kay氏が30年前に定義した，オブジェクト指向(OO)プログラミングに他ならない。
置換性と一貫性という，日常的に実施すべき判断を適切に行うことができれば，マイクロサービスは，この置換可能なコンポーネントアーキテクチャとして利用できる。ここでNorth氏が問題だと考えるのは，マイクロサービスという用語だ。マイクロという言葉は小さいことを意味する印象があるが，小さいことが必ずしもよいことではなく，置換可能(replecable)の方が相応しい。