Service meshes as a default pattern is harmful. Ideally you would be using immutable events over a message bus as a default pattern. Just as anti corruption l

Service meshes as a default pattern is harmful. Ideally you would be using immutable events over a message bus as a default pattern. Just as anti corruption layers have a use case. So do service meshes. But service meshes they are synchronous communication, with indirection typically through a sidecar, they will have the very real costs of synchronous communication in distributed systems. IMHO the problem isn't that they are problematic when applied to the correct use case, it is that as a default pattern they inherently will cause problems with little to no benefit for systems that can use events. It is simply the same as any tight coupling, it should be avoided unless a specific use case justifies the costs. Cargo culting it in because it is superficially 'easier' will typically result in code that doesn't have the scaffolding in place to support events and is very expensive to pivot away from if you don't intentionally write your code to support looser coupling in the future. Istio, Envoy, Linkerd, etc... currently cater to the synchronous request/response communication between microservices. It doesn't matter how decetralized their implementation is, it is still essentially sync operations over a network. We have known about the costs of that decision for a long time irrespective of the implementation complexity. It is a 'sometimes' food.