Service Mesh Wars, Goodbye Istio
A lot of service meshes offer advanced features like traffic splitting, retries, timeouts, etc. I rarely believe these are useful or I think it’s a feature that shouldn’t be handled by a sidecar proxy. They’re often used incorrectly to try and solve a problem that should be fixed some other way.
I have experience with Istio and Linkerd, both that make large claims of supporting many protocols. I found that to be very unreliable. Istio’s support for some database protocols broke between versions. Linkerd was breaking on ampq traffic. https, on both, frequently threw strange errors. I get the impression that writing a transparent networking proxy is extremely hard. At this point, I only trust a service mesh with http traffic, which is all I want anyways, as that’s the traffic moving between my Kubernetes services.
This one is particularly bad and the main reason I think services meshes aren’t ready for everyone yet. Your application container might start before the sidecar proxy, in which case, it won’t be able to complete network requests that the sidecar proxy is configured to process.
