SOA(サービス指向アーキテクチャ)がさまざまなシステムに適用されるようになって長いが，同じ哲学がマイクロサービスによって，今度はシステム内部に持ち込まれようとしている – ロンドンで開催されたMicroservices Conferenceでのプレゼンテーションで，Udi Dahan氏は，マイクロサービスをこのように評した。
サービス指向アーキテクチャの権威であり，NServiceBusの開発者でもある氏は，マイクロサービスを含むテクノロジがいまだ解決していない，２つの一般的な問題を説明することからプレゼンテーションを始めた。
- 間違った要件。 氏の経験から，開発者には，自分たちの要件の解釈が誤っていることを容易に理解できないという，共通的なテーマがある。ほとんどの場合，提示されている時間的要件さえ満足できれば，利害関係者が達成を望んでいるビジネス目標はある程度解決可能なのだ。
- 悪しき習慣とずさんなコード。 規律と納期を持たないソフトウェア開発は，いかなるテクノロジでもこの問題を解決することはできない。"金で買える規律"は存在しないのだ。技術者がビジネスと向き合う姿勢は，正しい要件に対処する適切なシステムを実装する上で，極めて大きな影響力を持っている。
一般的に我々は，結合度(Coupling)が強い場合を悪，低い場合を善と見なしている。広く知られた原理ではあるが，あまりにも単純化された方法で適用されることが多い，と氏はいう。ひとつのプロセス内にある２つのコンポーネント間の論理的関係に対して，これをマイクロプロセスのような別々のプロセスに分割しても，問題は何も解決しない。結合度の面で変化はなく，単にパフォーマンスの低下をもたらすだけだ。氏が強調するのは，どのようなアーキテクチャを評価する場合でも，論理的アーキテクチャと物理的アーキテクチャを明確に区別しなければならない，という点だ。この２つを独立して評価し，結合性に変わりがないと判断したのならば，結局は何も成し遂げられていないということを認めなければならない。ここでのリスクとして氏が警告するのは，賢い開発者は創造力に富むあまり，結合性を取り除く代わりに隠そうとすることだ。結果的にこのような形になっているエンタープライズアーキテクチャは数多い。システムを直接コールする代わりに，積み重なったレイヤの中にコールが隠されているのだ。
氏の紹介した，もうひとつの重要な用語は凝縮度(Cohesion)である。高度な関連性を持ったコードの集まりが，ひとつの概念としてまとまっている場合がある。これらが同時に使用されることを前提としているのであれば，分割を試みるべきではない。同じように我々は，操作対象となるデータセットがひとつに限定されていて，他のデータセットには影響されていないことを理由に，それらを疎結合な要素であると見なす場合がある。例えばリテールのドメインにおいて，製品名やその説明，イメージなどを扱うプログラムは，製品価格や値引きルールを扱うものと結合されていない，という具合だ。まずは本当に結合したいものを探すことから始めて，周辺にある，結合の弱いものとの境界線を見つけ出す。そうすることで，それらの境界に従って，ドメインを凝縮度の高い，疎結合なマイクロサービスの集合へと分割することが可能になる。
マイクロサービスに関する議論は視野の狭いものが多い，と氏は指摘する。一度にひとつのシステムしか見ていないというのだ。解決しようとする問題に対して，より広い視野を持ち，企業全体の視点に立つことができれば，同じようなデータが多くのシステムで使用されていることに気付くはずだ。一歩引いて企業全体を眺めれば，さまざまなシステムでそれぞれの処理を担っているマイクロサービスが，実は同じコンセプトのひとつのマイクロサービスに集約できるということが分かるだろう。 その結果として，システムの境界に拘束されず，組織全体に渡って，ビジネス機能によるサービス構成が実現することになる。ここでひとつの疑問が生じる。もはや小さいとは言えなくなったこれらのサービスを，本当にマイクロサービスと呼ぶべきなのだろうか。これについて氏は，サービスの規模やコードの行数を問題にするのは止めて，ビジネス機能の提供単位として適切かどうかに注目するべきだと考えている。本当に重要なのはその点なのだ。
Skills Matterがロンドンで開催準備中のMicroservices Conferenceは，この主題による初のカンファレンスである。次回のカンファレンスの登録が受付中だ。