Service mesh solutions like Istio and Linkerd are gaining a lot of traction in the industry. However, it seems to me like they are predicated on what I always though was a microservices antipattern i.e. a synchronous chain of microservices calling each other (as opposed to the prescribed "right way" i.e. all inter-service communication is asynchronous through some sort of messaging). I am hesitant to outright dismiss them looking at the hype and adoption. What am I missing here, are they just helping people make their mistakes more easily?
Because every system that needs to return a response within N ms (which is pretty much every app, service, API call, etc) ends up being implemented with synchronous calls, with messaging only used for truly offline bits. There's a good writeup of why here: <a href="https://programmingisterrible.com/post/162346490883/how-do-you-cut-a-monolith-in-half" rel="nofollow">https://programmingisterrible.com/post/162346490883/how-do-y...</a> , with this great quote: "In practice, a message broker is a service that transforms network errors and machine failures into filled disks".<p>(I used to work at Twitter, which went through this same transformation, but if you watch tech talks from pretty much any other modern company that it building a big distributed system, you'll see the same pattern.)
Most of the ideas of the service mesh came from Netflix. You should watch the orignal netflix lectures.<p>You are confusing the enterprise service bus architecture and micro service architecture.<p>Async architecture is not always the right answer. If you need it, than the recommended architecture is to use a center event log (i.e. kafka) and feed all the services from it.