In my experience, almost all the problems that microservices advertise solving can also be solved with a modular monolith plus some tooling to enforce certain rules (say, one module shouldn't be able to peek into another module's internals, bypassing an agreed-upon "clean" public interface; that alone solves most spaghetti-code problems)

There are two things monoliths can't easily offer:

* Using different frameworks, languages, etc. But in my experience, it's pretty rare for a team to use many programming languages at once. Usually, it's just a few highly performance-sensitive services that need to be written in another language (say, a proxy in Rust while the rest is in Python). For that, I prefer an architecture with one main monolith plus a few high-performance satellite services. No problem there.

* More optimized scaling in certain scenarios. Say I have a module that processes files and can use all available CPU. I might want to put it in a separate container on another node so that the processing doesn't destabilize the core web server. Technically, monoliths support this too, just run the monolith in a different mode (say, behind an `--image-process` flag of sorts), and you can schedule it on another node in the same way. The only downside is that it may use more RAM than necessary for the extra binaries or scripts that won't be used

What else am I missing?

Concerns that shape my own decision to run Marginalia Search as a service based architecture rather than one blob include:

* NUMA optimization - on multi-CPU architectures, I/O and/or memory bottlenecked software takes a pretty significant performance hit if you let is run on both CPUs, and this has knock on effects that also degrade the performance of other software running on the same machine.

* Network namespaces - if you're e.g. running an internet crawler, and want to assign one host machine multiple public IP addresses, this is much easier if you use something like ipvlan.

* Stateful long running process lifecycles (e.g. crawling) that coexist with the need for live redeployments of other parts of the system.

> But in my experience, it's pretty rare for a team to use many programming languages at once

Teams sure, but your whole org? Nothing wrong with all teams using same tools and language, nothing wrong with them choosing their poison. Of course your monolith can have multiple build systems.

But I think this is beside the main point of the article anyway, and it’s the part about how microservices help create boundaries that mirror organizational boundaries.

Data isolation, separate auth/permissions/roles, Compliance, crash isolation, Resource/capacity management

There’s probably more off the top of my head. Not that I necessarily advocate for the micro in services. Just the sliding scale of macro-micro services.

These are more problems in larger companies.