When you work on a micro reasonable-sized service, you inevitably talk to neighboring teams and your service talks to other serives. Of course, every single developer is a bearer of unique knowledge about the system and interactions between the systems. One can't possibly know all the details and nuances of their own service, not even mentioning the whole service fleet.

Imagine yourself a scenario: you're on-call over a weekend, it's some time close to midnight, and, of course, you get paged. The situation is dire, it's not a monitoring alert. It's a customer-reported issue that's been open for weeks now, and the customer wants it fixed! The issue's been forwarded between teams without significant progress and no one understands what exactly is wrong. You've got the incident only because they think that it might be slightly related to your area of expertise. Just a bit. A teeny-tiny bit. At least, they know that the affected functionality sends requests to or receives responses from your service. Since the incident hasn't had an input from your team, they send it to you so that they could present some traction to the angry customer. You, on the other hand, don't believe that the problem originates from your service. So, it's not your problem, right?

So, you have a dotnet project that you used to develop on Windows. And now you want to see how it’ll work on Linux via WSL. Just type dotnet run and that’s it, right? Yes, but no. In case you have a Nuget feed that uses authentication (e.g. at work) you’ll need to work around it for a bit.

Service-oriented architecture is a great architectural style, but it comes at a price. The more (micro)services you have, the more remote requests you'll have to send across them to have a working system. The more requests you make, the more failures you get. But don't panic yet! Even though you can't avoid failed requests, you can deal with them.