"Big Ball of Mud(大きな泥だんご)"には長い歴史がある。我々も2010年に取り上げたそのコンセプトについては，こちらのサイトにきれいに要約されている。
A BIG BALL OF MUDとは，無計画な構成でまとまりがなく，テープとワイヤでずさんに括り上げた，スパゲッティコードのジャングルのことです。誰もが目にしたことがあるはずです。このようなシステムには例外なく，無秩序な拡張と場当たり的な修正の繰り返しが見られます。システム内の遠く離れた要素の間で，好き勝手に情報が共有されます。重要な情報の大部分がグローバルであったり，コピーされていたりすることも珍しくありません。システムの全体構成が十分に定義されていないか，定義されていたとしても原形を留めないほど失われていたりします。アーキテクチャ的な感性を少しでも持ったプログラマならば，このような泥沼は避けたいと思うはずです。このようなシステムでの作業に満足しているのは，アーキテクチャに無関心で，そしておそらく，崩れ始めた堤防の穴を埋めるような毎日の作業に埋没している人たちだけでしょう。
マイクロサービスのコンセプトについての議論と利用が急速に高まっていく中で，マイクロサービスやSOAなどに関するアーキテクチャ論議の対象が"Ball of Mud"に移るまでには，長くは掛からないと予想された。Gene Hughson氏とSimon Brown氏は先日，このテーマで別々に記事を書いた。Simonの記事は，この業界においては従来的なモノシリックアーキテクチャによる開発が主流であり，それらは容易に"Balls of Mud"化する，という議論から始まっている。
もう一方には，ひとつの配備可能ユニット内にすべてをバンドルした，伝統的なモノリシックシステムがあります。おそらく業界のほとんどがこれでしょう。警告すべき対象ではあっても，モノリシックシステムは開発が速く，展開するのも容易です。ただしそのアジリティは限定的なもので，簡単な変更であっても全面的な再展開が必要になります。
議論のもう一端をなすのは，サービス指向アーキテクチャだ。これについては何年も取り上げているので，現在では読者にも馴染み深いものだろう。Simonによると，このアプローチは，
[...] 極めて多くの柔軟性と機能を提供してくれます。特にサービスが非同期メッセージを通じて分離されている場合には，それぞれのサービスを別々に開発，テスト，展開，スケールアップ，アップグレード，再開発することが可能になります。その一方で，モノリシックシステムに比較して動作部分の数が多いことから，複雑性が増加するという欠点もあります。
その上で氏は，マイクロサービスは妥協点だという見解を示す。
明示的かつ明確に定義されたインターフェースと責務を備えたインプロセスコンポーネントを使って，モノリシックシステムを開発することは可能です。このような旧式のコンポーネントベース設計は凝縮性が高く，結合性が低いと言われるにも関わらず，話題にするにはいつも，ある種のためらいを覚えるのです。
そして氏は，Karmaが先日投稿した，同社がマイクロサービスを使ったアーキテクチャに乗り換えた理由に関する記事を取り上げるとともに，我々の以前の記事にも言及している。元になったKarmaの記事では，古いモノリシックアプローチではすべてが"絡み合って"いた，と述べられている。同社がアーキテクト変更を考えた理由のひとつがこれだった。しかしながら氏は，それがアーキテクチャ変更に十分な理由とは考えてはいない。そもそもの問題である絡み合いの原因を解決する上で，マイクロサービスではおそらく効果がないだろう，というのだ。
モノリシックなシステムを開発中で，それが"Big Ball of Mud"になりそうならば，ソフトウェアアーキテクチャに十分な注意を払っているかを検討すべきです。開発中のソフトウェアにおいて，中心となる抽象構造を本当に理解しているか？ インターフェースや責務は明確か？ もし明確でないなら，マイクロサービスアーキテクチャへの移行が有効だと，どうして言えるのでしょう？ 確かに，サービスを物理的に分割することで，ショートカットの利用を強制的に止めさせることはできるでしょう。しかし同じような分割は，モノリシック内でコンポーネントを分割することでも実現できるはずです。
Geneはこれに同意しながらも，わずかに異なるアナロジを使用して，次のような主張をする。
この原理を用いて家を建てようとする人は多分，最高の建築材料と備品を購入しようとするのでしょう。そして最大限の配慮をしながら，それぞれの部屋を作り，仕上げるのです。ですが，バスルームの入り口が台所やキッチンに向けて開かれているようなデザインには，疑問を感じる人もいるでしょう。ソフトウェアやソリューション，さらには企業ITアーキテクチャは，システム中のシステムとして存在しています。システムコンポーネントの出来栄えは極めて重要ではありますが，それらのコンポーネントが含まれる，より大きなエコシステムの状態を無視することはできません。
Simonは，アーキテクチャアプローチの面についてさまざまなグループと議論を重ねるうちに，モノリシックシステムを開発するグループがコンポーネントベース設計の検討を望んでいないことに気が付いた。氏は，自身がかつてワークショップを実施した開発チームが，どのようなソフトウェアシステム図を作成しようとしたかについて詳説する。
当初のシステム図は，厳密な階層化アーキテクチャ(プレゼンテーション，ビジネスサービス，データアクセス)でした。すべての矢印は下を向いていて，各レイヤは隣接するレイヤを直接コールするだけでした。ですが，コードはそれとは全然違ってきて，最終的なシステム図は，それほど注意して見られることもなくなりました。そこで私たちは，コンポーネントによるパッケージ化アプローチを導入することによって，これらの問題がいくらか解決できないか検討しました。しかしその答は，"うーん，でも階層化を使って開発したいんだよね"，というものだったのです。
氏は次のように結論する – 優れた構造(優れたアーキテクチャ)のモノリシックシステムの開発において問題を抱えているチームが，マイクロサービスの適用や優れた設計に成功できるものなのだろうか？ その上で氏は，今年初めにQCon NYでパネルセッションのホストを務め，それを記事に書いたMichael Feathers氏に同意する。その記事の中で氏は，次のように述べている。"各マイクロサービスの実装には，それぞれある程度のオーバーヘッドがあります。マイクロサービスがクラスを書くように簡単になれば，さらなるトラブル – スケールの違う大きさのモノリスを作り出すための，フリーハンドを持つことになります。"氏の言うように，私たちが憂慮すべきなのは分散型Balls of Moudなのだ。
Simonの意見は読者の琴線に触れたらしく，記事に対するコメントは概ね氏への同意を示している。例えばRalf Westphal氏は，
[マイクロサービスは]別タイプのコンテナに過ぎません。コンポーネントやライブラリ，クラス，関数といった"低レベル"のコンテナを使ったソフトウェア構成に苦労しているのであれば，マイクロサービスから多くのメリットを得ることに期待はできません。現時点でモノリスが存在せず，コンポーネントを使用した経験もなければ，マイクロサービスは事態をさらに悪化させるだけでしょう。
Pieter H氏もまた，
そう，分散の話題を持ち出したのなら，ネットワーク遅延やフォールトトレランス，メッセージの直列化，低信頼性ネットワーク，非同期性，バージョン管理，アプリケーション層での負荷の変化，その他諸々の問題に対処しなければなりません。インフラストラクチャの活用が必要ですね。あるいはNetFlixのOSSのように，自分自身でコーディングしなければなりません。モノリシックな方法が面白くない大きな理由のひとつがこれではないかと，私は思っています。現時点で最高レベルの技術が必要ですが，どの企業でも手に入れられるというものではありません。
Michael Groves氏はマイクロサービスとCORBAを比較して，興味深い疑問を提起している。
90年代にCORBAシステムを開発していた頃，今のマイクロサービスで話題となっているのと同じようなメリットがたくさん，話題に挙がっていました。当時，Martin Fowler氏が"オブジェクトは分散するべきではない"と宣言していました。遅延が主な理由ですが，それでもその頃は，分散オブジェクトがクールに思えたのです。分散マイクロサービスがよくて，分散オブジェクトが望ましくないのはなぜでしょう？
最後にKevin Seal氏が，マイクロサービスは自然な開発手法であって，既存アプローチの単なる名称変更ではない，という意見を述べている。
マイクロサービスを選択する場合，少なくともチームがそれを選択したのだという認識が重要だと思います。それだけでも，プロジェクトがデファクトのモノリシック設計から転向するための十分な理由になります。ですから，チームが自分たちのやっていることについて話をできるように，"トレンディ"な話題を持っていることは重要だと思いますね。
マイクロサービスが"Big Ball of Mud"から決別するための優れたアプローチとなるのか，結局は同じ道を歩むのか(マイクロなのに？)は，時が経てば分かることだろう。