[CBLT]

>Conduit will become Linkerd 2

I have not been following this space, is anybody willing to provide background?

It looks like linkerd developers re-wrote their Scala service in Rust, citing smaller footprint and lower p99 latency as wins from this approach. As a JVM-hater myself, I fully believe this conclusion, but my mind is open to change. Certainly there's at least some nuance? Furthermore, to my knowledge the Netflix plumbing model puts the middleware as java libraries rather than java services, avoiding going through another JVM like Linkerd does. Are stacks like Java and Ruby sufficiently poorly suited for middleware services that developers should be rewriting-in-rust away from them?

[rsanders]

The JVM tax on footprint isn't terrible when there is one instance per host providing the service mesh for all processes on that host. In a containerized deployment model, however, each process may have a "sidecar" process providing its entry point into the service mesh. Whether that's a problem depends, but it certainly gives people pause.

[iampims]

GC pauses are a problematic issue for proxies. It’s a lot of work to work around the GC on the JVM, so I’m not surprised to see them move on with Rust. There’s also the JVM stigma, that is difficult to squash.

Looking forward to Linkerd2

[clhodapp]

Your understanding is correct, though they also created a control plane (which they actually wrote in Go instead of Rust), added a bunch of features, removed a bunch of configurability, and restricted themselves to supporting apps running in Kubernetes as well.

[andyfleming]

Linkerd is a service mesh. Conduit is a newer service mesh by the same org, except built specifically for kubernetes. The new agent/proxy/sidecar is rust-based and the new control plane they wrote is in go. Linkerd 2 is basically going to merge conduit in, product-wise (and maybe even use it as the basis for linkerd 2, though I'm not familiar with the details).

[tybit]

The problem of middleware, other than needing a library per language, is that it moves the concern into the app rather than the host.

I see a service mesh more as extending the network functionality of the host OS and cluster than the app, which arguably makes rolling it out across a large disparate organisation more feasible.