[okal]

I think that's the point. It's a set of simple services. A microservice is as simple as it gets. I imagine that orchestration can become hellish at a certain point, but every team works on a few simple microservices, rather than one complex system.

[gdy]

Maybe the services are simple but their interaction definitely isn't.

[okal]

"Definitely" is a strong word. I'd imagine that it's designed so that you don't need more than a few to interact with each in real time to fulfill a business process.

I think people's anxiety around this comes from thinking that they need to understand every single system in intimate detail, or even a significant number of them. On most days, you probably only need to understand what happens at the boundaries of the ones that your systems need to interact with. Good instrumentation means you have enough visibility into them without needing to understand the implementation details.

[Traster]

Let's put this in concrete terms, I have 1600 pieces of cardboard, each one only interacts with 4 other pieces of cardboard. In total, they come together to form a single, fully functional product which shows the full picture.

We literally call this product a puzzle.

[x3al]

But on bad days, you need to debug distributed transactions.

[imtringued]

No, there is no way around knowing the entire system and by that I don't mean the implementation but rather knowing which services exist and what their responsibility is. If you have 10x as many services as usual your work just got 10x harder.