There shouldn't be a need to connect to another service during debugging except maybe to validate that an external service stands by its published contract. A debugger (nor printf) does not seem like the right tool for that job, though.
If you're not sure which service is causing the error, combing a log output from the two services is much easier than debugging each service separately, is my point.
1. How does this really differ from debugging both services at the same time and attaching logpoints?
2. Microservices is a team separation technique, allowing different team to live in isolation, sharing only API documentation. It's the same as regular web services, except within a single organization instead of across organizations. If you happen to have access to the code (not a guarantee!), are you really going to be able to jump into a codebase you're not familiar with to start adding print lines with more expediency than other possible approaches?
Re 2: tell that to the company I used to work with. Management heard microservices are good? Then we should have nano services. They mandated that we split things up super small, by functionality, even if there was only one team working on that.
Yes, that's right. Teams not needing to communicate, beyond API contracts, allows them to scale the service they provide. When sharing code in a monolith then you have to meetings when you want to make changes that impact other developers, and that will soon take your whole day when there are thousands of workers, leaving no time to do anything. That leaves service that cannot scale.
More simply, it takes how the macro economy scales software (and, really, most everything) and tries to apply the same processes in the micro.
