BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース マイクロサービスとソフトウェア開発の目標

マイクロサービスとソフトウェア開発の目標

ブックマーク

原文(投稿日:2015/03/08)へのリンク

ソフトウェアの目標は,プラスのビジネスインパクトを得るためのリードタイムを最小化し,持続することだ。その他はすべて些細なことに過ぎない – QCon Londonカンファレンスで行ったプレゼンテーションの中で,Dan North氏はこのように訴えて,プログラミングに対する論理的な理由付けと,その結果としてのマイクロサービスに適したアーキテクチャスタイルへの移行について説明した。

IT業界の思想的リーダのひとりであるNorth氏が考えるソフトウェア開発の目的とは,ビジネスインパクト(Business Impact)の創造だ – Gojko Adzic氏が著書“Impact Mapping”で一般に広めた言葉を借りて,氏はこのように説明する。ビジネスインパクトとは,新規顧客や運用コスト削減といった,組織において認知可能な効果である。ソフトウェア開発の目標は,このビジネスインパクトを達成することにある。より具体的に言えば,チャンスの発見からソリューションを作り上げるまでのリードタイムを削減することだ。これを何度か行うことは簡単だが,困難なのは持続することである。最初に挙げた,North氏のソフトウェア開発の目標に関する説明は,そのような理由からのものなのだ。

North氏はプログラムコードを3つのタイプに分類する。最近自分が作成して,熟知しているコード。全員が知っている,十分にテストとドキュメント化されたようなコード。そして3つめは,氏がファブリック(fabric,織物)と呼ぶ,誰にも分からないまま存在し,依存関係も不明で,変更すればまったく関係のない部分に影響が出そうなコードだ。ソフトウェア開発の最大かつ唯一の問題として氏が指摘するのは,この第3のタイプのコードがほとんどを占めていることだ。誰も理解できない,コストと議論の対象になるコードである。コードは安定させるか,さもなくば破棄されるべきだ,とするこのNorth氏の主張からは,コードがこの第3の状態,すなわち未知のコード化することは許されない。氏が到達した,この考え方を支持するためのいくつかのパターンが,マイクロサービスへと結び付くのだ。

最初のパターンは,不安定な原子の崩壊速度を表す物理学用語を借用した,“ソフトウェア半減期の短縮”というものだ。コードは極めて短いソフトウェア半減期を持つべきだ,とNorth氏は考える。そのためには論証の可能な,明確な目標がコードにあることが重要だ。それがあれば,時間を掛けてコードを安定させるか,あるいは破棄するか,いずれかが可能になる。コードの目的を理解すること,それが非常に重要なのだ。

氏が挙げるふたつめのパターンは,James Lewis氏の発案による“頭に馴染む”コード,というものだ。このパターンは,コードを論証する能力に関するものだ。大規模なシステムの場合,それを論証する方法のひとつは,問題を単純化する,あるいは一度に注目する部分を限定して他を無視する,などの方法で,システムをブレークダウンすることだ。同じ原則を用いれば,さまざまな規模のシステムを対象に,メソッドはどのように機能するのか,モジュールはどう動作するのか,モジュール同士はどのように通信するのか,といったことの論証が可能になる。

このような理由から氏は,“置換可能なコンポーネントアーキテクチャ”と呼ぶアーキテクチャスタイルを定義している。これは,“ソフトウェアの半減期短縮”のアイデアに加えて,“頭に馴染む”というアイデアにも,文脈的な一貫性を持ってうまく折り込まれるものだ。すべてのコンポーネントは完全に交換可能で,内部詳細を隠ぺいしたAPIでラップされ,メッセージを送り合ってコミュニケーションする。これらのコンポーネントは,メッセージを送り合う小さなコンピュータのようなものだ。まさにAlan Kay氏が30年前に定義した,オブジェクト指向(OO)プログラミングに他ならない。

置換性と一貫性という,日常的に実施すべき判断を適切に行うことができれば,マイクロサービスは,この置換可能なコンポーネントアーキテクチャとして利用できる。ここでNorth氏が問題だと考えるのは,マイクロサービスという用語だ。マイクロという言葉は小さいことを意味する印象があるが,小さいことが必ずしもよいことではなく,置換可能(replecable)の方が相応しい。

この記事に星をつける

おすすめ度
スタイル

特集コンテンツ一覧

BT