Istio is a Big Important Service Mesh for Big Important People that does everything under the sun, and none of it well.
Neither project has real production adoption yet. (For that, you have to look at Linkerd). Istio will get adoption by spending infinite marketing dollars. Conduit will get adoption by solving actual problems.
Conduit's also significantly faster and smaller. Sub-millisecond p99 latencies, ~2mb RSS footprint per proxy. We took some big risks initially with Rust, but it's paid off handsomely.
If you can't get topline metrics dashboards for every service you're running in Kubernetes within 60 seconds of installing Conduit, I will literally* send a team of engineers to your house to fix it right in front of your face.
(* not actually literally)
Breaking down service success rate by inbound dependency is great for debugging many typical fault conditions.
It would be great to tie this into a release pipeline, where the release process is actively keeping an eye on failure rates of that service, so that bad deploys could be halted or rolled back automatically.
I was thinking this could work really well when using production integration tests. A percentage of that traffic can be dynamically routed to the newly running services, allowing the release pipeline to ensure the service is functioning correctly before routing any real users.
