Microservices and the Goal of Software Development:
http://www.infoq.com/news/2015/03/microservices-software
- ソフトウェア開発の目的は business impact を生み出すこと
- Business impactとは、組織内で観測可能な効果のこと（新規顧客やオペレーションコストの削減など）
- Lead time（機会の発見からその解答を生み出すまでの時間）を最小限にすること
- これを持続的に行うのが難しい
- 三種類のコード
- 最近書いて理解しているコード
- よくテストされ、文書化されているコード
- 誰も知らないコード（不明瞭な依存関係、変更の影響範囲が局所化されない）
- ソフトウェア開発最大の問題は、大部分のコードが 3 に分類されるということ
- コードはきちんと運用出来るものだけを維持するようにするべき（3のコードを排除すべき）
- North氏の提案する二つのパターン
- コードの目的（意図）を明確にすること
- ソフトウェアの半減期は短い（「半減期」とは放射性崩壊の速さを示す物理学用語）
- なので、それぞれのコードの目的を明確にして安定化に努めるべし
- 理解しやすいようにコードを分割統治すること
- コードの目的（意図）を明確にすること
- 上の二つのパターンを実現するために有効なのが「置換可能なコンポーネントによるアーキテクチャ (replaceable component architecture) 」
- APIによって意図が明確にされたコンポーネント
- コンポーネントは Alan Kay の発明したオブジェクト指向のオブジェクトのごとく、メッセージのやり取りをする小さなコンピュータのようなもの
- Microservicesは、置換可能なコンポーネントによるアーキテクチャになり得る
- 置換可能性と一貫性を追求すること
- コンポーネントの「小ささ」よりも「置換可能性」の方が重要
現場のエンジニアがMicroservicesアーキテクチャを評価するときは、どうしてもその実用性や現実性、例えばプロセス間通信の多用によるオーバーヘッドなどが問題にされがちである。しかし、そのコンセプトをつぶさに見ていくと、これは単にアーキテクチャだけの問題ではなく、ソフトウェア開発はどうあるべきかという、ある種の思想を提示していることに気がつく。
開発の現場には「エンジニアとは外から持ち込まれた問題に解を与える者だ」という強い思い込みがあることが多い。しかし、これはプログラミングに対する誤解を含んでいるだけでなく、一つのシステムを長く育てるというケースにおいては、持続可能なモデルではない。
Martin Fowler氏が「The New Methodology」の中で「ソフトウエア開発は、全てが「デザイン」である」と指摘したのはもう大分昔のことだが、この考え方が開発の現場においてどれだけ浸透しているだろうか。
ソフトウエア開発は、本質的に、問題に対する解法の実装だけでなく、問題自体の検証と再設定を含むサイクルを繰り返す作業で、プログラミングというのはそのための強力な武器である。既に設定された問題を解決するためだけにプログラミングが存在し、そしてその問題設定を開発から切り離せると考えるのは、ソフトウエア開発に対する大きな誤解である。
Microservicesで提案されているのは、一つのサービスだけでなく、それを開発する開発者（あるいはチーム）も、できるだけ完結した存在になることが望ましいということである。中央集権的な開発体制ではなく、いくつものサービスとその開発を担当する cross-functional なチームが自律的に連携して、全体として大きなシステムを実現するという、オブジェクト指向が理想としていたようなモデルである。
あまり理想主義的になり過ぎるのも良くないが、このような考え方のルーツの一つにオブジェクト指向があり、それが考え方としてはデザインパターンやアジャイル開発などにつながり、プロダクトとしてはインターネットやiPhoneなどにつながっていることを考えると、実用性や現実性はともかく、その思想の重要性に注目しておく必要はあるだろう。
ゆびてく 