モノリス(Monolith)は，その本質に対する誤解が最小限にされるどころか，逆にますます，レガシシステムと同じような侮辱的総称に使われるようになった - Robert Annett氏はこのように述べて，モノリスの特性を明らかにしようとしている。
金融サービスに携わっている氏は，マイクロサービスをベースとするアーキテクチャに向かう強いトレンドの存在を認め，モノリスとの比較をこれまで何度も議論している。しかしその一方では，モノリスの本質に対する疑問，２つのパラダイムの支持者による論争，その中で折々触れられている，モノリスで1日50回以上のデプロイに成功したと主張するETSYに対する議論に関しては，まったく異なる見解を持っている。
氏はモノリスを，アーキテクチャのスタイルあるいはパターンのひとつと捉えた上で，それを特徴づける３つの基本的なビュータイプ(viewtype)を定義する。
モジュールモノリス(Module Monolith)では，システムの全コードが単一のコードベース上にあって，ひとつのアーティファクトとしてコンパイル，デプロイされる。コード自体は凝縮性と分離性を備えた適切な構造であるかも知れないが，それでも単一のモジュールであることに違いはない。
アロケーションモノリス(Allocation Monolith)では，すべてのコードが同時にデプロイされる。コード全体が一度にコンパイルされて単一のアーティファクトになる場合と，いくつかのアーティファクトが得られる場合があるが，ひとつのバージョンがべてのノードにデプロイされて，同じバージョンが動作するという点は共通だ。
ランタイムモノリス(Runtime Monolith)は，ひとつのアプリケーションあるいはプロセスがシステムとして動作するという，一般的なシステム構築方法である。主体となる単一のコンポーネントがデプロイされるという意味で，アロケーションモノリスを連想させる部分も多いが，ひとつ異なるのは，新しいバージョンがリージョンにロールアウトされた結果，複数のバージョンが並行動作する状態になる点だ。
結論として氏は，マイクロサービスとモノリスを対比して議論する場合に注意が必要であることを強調する。氏の考えでは，直接的な比較が可能なのは，ランタイムビュータイプとその特徴を議論する場合に限られている。モジュールあるいはアロケーションモノリスを回避することは有効かも知れないが，それによって魔法のようにマイクロサービスアーキテクチャが実現する訳ではない。そのようなアーキテクチャに移行する場合に氏がアドバイスするのは，すべてのビュータイプを考慮した上で，それらの間の境界線を意識することだ。ひとつのモノリスを構築して，一連のノードに配布するべきではない。
別のブログ記事ではChris F Carroll氏が，単一のデプロイユニットはモノリスではない，と主張している。氏は先日のMicroservice Conferenceでも，Udi Dahan氏とJeppe Cramon氏がそれぞれのプレゼンテーションで提唱した4 + 1アーキテクチャビューモデルを引き合いに出しながら，論理的なビューと物理的ビューの分離の必要性を強調していた。