3 ms·

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

> 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 7mo ago
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.
- souvlakius 7mo ago
  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
  - mememememememo 7mo ago
    I work at a largish org (where microservices make sense but there are monoliths too) and the scary bits are unowned functionality. Leaning into a platform but being a business it isn't pure generic like say AWS it knows ahout the business. Some features are distributed across dozens of services. It is a skill hunting down who to blame for a problem. Not blame, ask for help, of course ;)
- kitd 7mo ago
  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.
- jayd16 7mo ago
  Look at Mr. Never seen an off by one error over here. I realize that putting a remote service call in between functionality adds complexity, but this is just so laughably hyperbolic.
  - bandrami 7mo ago
    I've found fencepost errors but AFAICR it was always somebody calling somebody else's code with the wrong semantics.
taeric 7mo ago
This same logic can be used to argue against the "keep all functions at 10 or so lines of code" mantra that a lot of folks try and push. Which is not to say it isn't valid.

> 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 7mo ago

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.

souvlakius 7mo ago
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
- mememememememo 7mo ago
  I work at a largish org (where microservices make sense but there are monoliths too) and the scary bits are unowned functionality. Leaning into a platform but being a business it isn't pure generic like say AWS it knows ahout the business. Some features are distributed across dozens of services. It is a skill hunting down who to blame for a problem. Not blame, ask for help, of course ;)
kitd 7mo ago
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.
jayd16 7mo ago
Look at Mr. Never seen an off by one error over here. I realize that putting a remote service call in between functionality adds complexity, but this is just so laughably hyperbolic.
- bandrami 7mo ago
  I've found fencepost errors but AFAICR it was always somebody calling somebody else's code with the wrong semantics.

taeric 7mo ago

This same logic can be used to argue against the "keep all functions at 10 or so lines of code" mantra that a lot of folks try and push. Which is not to say it isn't valid.