Microservicesと組織構造とプロセス
今日の某勉強会でMicroservicesの話があったので思ったことを書いてみる。
Conwayの法則で知られるようにアーキテクチャは組織構造を反映する。アプリ、DB、サーバなどのレイヤ単位に組織を分割すると、各レイヤは互いに深く依存しているので、変更に必要なコミュニケーションコストが増大する。そのような環境では、システムの振る舞いを少し変更するだけでもチーム間の調整と合意が必要になる。チームが独立して作業を進めることは難しくなり、スケーラビリティは悪化する。結果として、変更コストが高く、硬直したアーキテクチャが生み出される。また、最初に正しい計画を立てて各チームの足並みを揃えるというプロセスが必要になる。
一方で、巨大なシステムを適切な大きさのサービスに分割して、各チームに割り当てるやり方も考えられる。サービスはそれぞれが単一の役割を担うように粒度を保つことで、独立性を確保する。これによって、サービスに閉じた小さな変更はチームが独立して行えるようになり、スケーラビリティが向上する。最初に立てた計画を変更して、目標を補正することも容易になる。
すべてのサービスを同一のフレームワークや共通機能、データベースなどの上に構築する必要はない。サービス間で構成要素を共有すると独立性が低くなり、チームが独立して作業を進めることが難しくなる。
各チームは独立して作業を進めるが、サービスが互いにデータをやり取りするためのインタフェースは調整する必要がある。したがって、いくつものチームが互いに協調して作業を進めるためのプロセスが必要になる。ここで、複数のScrumチームが存在する前提とするとScrum of Scrumが生きてくる。Scrum of ScrumはFeature単位でチームを分割する前提であるが、Microservicesのようにサービス単位でチームを分割する方法でも有効ではないかと考えられる。ただし、サービスの粒度が大きい場合はScrumチームをさらに分割する必要があるだろう。
ゆるふわな話でツッコミどころが多い気がするので、偉い人ぜひ教えてください。
