I draw the opposite conclusion here. In monoliths, someone else might want the code to stay in the codebase. I don't want to ask everyone about it. Everyone's responsibility is no-one's responsibility, and the code stays as is.

In a microservice, I publish an interface, and I'm free to tear up all the carpet behind it as long as it keeps doing its job as advertised. Knowing whether public routes are still in use is still a problem, so you need a minimum level of metrics or logging before you can retire an endpoint.

   Inside a monolith it's easy to answer questions like "Which dependencies are we shipping?"; or "Is this piece of code still used?” Once the code is spread across dozens of independent services, those answers become much harder to obtain.

In our software project, we have had many issues with OOM and golang panics in a goroutine killing our critical endpoint even though the fault was most times caused in the administrational endpoints. By separating the critical endpoint from our administrational ones in two separate services, we reduced the criticality of those issues and therefore also the number of hotfixes we needed.

https://en.wikipedia.org/wiki/Conway%27s_law

Genuinely useful method for abstraction, concern/dependency separation, scaling, and so forth, for teams & projects that genuinely need what they offer.

https://github.com/GoPlasmatic/Orion

Design principles: * Isolate business logic from service framework using declarative coding * Make the logic representation machine-writable so AI is a first-class author * Treat business logic as versioned data, not compiled services * Ship governance with the platform, not with each service * Invoke services in-process, not over the network * Modular monolith — export and scale a service independently when needed * Push integrations into declarative connectors, keep logic pure

For a big software company, you don't have to ship a single behemoth monolith, but you don't have have microservices so small that a team of 3 has to manage 10 services.

You can have "right size" services. I don't like to call them micro because they can be fairly big and do multiple things, as long as it makes sense to have them in a single service.