「私たちは大きすぎるシステム、必要以上に大きなシステムを作っていませんか？」ThoughtWorksの主任コンサルタントであるJames Lewis氏は、GOTO Berlin Conferenceのプレゼンテーション、"Microservices - adaptive architectures and organisations"をこう始めた。総所有コストの最高90%はシステムのローンチ後に発生するという事例がある。また私たちの業界では、莫大なお金を費やして、非常に巨大で複雑なシステムを構築し、結局は失敗に終わるプロジェクト事例がたくさんある。
James氏が昔ながらのやり方でシステム構築をしている大企業で経験したのは、巨大な1つのデータベースを持つ巨大な1つのアプリケーションに、すべての機能を詰め込んでしまうことだった。このことは、個々のビジネスケイパビリティをマイクロサービスとして、独自のデータベースを持つ小さなパーツに分割するというシステム構築へと、彼を導いた。
その最初のステップはヘキサゴナルビジネスケイパビリティというアイデアで、Alistair Cockburn氏のヘキサゴナルアーキテクチャ（Hexagonal Architecture）を参照したものだ。独自のデータを持つ単一のビジネスケイパビリティあるいは機能が、1つの六角形、DDD用語で言うところのコンテキスト境界（bounded context）を構成する。これら六角形がさらに大きな六角形を構成し、最終的にシステムを形作るのだ。
次のステップは、すべてのサービスのための単一インターフェイスに関係している。システムを個別に構築したときによく見かけるのは、直接的なデータベースアクセスによるインテグレーションだ。これには、システムの個々のパーツが密結合し、ロジックとデータがシステム全体に散らばりやすく、変更の影響が予測困難になるという問題がある。James氏が選んだのは、Webがうまく利用しているインテグレーション手法を使うことだ。すなわち、HTTP、HTML、そしてハイパーメディアをベースとし、コミュニケーションにはRESTを使うという方法だ。James氏がRESTと組み合わせてうまくいった標準アプリケーションプロトコルは、AtomとAtomPubだ。
James氏は、こうした小さなサービスはみな単一責任の原則に従うべきであり、その原則はすべての抽象化レイヤー、オブジェクトからサブシステムビジネスケイパビリティ、そしてシステムにまで適用すべきだと考えている。
最終ステップとして、James氏はスケーラビリティに注目した。すべての機能を備えた単一の巨大なシステムを構築することは、システムの個々のパーツをスケールするのを困難もしくは不可能にする。もし負荷の高い部分と低い部分があっても、それらを同じ能力で実行する必要があるためだ。小さなサービスを使うことで、それらを異なるサーバで、異なるサーバ数で、デプロイできるようになる。もう1つのメリットは、個々のサービスを異なるプラットフォームで実装できることだ。多数の小さなサービスを使うときに重要なことは、プログラマブルなインフラを使うなどして、モニタリングとデプロイメントを自動化することだ。ここ数年の仮想化およびIAASプロバイダの進化がこれを可能にする。
GOTO Berlin Conference 2013は、ベルリンで初めて開催されるGOTOカンファレンスであり、400名を超える出席者と80名の講演者が参加する。