Conduit 0.5.0 and the future of Conduit
blog.conduit.io
Conduit 0.5.0 and the future of Conduit
1–10 of 12 posts
Re: Conduit 0.5.0 and the future of Conduit
#2>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?
Re: Conduit 0.5.0 and the future of Conduit
#3>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 Net…
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.
Re: Conduit 0.5.0 and the future of Conduit
#4>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 Net…
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.
Re: Conduit 0.5.0 and the future of Conduit
#5>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 Net…
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
Re: Conduit 0.5.0 and the future of Conduit
#6>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 Net…
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).
Re: Conduit 0.5.0 and the future of Conduit
#7One of the biggest draws of Linkerd over Envoy (prior to Consul Connect at least) was that it seemed more feasible to use outside of Kubernetes.
Conduit however is tightly coupled to Kubernetes as I understand, which isn’t really addressed in this blog post.
Re: Conduit 0.5.0 and the future of Conduit
#8>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 Net…
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.
Re: Conduit 0.5.0 and the future of Conduit
#9One of the biggest draws of Linkerd over Envoy (prior to Consul Connect at least) was that it seemed more feasible to use outside of Kubernetes. Conduit however is tightly coupled to Kubernetes as I understand, which isn’t really addressed in this blog post.
I think many people believe that Kubernetes has won and this where the money is. Big Co’s will be looking for contract support for anything they run on kubernetes.
Re: Conduit 0.5.0 and the future of Conduit
#10Wow, on a side note, when I saw it I almost thought it was the scammy Israel company that used to thrust adware/malware through its toolbars back then.