3月16日、「ガートナー エンタプライズ・アプリケーション戦略＆アプリケーション・アーキテクチャ サミット2017」のセッションの1つとして、ガートナーのリサーチ部門でリサーチディレクターを務める飯島公彦氏が登壇。「マイクロサービス：適用すべきか否か、それが問題だ」と題して講演した。
ガートナー リサーチ部門 リサーチディレクター 飯島公彦氏
飯島氏はマイクロサービスについて「単独で展開できる疎結合型のアプリケーションコンポーネント。SOA（サービス指向アーキテクチャ）やドメイン駆動設計（DDD）の組み合わせを基礎とする」と端的に説明。マイクロサービスが望まれる背景について「デジタルビジネスの実現にはアジリティ（俊敏性）が必要」とした。
マイクロサービスとは、「開発の俊敏性、デプロイの柔軟性、精緻な拡張性の3つを実現することを目的に、大きくてモノリシックなアプリケーションを、独立した小さい塊へと分割する考え方」（飯島氏）のこと。依存性を減らして取り払った結果として、小さい単機能のコンポーネントになる。
例えば、ホテルの部屋を予約するという処理の場合、予約を受け付ける機能や、ホテルの空き状況を調べる機能、ポイントを調べる機能、などがスコープとして独立している。これらをマイクロサービスとして動作させることができる。
マイクロサービスのメリットの1つは、他のモジュールに対して影響を受けたり与えたりすることなく、変更やデリバリが可能になること。目的に合った開発言語と実行環境をデプロイ単位に選択できることや、必要とするシステムリソースが少なく、負荷の増減に合わせてスケールイン／アウトが迅速にできることもメリットだ。
多くのマイクロサービスは「Web API」の形態で公開される。マイクロサービスが駆動するタイミングと方法については、イベントドリブンで自律的に駆動するやり方もあれば、外部のオーケストレーションソフトからバッチ処理の一部として呼び出されるやり方もある。
飯島氏は、ロジックとデータの持ち方の違いに応じて、マイクロサービスの実装のパターンをいくつか挙げた。基本パターンは、マイクロサービス内にデータを持たず、外部からデータを入力して結果を返すというものだ。一方、ポイント計算サービスなどのように、マイクロサービス内にデータを持ったほうがいいものもある。
需要に合わせてマイクロサービスを開発し、継続的に改善せよ
講演の中盤では、マイクロサービスを適用するに当たって留意すべき事柄について解説した。基本は、依存性を減らすことを考える必要がある。
（1）として、まずはデマンド（需要）を考えることが大切という。「APIは商品であり、市場が求めるものを提供すべき」（飯島氏）。アウトサイドインの発想が大切だとした。
「APIを利用するのは誰か」を先に考えることによって、マイクロサービスに求められる拡張性やスピードが決まる。「今持っているものを公開する、というプロダクトアウトの発想ではだめ」（飯島氏）
（2）として、プロセスを考えることが大切になる。「継続的なデリバリを目指すべきだ。市場からのフィードバックやログ分析を、アジャイルなやり方でマイクロサービスに反映する」（飯島氏）
APIのライフサイクルとサービス実装サイクルを分離することも大切なことという。「APIのライフサイクルは長く、あまり頻繁には変更しない。使う側に影響があるようなAPIの変更は極力減らす。作り手側の都合でAPIをコロコロ変えてはいけない」（飯島氏）
（3）として、マイクロサービスの稼働環境は、クラウドベンダーのメニューを利用するのが現実的とした。マイクロサービスを実現するためのソフトウェアのアウターアーキテクチャが複雑だからだ。
例えば、マイクロサービス自身の実行環境だけでなく、サービス間の通信やサービスの発見、非同期メッセージング、外部とのやりとり、自動化、性能や可用性の監視、などの仕組みで構成する。
（4）として、開発チームは、フルスタックのスキルを備えた小さなチームが望ましい、とした。「設計からデプロイまでを1人で担当する」（飯島氏）。チームは機能ごとに分かれており、機能同士はAPIで連携する。このため、チーム間のコミュニケーションを密にする必要がある。
