[chucke]

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.

[Alupis]

So you're describing a bunch of unnecessary things, and stating they make microservices more difficult to debug?

Nobody says you need http, sqs, grpc, and queue (message broker) all in the same system. Nor does anyone say you need to use 4 languages for these things, nor does anyone say you need to only enable observability when there's issues.

Bunch of handwavy "it's complicated" nonsense basically - demonstrating yet again most people don't really understand microservices.

A microservice can be as simple as studying it's inputs and outputs and nothing more. All of which can be observed via tracing, logging or whatever you prefer, either on a sampled-basis, only on errors, or all the time.

Microservices make you rethink almost all of your software engineering assumptions - and some people are just not in the right headspace to make the jump. The biggest change is viewing/treating your codebases like cattle more than pets. Automate everything, fail quickly, stop caring about crashes, keep services as small and focused as possible, stop worrying about multiple supported releases, etc.

It is very different, but that doesn't mean it needs to be complex.

That doesn't mean microservices are the solution to every problem. It does mean, however, it's a solution to more problems than some people are willing to admit and/or take the time to understand.

[chucke]

> Nobody says you need http, sqs, grpc, and queue

I give it to you that, we're it not for microservices, I wouldn't need as much of http, sqs, etc, as well requiring making sense out of all of it via tracing/metrics/logging...

I've worked enough with microservices and heard enough managers preaching the same "cattle not pets", "small focused services", and similar, enough to know that high turnover or several rounds of layoffs, unreasonably high cloud bills and clients frustrated with high latency, often caused by several services, is the inevitable outcome.

[Tainnor]

Microservices are distributed and distributed systems are inherently more complex than non-distributed ones.[0]

> A microservice can be as simple as studying it's inputs and outputs and nothing more. All of which can be observed via tracing, logging or whatever you prefer, either on a sampled-basis, only on errors, or all the time.

In a statically-typed monolith, function calls are typed, I can jump to the declaration site with a mouse click and if I pass the wrong type, the code won't compile. That's way easier than "you can observe the inputs and outputs" (and hope that your observations generalise sufficiently). And yes, there are solutions for this (contract tests, Avro schemas, etc.), but they are inherently more complicated (maybe the most interesting idea I've seen in this space is Unison[1], but that's not gonna gain a lot of traction anytime soon, I predict).

Of course, microservices have valid use cases, but they come at a significant cost. I don't understand how one can argue that that cost doesn't exist.

[0]: https://en.m.wikipedia.org/wiki/Fallacies_of_distributed_com...

[1]: https://www.unison-lang.org/