マイクロサービス～疎結合なアーキテクチャが時代に合っている

マーチン・ファウラー氏による「マイクロサービス」パターンの記事を最近よく見かける。
関連する記事をメモ。

【元ネタ】
マーチン・ファウラー氏による「マイクロサービスの前提条件」 － Publickey

クックパッドとマイクロサービス - クックパッド開発者ブログ

"Microservices"を読んだ | SOTA

マイクロサービスとSOA

マイクロサービス設計概論

akipiiさんはTwitterを使っています: "なるほど。RT @yusuke_arclamp: なんとなくですが、SOAは「いかにシステムを統合化するか」ということであり、マイクロサービスは「いかにサービスを分割して構成するか」ということかなと。同じテクニックではありますが、考える方向が逆なのが面白いところです。"

akipiiさんはTwitterを使っています: "#DevKan マイクロサービスは一昔前のSOAやEAIと何が違うのか？"

akipiiさんはTwitterを使っています: "#DevKan アーキテクトやアーキテクチャーの話はすごく良いけど、アーキテクチャーの事例をパターンで表現できないものか。超高速開発も同じ方向と思うがノウハウが体系化されてないから、使いにくい"

【1】(抜粋の引用開始)
・“Microservices” とはソフトウェアシステムの開発スタイルである

・Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法
　それぞれのサービスは自身のプロセスで動いており，軽量な機構（e.g., HTTP API）を通じて情報をやりとりする
　これらのサービスは独立して自動デプロイされる

・Monolithicシステムの構築は一般的には成功したスタイルである
　リクエストを処理するロジックは単一のプロセスで動く
　ロードバランサを配置しスケールアウトさせることもできる
　クラウドに多くのアプリケーションがデプロイされ始めるとMonolithicアプリケーションはフラストレーションになってきた

・これらのフラストレーションがMicroservicesアーキテクチャーを導きだした，
　Monolithicなアプリケーションと比較してMicroservicesは:
　独立してデプロイできる
　独立してスケールできる
　しっかりしたモジュールの境界をもつ（影響範囲の限定）
　様々なプログラミング言語を利用できる
　異なるチームで運用できる

・Microservicesは新しい考え方ではない
　少なくともその根源はUNIXのデザイン哲学に立ち戻っている
(抜粋の引用終了)

【2】モノシリックなアーキテクチャの例は、ERPが典型例だろう。
一つのシステムが、販売管理・生産管理・発注管理・原価管理・会計管理など、会社に必要なモジュールを全て持っている。
統合DBだからこそ、データを一元化できるメリットが生きる。

しかし、膨大なソースコードになり、システムの変更や保守が大変。
本来のアーキテクチャの思想に基づくモジュール構造を維持していくのも大変。
また、一つのシステムであるがゆえに、1個の機能をスケールすることはできず、システム全体でスケールしなければならない。

一方、マイクロサービスはモノシリックの対極だ。

それぞれの機能は普通、Webサービスとして独立しており、REST APIのような軽量なI/Fでデータがやり取りされる。
サービスとして独立しているから、ソース変更やデプロイの影響範囲が狭いし、気軽に頻繁にリリースできる。
また、サービスごとにスケールすることも簡単。

つまり、マイクロサービスの概念は、UNIXのデザイン哲学に似ている。
単純な処理をパイプでつなげて、大きな機能を実現する、みたいな。

【3】マイクロサービスの概念を実現した事例として、クックパッドとマイクロサービス - クックパッド開発者ブログが詳しい。

クックパッドの記事を読むと、マイクロサービスはドメイン駆動設計と相性が良いようだ。
「境界づけられたコンテキスト」「公表された言語」が適用できるらしい。

akipiiさんはTwitterを使っています: "マイクロサービスのDDDパターンとしては「境界づけられたコンテキスト」「公表された言語」が中核にあるのか。すごく分かりやすい。マイクロサービスはWebシステムに向いているか。クックパッドとマイクロサービス - クックパッド開発者ブログ http://t.co/QXdOCDdjyh"

(引用開始)
マイクロサービスの文脈でしばしば取り上げられる概念のひとつに、『ドメイン駆動設計』で紹介されているパターンである「境界づけられたコンテキスト（Bounded Context）」があります。
(中略)

境界づけられたコンテキストという概念を採用するならば、それらの間でどのように情報をコミュニケーションさせるかということも、同様に重要となります。そのためのパターンが、「公表された言語（Published Language）」です。

必要なドメインの情報をコミュニケーションにおける共通の媒体として表現できる、明確にドキュメント化された共有言語を使用し、必要に応じてその言語への変換と、その言語からの変換を行なうこと（Evans 2003）

クックパッドにおけるGarageは、ちょうどこの公表された言語の機能を持っています。どのようなアプリケーションであれ、Garageという公表された言語を備えることで、他のアプリケーションと統一的で一貫した情報のやりとりができるようになっているのです。
(引用終了)

確かに、サービスごとにモデルのコンテキストがあり、サービス同士のI/Fがコンテキストの境界になっている。
サービス同士のI/FがREST APIのような「公表された言語」で、やり取りされているわけだ。

【4】もう一つ気になるのは、マイクロサービスが、一昔前のSOAやEAIと何が違うのか、という点だ。

EAIとは 〔 エンタープライズアプリケーション統合 〕 【 Enterprise Application Integration 】 - 意味/解説/説明/定義 ： IT用語辞典

SOAとは 〔 サービス指向アーキテクチャ 〕 【 Service Oriented Architecture 】 - 意味/解説/説明/定義 ： IT用語辞典

僕の理解では、EAIはシステム関連形容のパッケージ製品、SOAはSOAPのようなXML HTTPのI/Fと理解している。
一方、マイクロサービスは、REST APIやJSONなどのように、もっと軽量なI/Fかつ現代風のI/Fと理解している。

つまり、マイクロサービスは一昔前のSOAやEAIと同じような発想から作られた概念と思うが、マイクロサービスは、アジャイル開発やDevOps、クラウドなどの最新の技術のトレンドを踏まえて、より軽量に素早く開発できることを意識したように思える。

「犠牲的アーキテクチャ」と合わせて「マイクロサービス」も、最近の技術のトレンドの一つ。
これらの概念も含めたアーキテクチャの鳥瞰図がそろそろ欲しいなあ、と思っている。