モノリスからマイクロサービスへの動きに賛同しつつも、ビジネスステークホルダーが関心を持っているのはコストを削減することだ。マイクロサービスアーキテクチャへの移行は収益を増やしたり守るものではなく、スケールも分散もビジネスを納得させる良い理由にはならない。今年開かれたMicroservices Conference in Londonでのプレゼンで、モノリスからマイクロサービスに移行する指針をIan Cooper氏が説明した。システムが小さくなって複雑さが減ることで、開発者の生産性が高まり、コスト削減につながる可能性がある。
ロンドン.NETユーザーグループの創設者であるCooper氏によると、マイクロサービスとともにビジネス遂行能力について言及されることが多いが、その概念を明確に定義している人はほとんどいないという。彼にとってのビジネス遂行能力は、本質的に価値という形でビジネスが顧客に提供する機能のことだ。一例は保険を売っている保険会社だ。ビジネス遂行能力はかなり安定しているが、かなりハイレベルでもある。より具体的にするため、Cooper氏はそれらを境界づけられたコンテキスト（Bounded Context）（DDDの概念）に変換する。
モノリスには境界づけられたコンテキストが複数存在しているが、それらはドメインオブジェクトやデータベーススキーマといったリソースを共有している。そのため、あらゆるパーツ間に依存関係が生まれ、ひとつが変わると他のパーツに連鎖反応が起こる恐れがある。つまり、すべてをまとめて構築・デプロイしなくてはならないということだ。必要なものをすべてマイクロサービス環境に移行するということは、別の境界づけられたコンテキストに分割するということだ。これは直感的ではあるが、簡単な操作ではないとCooper氏はいう。
Cooper氏が説明するモノリスからマイクロサービスへのアーキテクチャ移行のアプローチのひとつが、完全な書き直しだ。だが彼にとって、これはアジャイルからウォーターフォールへの移行でもある。通常、置き換えるには機能的に完全である必要があり、既存のシステムと同じになるまでは納品できないためだ。結局のところ、学習としての長期のフィードバックなしに、暗闇を進むことになる。こうしたプロジェクトはずっとビジネス価値を届けることができず、終了してしまうことが多い。
代わりにCooper氏がすすめているのは、ビジネスにとって最も価値のある機能を見つけることだ。すなわち、市場で差異化を生み出す機能や、必要不可欠な機能であり、おそらく急速に変化するものでもある。彼はひとつずつ新しいコードで置き換える。コンテキストに含まれる古いコードがすべて死に絶えて削除されるまで、境界づけられたコンテキストにある機能を新しいものに置き換えていく。必要な機能をすべて実現した時点で、最終的に置き換えることができる。このアプローチで彼が利点だと思っているのは、プロジェクトのアジャイルさを保ち、インクリメンタルなリアーキテクチャとすばやくこまめな納品によってリスクを管理できるところだ。
来年のMicroservices Conference in Londonは2016年11月7、8日に予定されている。