概要
原著者の許諾を得て翻訳・公開いたします。
- 英語記事: Microservices Will Mess Your Team Up
- 原文公開日: 2018/01/10
- 著者: James Thompson
「なぜAmazonはマイクロサービスに舵を切ったのか？」も参考にどうぞ。企業のトップが経営判断としてマイクロサービスを強力に推進したことが重要であると思えます。
開発チームを苦しめるマイクロサービス（翻訳）
マイクロサービスは多くのチームで人気を博しています。しかし、ソフトウェア開発のパターンは、このアーキテクチャパターンの周辺で今も流動を繰り返しています。このギャップはここ数年で相当埋められてきましたが、それでも質の低い実装を生産するチームがあまりにも多すぎます。
マイクロサービスは、しばしばモノリシック（一枚板）アプリの対極に位置づけられます。この対比は有用な反面、素朴に過ぎるとも言えます。マイクロサービスというソフトウェア設計は、モジュールやコンポーネントをベースに拡張したものであり、「境界定義（boundary definition）」というアイデアを適用することで明確な「縦割り分割（vertical segmentation）」を目指して拡張されます。
マイクロサービスについて私がこれまで目にした問題点は、境界を正しく定義するという大事な作業に時間を割くチームがほとんど見当たらないということです。ここをしくじると、アプリがモノリス化したときにメンテが困難になります。そうした境界定義を欠いたマイクロサービスシステムは、数十倍始末に負えないしろものになってしまいます。境界が定義されていないマイクロサービスのエコシステムなど、ただの分散モノリスでしかありません。よほど経験豊富なチームでなければこの現実を正しく理解できないでしょう。
コストを織り込む
独立した粒度の高いデプロイが行えるのは（マイクロサービスの）最大のメリットですが、多くのチームはそんなものを必要としていません。このメリットは、分散システムにおける複雑な運用というコストと引き換えに得られるものです。メッセージングプロトコルからイベント/メッセージチャンネル、協調動作やサービス検出に至るまで、分散システムにはさまざまな運用コストが伴います。ごくささやかなエコシステムですら、運用指向の特殊な知識やスキルが求められる複雑なツールを必要とします。
マイクロサービスの別の大きなメリットとして、モジュールの境界を強固にできるという点が挙げられます。しかし、モノリシックアプリで境界を満足に定義することもできないチームがあまりに多すぎます。マイクロサービスと同じぐらい複雑な別のアーキテクチャを使ったところで、この困難は軽減されません。マイクロサービスを採用するチームには、境界を見つけ出し、定義するアーキテクトとしてのスキルが求められます。最初にこのスキルをモノリシックアプリで蓄積する方がよほど楽なのですが、このアプローチに投資しようというチームはほとんど見かけません。
境界が定義されていないマイクロサービスのエコシステムなど、ただの分散モノリスでしかありません。
技術の多様性は、チームの取り組みを盛り上げてくれます。マイクロサービスは多様な技術を導入しやすくしてくれますが、独立したデプロイの場合と同様、そのメリットは「操作が複雑になる」というコストと引き換えに得られるものです。しかも、ガイドがなければチームの管理能力を超えた技術を導入してしまう可能性もあります。
問題を解決する
マイクロサービスは、他のアーキテクチャ的アプローチと同様に、特定の問題だけを解決するものであり、他の技術に対してオープンになっています。どんなアプローチを採用するにしても、プロジェクトやチームのニーズを把握することが重要です。多くの場合、マイクロサービスは出発点としてふさわしくありません。独立したデプロイをチームが本当に必要とし、かつサービスの明確な境界を見定めて維持するスキルがチームに蓄積されるまでは、モノリスを選ぶのがベストです。誤った理由でマイクロサービスを追求し、本当に解決したい問題を特定することもできないチームがあまりに多すぎます。
マップを作成する
どんなチームでも使える方法のひとつは、ドメイン駆動設計（DDD）から拝借した「コンテキストマップ（Context Map）」という概念に基いて作業することです。
コンテキストマップは、システム内に存在するさまざまなBounded Context（コンテキスト境界）を定義します。これは技術であり、実装からは独立しています。この手法は、システムのどこに境界が存在すべきかという洞察をチームが得るのに有用です。また、それらの境界がどのように重複しているか、どのようにやりとりを行う必要があるかを調べるのにも有用です。チームや経営陣がこうした発見を行えば、マイクロサービスに本当の価値があるかどうかを定めるのに役に立つでしょう。
ソフトウェアアーキテクチャに関連して頻繁に引用されるコンウェイの法則（Conway's Law）は、肝に銘じる価値のある法則です。しかし、組織がシステムに及ぼす影響は一方向だけではありません。チームが取り組んでいるシステムもまた、組織に影響を与えるのです。分散システムに取り組むチームには、部門の縦割りや疎結合を指向する傾向も生じます。こうした傾向を管理できる手腕がなければ、チームが縄張り意識で凝り固まってしまう可能性があります。すなわち、マイクロサービスは技術であると同時に（企業）文化でもあるのです。そうした点を考慮に入れておかなければ、マイクロサービスはチームの助けになるどころか害をもたらすかもしれません。