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

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.

Microservices still have global concerns. Is someone actually using that endpoint or can you remove it? How will you know? Ask everyone?

How many HTTP calls are made during one user request and how long does it take? (This concern brought down one of the early microservice projects with a 10-minute page load time)

What are the race conditions? User removes billing info at the same moment as making a payment - what happens? Is the payment marked as successful but not actually billed?

It's called programming to an interface.

type ThingDoer interface { DoTheThingIDontCareHow() (result, error) }

func NewAmazingThingIMade(theThingINeedButIDontCareHowItDoesIt ThingDoer) { // You receive the superduper thing and dont care about it in any other way }

func (a *Amazing) DoSomeThing() (result, error) { return a.DoTheThingIDontCareHow() }

Nothing about "monoliths" prevents or hampers this development style. Once someone decides to do the Thing in another fashion, they are free to do so and you wouldn't have to change a thing.

All problems you experience are organizational, not technical. It's psychology we should be studying, not computer science.

Edit: In fact you introduced a network boundary which can fundamentally only complicate matters, not make them simpler.

I think you described not monolith vs microservices, but single person working on a project and making decisions vs multiple. “Everyone’s responsibility is no-one’s responsibility” works the same way if multiple people work on the same microservice.

Also a monolith may (actually, must) have internal public interfaces through which components must communicate, and those contracts are more enforceable, amenable to static checks, and much higher performance that microservices’ network interfaces.

> 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.

Then they can retrieve it from source control? Leaving dead code in the codebase because "someone else might want it" sounds like nonsense.

You do exactly the same in a monolith, functionality is broken into modules with a public API and you can switch out the implementation at any time if you want or have to.

This is complete lack of experience on the authors part. No tracing, no observability, no knowledge of distributed systems design to allow them to see what they can clearly measure. Your take is the correct one. Microservices break up the monolith so that multiple teams can work on pieces of the solution/platform without stepping on each others toes. The rest of it is documentation/discovery.