This message was deleted.

Depends... your problem to be solved might not be "mutual tls" - but rather compliance, or security?

Agree with "depends", a service mesh solves multiple problems and the best way to sell it internally is probably to determine which of the biggest pain points it might solve for your use-case? Going through a similar exercise at a new company myself, and for us the possibility of reducing network hops (and hopefully latency) plus eliminating cloud load balancing is the selling point. And that selling point also gets us mTLS

Thanks for the talk link, definitely check it out, agree with the identifying objective first. 3 objectives in my mind like said above: 1. Provide service agnostic telemetry (meaning: reducing the need for building custom observability sdks like one for springboot, one for go one for node etc). Abstracting Observability out of the services. 2. Service to service authorization again from network layer rather depending on the gateways or adding complexity in services. I dont know it makes much sense or not but thanks for the time

Service-agnostic telemetry is a tricky one, as some might argue that is an anti-pattern since it essentially gives you a black box view of your distributed traces/info. If you're purely trying to track down latency/error rates/topography-style information it's a low-friction solve, but if you want to provide a comprehensive observability solution then having insight into specific services as well as from the mesh can really help. Agree it's definitely better than having neither though!