[mbrodersen]

A colleague of mine is working on one of the worst software systems I have ever seen or heard of. It is a 20+ years old micro-services architecture. More than 50 services all interacting with each other in mysterious time dependent ways. It is almost impossible to debug or reason about. It took him most of a year to figure out how to reliably and automatically build and boot the system from scratch.

I have worked on systems with the same functionality but architectured as a single monolith + database. Maintaining that system was a walk in the park comparatively.

[steveBK123]

I think team size / responsibility is a big part of choosing how much you need to go down the micro service route as well. I've recently launched on a ~2 dev team, and leaning more and more towards monolith the longer we go.

The worst teams I have been on are the ones with multiples (~5x) as many repos & running services as we have developers.

Huge swathes of repos would go without commits, builds or releases for years. Inevitably the next time you had business requirements on that repo, something in CI/CD or environment had changed enough that you had to do a bunch of devops/infra/non-business work to get the plumbing working again to even start the task.

Even in teams where we eventually had nice central utilities & libraries with versioned dependencies, you never had the chance to do enough "catch up" releases to keep all 100 repos on some reasonably recent version of the core libraries. So the cost to activate some new observability function from your central libs was huge because you needed to make small changes on 50+ repos otherwise the observability was pointless since it had low coverage.