キーポイント
- マイクロサービスは複雑さの原因ではなく、むしろ治療法だ。あらゆるアプリケーションは複雑になってゆく。ある点を超えると、マイクロサービスがその複雑さを管理する助けとなるだろう。
- マイクロサービスにはコストと恩恵が伴う。もし恩恵がコストを上回らなければ、マイクロサービスをうまく使うことはできないだろう。
- モノリス対マイクロサービスというものは存在しない。実際、両者の間にはさまざまな可能性がある。もしあなたがどちらか極端に自分を縛り付けているとしたら、その中間にある多種多様なアーキテクチャを見逃していることになる。
- マイクロサービスへの旅は、私がハイブリッド モデルと好んで呼んでいる範囲のどこか中間で止めることが可能だ。この時点では、大きなサービスと小さなサービスが混在しているかもしれない。我々は両者の長所、つまりモノリスのシンプルさと利便性に、マイクロサービスの柔軟性と拡張性を組み合わせたものを活用できる。
- モノリス対マイクロサービスという議論はやめて、適切なサイズのサービスというニュアンスの議論をすべきだ。
現在進行中の戦争：モノリス対マイクロサービス
多くの意味で、マイクロサービスはゾンビ・アーキテクチャだ。死ぬことを拒む知的伝染病の別の系統だ。J2EEの暗黒時代（リモート・サーバー・ビーンズ、誰かいる？）から、WS-Deathstarのナンセンスを経て、現在はマイクロサービスとサーバーレスの形で脳みそを食いつぶしている。
-- David Heinemeier Hansson（ソース）
※訳者補足：WS-Deathstarとは、WS-から始まる多くのWS標準を「WS-*」と総称することに対するスラング。SOAPやWSDLが流行ったひと昔前の書籍等に、用語の説明を垣間見ることができる。
AWSがマイクロサービスを捨ててモノリスに戻ったという最近のブログ投稿で、モノリス対マイクロサービスの古い戦争が再燃している。
あなたの立場は？ マイクロサービス派かモノリス派か？ マイクロサービス対モノリスは、より大きなストーリーの一部に過ぎず、その区別は幻想のようなもので、人々は虚構の上で争っているのだと言ったらどうだろう。
AWSの記事は、（長年マイクロサービスの支持者であった）同社がマイクロサービスから手のひらを返し、モノリスに戻った証拠として受け止められている。
彼らのブログ記事のタイトルは、注目を集めるよう計算されたものだが、この記事はマイクロ（マイクロの定義がどうであれ）より大きなサービスを持つ分散アプリケーションでなければ、FaaS（functions as a service）から、現在の恐らくマイクロサービスアーキテクチャへの転換について書かれているように見える。
しかし私が言いたいのは、そんなことはどうでもいいということだ。これはAWSのあるひとつのチームが、最初に試したアーキテクチャが上手く機能しなくなった（時とともに）、そして別の方法を試したらよりうまく機能した、というだけのことだ。だから何だというのだ。私の今までのキャリアから見て、これは 単に優れたソフトウェアが取るべき当たり前の方法だ。
我々は誰しも、もっとも重要なこと、つまり顧客のために正しいことをする、といったことに集中したいと思っている。マイクロサービス対モノリスの議論のどちらか一方につくことは、その妨げになる。マイクロサービスが必要な時もある。モノリスが必要な時もある。（FaaSがいつか必要になるとはまだ確信していないが、先入観は持たずにいようとしている）。大抵の場合、極端ではない中間にいるほうが良い。
なぜマイクロサービスを恐れるのか？
確かに、マイクロサービスはモノリスよりも扱いが難しい。それはそのとおりだ。しかし、素晴らしく自動化されたマイクロサービス・アーキテクチャを見れば、その議論は通用しない。私がこれまで使ってきた、もっともシームレスで作業しやすいシステムのいくつかは、優れた自動化を備えたマイクロサービスだった。一方、私が手掛けたもっとも困難なプロジェクトのひとつは、自動化がほぼない巨大で古いモノリスだった。マイクロサービスではなくモノリスを選択したからといって、幸せになれるとは限らない。
マイクロサービスへの恐怖は、誇大広告への反動なのだろうか？ そう、マイクロサービスは誇大宣伝されてきた。マイクロサービスは銀の弾丸ではない。あらゆる潜在的な解決策と同じく、すべての状況に適用できるわけではない。どんなアーキテクチャであっても間違った問題に適用した場合（あるいはもっと悪いことに、経営陣によって間違ったアーキテクチャの適用を強制された場合）、そのアーキテクチャーが激しく憎くなるのはよくわかる。
マイクロサービスが、純粋にずっと困難だったかつての時代からの恐れもあるだろうか？ 10年前、マイクロサービスの開発はかなり困難だった。しかし、ツールやプラットフォームはそれ以来大きく進歩した。マイクロサービスでの作業をよりシームレスで楽しいものにする優れた自動化を作るのは、かつてないほど簡単になっている。
恐れの一部は、それが複雑だと感じるところから来ているのかもしれない。これは本当に大きな要素だと思う。人は自然と複雑さを恐れる（あるいは少なくとも避ける）。「複雑だと感じる」 というのは、複雑になるのはマイクロサービスだけではないからだ。あらゆるモノリスも同じように複雑になる（頑張ってやってみてほしい）。一方、マイクロサービスでは、複雑さは誰の目にも明らかであり、早期に対処しなければならない。拙著『Bootstrapping Microservices※』では、これを「痛みを前倒しすること」と開発プロセスにおいて呼んでおり、これにより簡単で、かつ安価に対処できる。
※訳者補足：原文にはないが、書籍の出典を追加。（段落では1.10.5）
残念ながら、現代のソフトウェア開発では複雑さから逃れることはできない。我々のアプリケーションは大規模化し、複雑化している。地味なモノリスでさえ、一人で扱える以上に複雑化する運命にある。
現代の大規模開発では、複雑さを避けることはできない。複雑さが開発プロセスを遅らせたり、我々を圧倒したりしないように、複雑さを管理するためのツールが必要なのだ。
なぜマイクロサービスは難しく見えるのか？
マイクロサービスを使うには、これくらい背伸びしなければならない
-- Martin Fowler（ソース）
マイクロサービスに限らず、分散型アプリケーションの構築には、より高い技術力が求められる。1つのサービスだけでなく、多くのサービスのフリートを管理するということは、システム管理を自動化するツールが必要だということだ。また、サービスが何をしているのかを理解しようとするだけでも、多くのことを把握しなければならない。サービスの数が増えれば増えるほど、サービス間のコミュニケーションを理解するのは指数関数的に難しくなる。
あなたが小さなチームや小さなプロジェクトだとしよう。その場合、マイクロサービスを正当化できない状況に適用していたり、分散システムの構築と運用に必要なスキルやテクノロジーへの投資を惜しんでいたりすると、マイクロサービスで良い経験をすることは期待できない。
もうひとつ考えられるペインポイントは、サービスをドメインと適切に整合させていないことだ。私は、マイクロサービス・アプリケーションをビジネス・ニーズではなく技術的なニーズに合わせいるのを見たことがある。結果として、サービスの数が増えすぎ、管理しきれないほどのシステムになってしまっていた。サービスを小さくしすぎて、不必要に複雑さとシステム管理の難しさを増大させるということがある。
アーキテクチャをドメインと正確に整合させることができなければ、モノリスかマイクロサービスかに関係なく、大きな問題を抱えることになる。しかし、こうした問題はサービスが増えれば増えるほど大きくなる。マイクロサービスは、パフォーマンスのスケーリングに適しているだけでなく、すでに抱えているどんな問題もスケールアップしてしまう。
単なるスケーリングの問題なのか？
モノリスを構築できない場合、マイクロサービスが解決策だと考える根拠は何だろうか？
-- Simon Brown（ソース）
マイクロサービスの本当の問題は、既存の問題をスケールアップしてしまうことだけなのだろうか？
悪いマイクロサービスの実装は、悪いモノリスの少なくとも X 倍は悪くなる。ここでの X は分散アプリケーションのサービス数だ。分散アプリケーションの通信経路が指数関数的に増加することを考えると、それよりもさらに悪い。
モノリスで機能するツール、テクニック、自動化、プロセス、組織を持っていないのであれば、マイクロサービスにスケールアップできると思うだろうか？ スケールアップする前に、まず身の回りの問題をきちんと処理しておく必要がある。
マイクロサービスは、パフォーマンスや開発チームのスケールだけでなく、難易度もスケールする。モノリスの構築と保守に苦労しているのであれば、マイクロサービスへのスケーリングは役に立たないだろう。
ひとつのマイクロサービス・アプリケーションはモノリスに過ぎないが、サービスの数は増加し、サービスのサイズは減少する。もしあなたがモノリスに苦しんでいて、マイクロサービスがその答えだと考えているなら、もう一度考えてみてほしい。
思うに、マイクロサービスはパフォーマンスや開発面でスケーラブルなだけでなく、難易度においてもスケーラブルだ。マイクロサービスには恩恵があるが、コスト抜きというわけではない。
マイクロサービスのコスト
マイクロサービスはタダではない。
-- Sam Newman（Building Microservicesより※）
※訳者補足：原文にはないが、書籍の出典を追加。
マイクロサービスとは本当は何なのか？ なぜアプリケーションを別々のサービスに分けるのか？
よく知られている恩恵はたくさんある。
- スケーラビリティ
- パフォーマンス
- 開発チーム
- 耐障害性
- 迅速な開発サイクルのための独立した（そしてリスクの少ない）デプロイメント
- 開発者のエンパワーメント
- 破棄容易性のための設計
- 複雑さの管理
しかし、恩恵ばかりではない。支払わなければならないコストもある。
- より高いレベルの技術スキル
- より優れた自動化、管理、オブザーバビリティシステム
- スケーラブルな困難への対処
どのようなツール、テクノロジー、アーキテクチャであれ、我々が使いたいものについては、自問自答しなければならない「恩恵がコストを上回るか？」。恩恵がコストを上回っていれば、その技術で良い経験ができるだろう。でなければ、酷い目に遭うことになる。
複雑さを管理する
マイクロサービスは、大規模で複雑なアプリケーションの継続的なデプロイを可能にする。
-- Chris Richardson(ソース)
マイクロサービスには非常に多くの恩恵があるが、マイクロサービスを使うべき本当の理由は、複雑化するアプリケーション管理を助けてくれるからだ。
そう、ここで聞いた通り、マイクロサービスは複雑さの原因などではなく、むしろ複雑さを解決するものなのだ。
すべてのアプリケーションは複雑になる。仮にモノリスを構築していたとしても、避けることはできない。しかしマイクロサービスはその複雑さを、より小さく、よりシンプルで、より管理しやすい塊に分割するツールを与えてくれる。
マイクロサービスは、複雑さをシンプルかつ分離された断片に分割することで、複雑さを管理する手助けをしてくれる。確かにモノリスでもこのようなことはできるが、設計を維持し、大きな泥の塊にならないようにするには、規律正しく積極的なチームが必要だ。
マイクロサービスであれば抽象化を行い、ソフトウェアをコンポーネント化できる。もちろん、このようなことはモノリスでもできる。しかしマイクロサービスは、独立したデプロイメントや障害隔離のような他の重要な恩恵は言うまでもなく、コンポーネント間の強固で越えがたい境界をも与えてくれる。
可能性のスペクトラム
すべてを統べるアーキテクチャパターンなどない。
-- Dr. Werner Vogels（ソース）
この記事の冒頭で質問をした。あなたはマイクロサービス派かモノリス派か？
この記事のタイトルに戻ると、それはどちらか一方のみの選択ではない。1つの大きなサービス（モノリス）から多くの小さなサービス（マイクロサービス）までの変動する規模があり、その間に多くの実行可能な選択肢がある。
単純にモノリス対マイクロサービスということではない。そこには異なる可能性のあらゆるスペクトラムがある。モノリス派かマイクロサービス派のどちらかに自分を固定してしまうと、その間にある豊富で多様なアーキテクチャを見逃してしまう。
このスペクトラム（図）の両端に人為的に自分を合わせる必要はない。その中の特定のポジションに自分を固定する必要もない。誰に何と求められようが 、正しいポジションなど存在しないのだ。選ぶ場所は、あなたのチーム、ビジネス、プロジェクト、あるいは顧客にとって適切でなければならない。可能性のあるアーキテクチャのスペクトラムの中で、自分がどこにいるべきかを決めることができるのは自分だけだ。
投資に対するリターンの減少
マイクロサービスによる恩恵は、可能性のスペクトラム（図）の右側に行くほど得られる。しかし、右へ進むにはコストと困難も伴う。マイクロサービスに移行するコストが、我々が支払っても構わないものであるという確認をする必要がある。
複雑さを管理しようとしていない場合、マイクロサービスの他の恩恵を必要としていない場合、あるいは単一サービスの自動化とテクノロジーの管理に苦労している場合は、スペクトラムの左側にあるモノリスにできるだけ近づくべきだ。マイクロサービスが必要な範囲では、スペクトラムの右側のマイクロサービスに近づくべきだ。
投資に対するリターンの減少を理由として、マイクロサービスという開発者のユートピアへ全行程を突き進む価値はないかもしれないが、道のりの一部を進むことで、高い投資リターンを得られる。
この時点で重要なのは、マイクロサービスの恩恵を受け始めるために、開発者のユートピア（と私が好んで呼んでいるもの）に到達する必要はないということだ。スペクトラムの右側へ向かう動きは、たとえ反対側まで全行程を到達しなくても、目に見える利益をもたらすだろう！
「完璧な」マイクロサービスに全行程を突き進みたくないのには、それなりの理由がある。（まず、「完璧な」の意味を決めるのは誰だろう？）右へ右へと突き進み始めれば、大きな見返りが見えてくるだろう。しかし、さらに突き進めば、「投資に対するリターン」は減っていくだろう。より小さなサービスへと突き進めば突き進むほど、コストが利益を上回ることになる。現実の世界では（厄介で複雑だ）誰もが考える完璧なマイクロサービスを実現するのは難しいし、言うまでもなく不必要だ。しかし、だからといってそちらに進むことが助けにならない、ということとは違う。
ハイブリッドモデル
マイクロサービスまで全行程を突き進む必要がないのであれば、どこで立ち止まればいいのだろうか？ その答えは、開発スピード及び能力の改善とトレードオフになり、かつ開発コストが恩恵を超過しない、「中間のどこか」にある。
私は、その「中間のどこかを両端の世界の最適解」と考えたい。そう、モノリス（または複数のモノリス）をマイクロサービスの連なりで囲むのだ（図）。このような現実的な立場を取る私は、ある種の異教徒なのだろうか？ この現実的な恩恵は、モノリスの恩恵とマイクロサービスの恩恵を混ぜ合わせることが可能ということだ。コードベースの大部分はモノリスの利便性とシンプルさが、そして必要なときに活用できるマイクロサービスの柔軟性、スケーラビリティ、その他の恩恵が、理想的な環境を作ってくれる。また、マイクロサービス化で特定の機能やタスクが恩恵を受けることが明らかになれば、いつでもモノリスから個々のマイクロサービスを段階的に掘り起こすこともできる。
ハイブリッドモデルは新しいアイデアではない。ネット上で繰り広げられる議論とは裏腹に、現実の世界はしばしばこうなっている（中間のどこか）。
David Heinemeier Hansson（モノリス賛成派）でさえ、彼が「シタデル・アーキテクチャ」と呼ぶこのアイデアを気に入っているようだ。
サイズは本当に重要なのだろうか？
「マイクロ」という接頭辞は誤解を招くかもしれない。これらは必ずしも「little（量が少ない）」という意味での「small（サイズが小さい）」ではない。サイズは実は重要ではない。
-- Ben Morris（ソース）
サービスが小さければ小さいほど、より「マイクロ」になり、使い勝手が悪くなり、より多くのサービスが必要になる。サービスのサイズを小さくし、数を増やせば、難易度は上がる。
マイクロサービスの「マイクロ」という部分に注目するのはやめたほうがいいかもしれない。そのせいで、サービスが小さくなりすぎているのだと思う。そして間違いなくマイクロサービスでひどい目に遭う。
どうしてサービスをできるだけ小さくすることに固執するようになったのか、私にはよくわからない。その意図は、ソフトウェアを分割して責任を分担できるようにすることであり、各部分は全体よりも単純であるため、システム全体の複雑さを管理しやすくなることにある。しかし、サービスを小さくしすぎると、複雑さを管理するどころか、その複雑さに振り回されてしまう危険性がある。
マイクロサービスの大きさや小ささについて、誰もが自分なりの考えを持っているようだが、現実には、マイクロサービスがあるべき「決まったサイズ」はない。「マイクロサービス警察」は違反者のためのパトロールをしていない。
だからサービスのサイズについて議論するのはやめて、代わりに「適切なサイズ」のサービスについて話し始めよう。つまりモノリスサイズであったり、スペクトラムの左端より小さいどこかであっても、状況に適したサイズであればどれでもだ。サービスの大小にかかわらず、サービスはビジネスを中心に構成され、自分たちのドメインにふさわしいものでなければならない。サイズはほとんど後付けで、重要なのは全体的な組織なのだ。
サービスをできるだけ小さくすることが重要なのではない。ある段階を超えると、サービスを小さくすることは逆効果になる。サービスを小さくすればするほど、仕事をこなすためにシステムの他の部分とコミュニケーションを取らなければならなくなる。コミュニケーションをとるほど、「ネットワーク転送」コストを支払うことになる。どのサービスがどれと会話してるかを理解するのが難しくなるのは言うまでもない。サービスのサイズと、サービスの「おしゃべり」 度（「おしゃべりという」言葉を教えてくれたDamian Maclennanに感謝）のバランスをうまくとる必要がある。
意味のあるサービスのサイズを選ぼう。あるサービスが他のサービスより大きくても構わない。サービスサイズを決めるOCD（強迫神経症）に負けないでほしい。それは、素晴らしいアーキテクチャになるはずだったものを邪魔してしまう。自分に合うものを見つけさえすれば、サイズを大きくしたり小さくしたりすることに本質的な善し悪しはない。
考えを変えることを恐れない
正直に言うと、私は以前にもマイクロサービスからモノリスへ行き、そしてまた戻ってきた。両方向だ。
-- Kelsey Hightower
プロジェクトに適しているかどうかを理解するためには、新しいことを試さなければならないこともある。だから、新しいテクノロジーを試すことを恐れてはいけない。マイクロサービスやハイブリッドモデルがうまくいくかどうか試すことを恐れてはいけない。
しかし、後になって気が変わり、それまでの決断を撤回することを恐れてはならない。うまくいかなかったことを認めるのは悪いことではない。それこそが成功をつかむために必要なことなのだ。さまざまなことを試し、さまざまに実験し、うまくいかなかったものから切り替えて前に進む。マイクロサービスが特定のプロジェクトでうまくいかなかったからといって、他のチームやプロジェクトにとって悪い選択だということにはならない。
もっと言えば、先入観は持たずにいることだ。それが、次のプロジェクトで真に輝くために必要な新しいアイデアや新しい考え方から自分を遠ざけないための最善の方法なのだ。