3月20日、海外のインフラエンジニアIan Miell氏が「Why I'm No Longer Talking to Architects About Microservices（私がマイクロサービスについてアーキテクトと話をしなくなった理由）」と題した記事を公開した。
この記事では、マイクロサービスを組織に導入するにあたっての課題と不満を述べており、海外で大きな反響を呼んでいる。
以下に、その内容を紹介する。
はじめに
筆者が参加したアーキテクチャのレビュー会議で、先日マイクロサービスの話題が持ち上がり、いつの間にか「マイクロサービスとは何か」という抽象的な議論に終始していた。
多くの場合、 マイクロサービスは手段であるはずなのに、いつのまにかそれ自体が目的に変質してしまう。
そこで筆者は、アーキテクト同士でマイクロサービスの議論を交わすのをやめるに至ったという。
筆者が感じた3つの問題
筆者はマイクロサービスをめぐる議論に対して、主に以下の3つの問題を指摘している。
- 「マイクロサービス」の定義が合意されていない
- マイクロサービスの議論が抽象的で、ビジネスゴールと結びついていない
- 組織改革なくしてマイクロサービスを導入しても意味がない
問題1：誰も「マイクロサービス」の意味で合意できていない
「マイクロサービス」とは何かという正式な定義が存在しないため、話している人によって示す対象が異なる。その結果、同じ言葉を使っていても噛み合わない議論になりがちだ。以下のように、多種多様な見解が混在している。
マイクロサービスとは◯◯である:
- コード行数が極端に少ないサービス（例：100行程度など）
- 「2枚のピザで満足できる人数」のチームが担当する単位
- 1人のプログラマだけで設計・開発・保守を完結できる単位
- 自律性を持ち、独立したプロセスとして動作するもの
- Dockerコンテナとしてパッケージ化され、Kubernetes上で動かす単位
- 独立したデータストアを持つサービス
- 独立してリプレースやアップグレードが可能な単位
- 業務ドメインを小さく切り出した「小さなコンピュータ」
これらはいずれもマイクロサービスとして正しく捉え得る要素を含んでいるが、強調する点が違うために議論がかみ合わない。筆者は「マイクロサービス」という言葉が混乱を生むのであれば、いっそ使用をやめるべきだと主張している。代わりに、デプロイを迅速化したい、システムの一部だけを拡張したい、結合度を下げたいなどの 具体的な課題や目的をまず議論すべき だというわけだ。
ついでに言うと、マイクロサービスだけでなく、IT業界には用語の使われ方が広すぎて混乱を招く事例が多いとして、以下のような例が挙げられている。
- DevOps
- もともとは開発チームと運用チームを分けるべきでないという思想だったが、いつの間にか部署名のように使われるケースが増えた。
- Agile
- ウォーターフォール型の非効率性を避けるための柔軟な開発手法を指していたが、形式的で官僚的なプロセスを指す言葉として扱われることも多くなった。
- SRE
- Googleが提唱した信頼性と自動化を重視する開発運用手法だが、組織として単に従来の運用業務をリブランディングするだけの事例が多い。
- Observability
- 制御理論の概念をソフトウェアに応用したものだが、ベンダーの商用ツールが普及するにつれ、単にモニタリングやダッシュボードを増やすだけの手段と混同されがちになった。
どの用語も最初は具体的で明確な意味を伴っていたが、商業的な利用や誤解の蓄積で定義がゆらぎ、結局「何を指しているのか分からない」という議論を招く要因になっているという指摘である。
問題2：マイクロサービスに関する議論がビジネスゴールから乖離している
「マイクロサービスの導入が組織にもたらすメリットは何か」という問いに対し、「スケーラビリティが向上する」「アジリティが高まる」といった抽象的な回答で終わってしまうことが多いという。具体的にどの部分がボトルネックなのか、なぜデプロイが遅いのかなどを検証しないまま、技術としてのマイクロサービスを採用したいだけというケースもある。
- 「スケーラビリティが向上する」と言うが、実際には何をどのようにスケールさせたいのか
- 「アジリティが高まる」と言うが、その原因はアーキテクチャなのか、プロセス面の問題なのか
- 「単独でデプロイできる」と言うが、本当にそれが必須要件なのか
- 「認知負荷が下がる」と言うが、本当にそうなのか。それとも複雑さを分散しているだけではないのか
場合によっては「最新技術に触れてみたい」や「レガシーから逃れたい」という漠然としたモチベーションだけが先行し、ビジネス上の具体的なゴールと紐づいていないことも多い。著者は 「まずはマイクロサービスありきではなく、ビジネス課題をどう解決するのかを考えるべきだ」 と強調している。
問題3：組織の変革なくしてマイクロサービスを導入しても意味がない
マイクロサービスは技術的にサービスを分割するだけでは成立しない。組織全体で対応するための体制が必要だ。たとえば以下のような要素が挙げられている。
- 機能横断的で自律的なチーム編成。サービスを一貫して管理するため、データベースや運用チームなどを一元的に依存しない体制づくり
- 決定権の分散。各サービスチームが独立してリリース・運用できるための仕組み
- 高度なDevOps文化。CI/CDや監視、インシデント管理といった運用面も含めて分散システムに対応できる成熟度
これらが不十分なままマイクロサービスだけを導入すると、技術的複雑さだけが増し、従来の承認プロセスなどのボトルネックも残り、かえって状況が悪化することにもなりかねない。実際、組織構造を変えることはソフトウェアを変えるよりはるかに難しく、大企業や既存の組織体制ではとくにハードルが高いだろう。
結論
筆者は「もうマイクロサービスについては話さない」と述べているが、マイクロサービスそのものを否定しているわけではなく、本来のビジネス課題を明確にし、技術は手段として捉えるべきなのではないか、というメッセージを投げかけている。
詳細はWhy I'm No Longer Talking to Architects About Microservicesを参照していただきたい。
