I'm testing Istio at the moment and I feel those comments to be very inaccurate:<p>"Traditional service meshes are an all-or-nothing proposition that add a significant layer of complexity to your stack. That’s not great."<p>Istio is like k8 it's very modular and you setup what you need.<p>"Traditional service meshes are designed to meet the needs of platform owners, and they dramatically underserve a more important audience: the service owners."<p>Not sure what it means, Istio is all about observability ect...
This looks great but I'll hold off using it until it gets automatic sidecar injection.<p>The CLI YAML-adulterer doesn't fit into my flow very well.
Doesn't seem like it is designed to work outside of k8s anymore?<p>Anyone know of a service mesh that is intended to run in a more standalone fashion? (itsio also integrates very strongly to k8s)
I get why I want metrics from an RPC service, but not why I want them behind a process boundary. How do custom metrics (items processed/filtered per request, experiment vs control SR) work?
For those that care, the core of linkerd 2.0 is in Rust<p><a href="https://github.com/linkerd/linkerd2-proxy" rel="nofollow">https://github.com/linkerd/linkerd2-proxy</a>