今、エンタープライズ界隈のソフトウェアエンジニアの間でマイクロサービスという言葉がにわかに盛り上がりつつあります。Lewis氏によって提案された言葉です。Fowler氏と共著で書いた「Microservices」という記事を参照してほしいのですが、ようするにひとつのアプリケーションを、Railsのような一枚岩のアーキテクチャではなく、複数の軽量なサービスを連携させたアーキテクチャでつくろうというアプローチです。マイクロサービスの特徴が九つほど上げられています。サービスによるコンポーネント化:ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。ビジネスケイパビリティに基づく組織化:役割ごとにチームが構成されるのではなく、複数の役割が混在したチームがひとつのサービスを構築する。(コンウェイの法則!)プロジェクトではなくプロダクト:コンポーネントは期限のあるプロジェクトとして開発されるではなく、継続的なプロダクトとして提供される。スマートエンドポイント、ダムパイプ:サービス間のメッセージは、HTTP経由でAPI呼び出しされるか、RabbitMQやZeroMQといった軽量メッセージングシステムによる通信で交換される。分散ガバナンス:サービスごとに言語やデータベースなどは統一されず、個別に適切なものが選択される。分散データ管理:サービスごとにデータを持ち、統合されていない。インフラストラクチャ自動化:継続的デリバリが実現され、自動テスト、自動デプロイなどが採用されている。障害設計:構成されるサービスの障害に耐性を持つように設計されている。進化的設計:各サービスごとに変更が行なわれ、漸進的に設計がされる。このような特徴が挙がっているものの、SOAとどう違うのかという疑問を抱くかもしれません。実際のところ、マイクロサービスはSOAの焼き直しにすぎないという主張もあります。SOAという用語は既に多くの場面で語られすぎていて、多義的な用語となっています。SOAと一言でいったときに、設計思想といった広い概念を指す場合もあれば、WS-*やESBの導入といった狭い概念を指す場合もあります。いった領域も含む用語となっています。マイクロサービスは新しい言葉です。その言葉が指し示そうとしている内容は、アーキテクチャというよりも、スタイルであるといった方がわかりやすいのかもしれません。私個人としては、マイクロサービスという用語は、モノリシックなアーキテクチャを採用して成長してきたウェブ企業がその問題に対応していくなかで、自然と培ってきたテクニックやスタイルに名前がついたものとしてとらえています。モノリシックなアプリケーションのコードベースが巨大化すると、まず、全体像を把握できるエンジニアがいなくなります。他のエンジニアによるデグレーションを防止するための自動テストの数が増加し、実行に多大なコストを支払わなくてはならなくなっていきます。多数のサーバにアプリケーションを配置するデプロイメントのプロセスは複雑になり、その把握が困難になってきます。いった問題を解決するために、巨大な一枚岩のアプリケーションを個々の独立したサービスへ分割していこうというのは、自然なアプローチとなります。APIといったウェブで利用されている技術を採用するというのも、ウェブ企業にとっては自然な選択です。マイクロサービスという用語は、SOAの焼き直しのように見えます。それを構成するとされている要素についても、目新しいものはありません。私は、だからこそ、マイクロサービスという用語が、自分たちの開発スタイルやアーキテクチャを自然に表現するものとして気に入っています。今後、自分たちのアーキテクチャを紹介するときには、SOAという用語を違和感を持ちながらつかうのではなく、マイクロサービスという用語を使いたいとおもいます。ソフトウェアエンジニア。大学在学中からネットワークやWeb技術にたずさわる。Web制作会社、システムインテグレータを経て、現在はインターネットサービスの開発に従事。