Comment by Alupis
1 year ago
It is not correct. This is the sentiment people who don't understand k8s often have, because of handwavy complexity blah blah blah. The predictable quote is always along the lines of "unless you're Google scale..." - which misses perhaps 80% of what microservices bring to the table.
Then they go off and build complicated monorepos that take 6 months to learn before you can effectively contribute.
All paradigms have trade offs. Engineering is about understanding those trade offs and using them where appropriate. Unfortunately too many people just jump on the "k8s is complicated" bandwagon (because it challenges most of the assumptions they've previously held in software development) and entirely write-off microservices without taking the time to learn what problems microservices solve.
People are well aware of what problems microservices solve. They are also aware of all the numerous problems they introduce, such as making debugging much more complicated, for starters.
Well, you're repeating one of the myths yourself here.
Debugging is different and some people find that harder because it's not what they are used to. That does not mean it is actually more complicated.
Debugging IS more difficult. Observability is much harder, sometimes needlessly. When you're 4 languages deep and have to enable distributed tracing across a variety of brokers/protocols (http, sqs, grpc, queue in a database) you know the lord intended you to spend your time in a more useful way.
3 replies →
It is inevitably more complicated because there are more moving pieces to coordinate. This applies to all IPC, not just in this context. To some extent you can mitigate this with tooling that tries to hide the complexity, but that usually only works for simple cases.