マイクロサービスを管理するのは、互いに通信しあい、自動的にプロビジョニングするたくさんの小さなシステムの面倒を見ることであり、インフラの自動化が極めて重要だ、とJames Lewis氏は言う。氏はマイクロサービスアーキテクチャがもたらす、増大する運用の複雑性に対処するための方法を共有する中で、このように書いている。
氏はThoughtWorksのコンサルタントであり、マイクロサービスの起源をテストや変更、管理が難しい巨大な一枚岩アプリケーションを開発してしまったことに対する反動であると説明している。つまり、スパゲッティコードが絡み付いた巨大な泥だんごに対する反動というわけだ。解決策として小さなシステムを作り、それらが互いに通信するようにしたのがマイクロサービスだ。
氏にとってマイクロサービスとは、大規模なアプリケーションの境界とビジネス機能を特定し、それに基づいて分割をして、ひとつの統合されたデータベースではなくアプリケーションデータベースにデータを格納するようにする、ということだ。重要なのはコンテキストマップの頂点から始めることだ。ビジネスのドメインを理解するためだ。氏は同僚のIan Cartwright氏に言及して次のように言う。
ビジネスとアーキテクチャは異種同形になるべきです。ビジネスパーソンはハイレベルのアーキテクチャマップを探し、ビジネスそこに反映されているかを考える必要があります。同様に技術者もビジネスを探り、アーキテクチャが反映されているかを考える必要があります。
マイクロサービスの重要な側面はサイズだ。James氏は単一責任パターン(SRP)が良い物差しになる、という。ひとつのサービスにはひとつの変更理由しかない。これによってサービスは小さくなり、概念的につかむことができる程度の大きさになる。
氏にとってマイクロサービスのコンセプトは独立して配置、スケールできるということだ。サービスは複数のインスタンスとして配置され、異なるサービスが同じサーバにホストされる場合もある。分散システムを開発し配置する場合、自動プロビジョニングへ注力するが重要だ、とJames氏は強調する。各サービスやアプリケーションは自動的にビルドされスケールされなければならない。統合は多くの複雑さを生むが、マイクロサービスを導入することで解決できる。また、氏は書籍Continuous Deliveryに言及してパイプラインを構築するパターンを紹介している。
ChefやPuppetのようなインフラ自動化ツールは自動プロビジョニングを支援してくれる。これらのツールは多くのサービスから生まれる複雑さを管理する上で中心的な役割を担う。Phoenixのインフラパターンは自動化に仕組みと使ってどうやってインフラ全体を常に再作成できるようにするかについて説明をする。例えば、スクリプトを実行してインフラをすべての依存物とともに完全にビルドし直すというような処理だ。
James氏が言及するマイクロサービスカンファレンスは11月末にロンドンで開催される。