That's an argument for components with well-defined contracts on their interfaces, but making them microservices just complicates debugging for the model.
It's also unclear whether tight coupling is actually a problem when you can refactor this fast.
Whether you call it modularization, good design, SOLID principles, or micro services, etc. It all boils down to the same thing. I usually dumb it down to two easy to understeand metrics: cohesiveness and coupling. Something with high cohesiveness and low coupling tends to be small and easy to reason about.
Things that are small, can be easily replaced, fixed, changed, etc. with relatively low risk. Even if you have a monolith, you probably want to impose some structure on it. Whenever you get tight coupling and low cohesiveness in a system, it can become a problem spot.
Easy reasoning here directly translates into low token cost when reasoning. That's why it's beneficial to keep things that way also with LLMs. Bad design always had a cost. But with LLMs you can put a dollar cost on it.
My attitude with micro services is that it's a lot of heavy handed isolation where cheaper mechanisms could achieve much of the same effects. You can put things in a separate git repository and force all communication over the network. Or you can put code in different package and guard internal package cohesiveness and coupling a bit and use well defined interfaces to call a functions through. Same net result from a design point of view but one is a bit cheaper to call and whole lot less hassle and overhead. IMHO people do micro-services mostly for the wrong reasons: organizational convenience vs. actual benefits in terms of minimizing resource usage and optimizing for that.
> Or you can put code in different package and guard internal package cohesiveness and coupling a bit and use well defined interfaces to call a functions through.
While I do think actual microservices are over-kill. I don't think I've seen code anywhere that survives multiple years where somebody doesn't use internal state of another package. Like if you don't force people to use a hard barrier (i.e. HTTP) then there's going to be workarounds.
The problem with the latter has always been the same. It requires careful review to ensure that system boundaries aren't being crossed. It's very obvious if your repo sounds to access to a new database. Less so if it imports a function directly from an inappropriate package.
No, I think you’re not reading it literally enough. “Microservices” generally does mean separate HTTP (or at least RPC) servers. Near the beginning, the article says:
A microservice has a very well-defined surface area. Everything that flows into the service (requests) and out (responses, webhooks)
Are you purposely misreading the comment? Where did it say that http was the only form of communication (or even the best) between microservices? Where did it imply there weren't other methods?
> While HTTP can be considered as a transport layer for RPCs between microservices, it seems to me to be a very inefficient and bug-prone solution.
This is so irrelevant to the point being made it's nuts.
Why arbitrarily invent new meanings (for microservices) and new words (microlibraries) when there are already many adequate ways to describe modular, componentized architecures?
A totally valid and important point but it has been diluted by talking about microservices rather than importance of modular architectures for agent-based coding.
It's also unclear whether tight coupling is actually a problem when you can refactor this fast.