> While small microservices are certainly simpler to reason about, I worry that this pushes complexity into the interconnections between services

100% true in retrospect.

▲

bandrami 2 hours ago | parent [-]

I've found a lot of bugs in software in my career and basically none of them were at a single spot in a codebase. They've all been where two remote spots (or even more frequently to spots in two different codebases) interact. This was true even before microservices were a thing.

	▲	kitd an hour ago \| parent \| next [-]
		There's a stat I think quoted in "Code Complete" by McConnell that says the number of bugs in a system strongly correlates with the number of coders. The conclusion is that as the # of coders goes up, the # of lines of communication between them grows exponentially, and it's the lines of (mis)communication that lead to bugs. This: 1. explains Brooks' assertion that adding coders to a late project makes it later 2. emphasises the importance in clearly defining interfaces between components, interfaces being the "paths of communication" between the coders of those components. So your assertion is well founded.
	▲	souvlakius an hour ago \| parent \| prev [-]
		I mean, microservices split the code into smaller chunks but now lots of little pieces communicate over the network and unless you are using some form of RPC, this communication channels are not typed and there's a lot more stuff that could go wrong (packets dropped, DNS not resolving). Plus you could update one microservice and not update its dependents. I think a lot of people jumped on the hype without realising that it's a trade-off