Conduit 0.5.0 and the future of Conduit | Hacker News Reader

Conduit 0.5.0 and the future of Conduit

blog.conduit.io

93 pointspyronicide11 comments

>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?

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.

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.

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

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).

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.

Wow, 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.

[1] http://malware.wikia.com/wiki/Conduit_Search

Haha, I remember them. (sighs)

One 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.

I mean, clearly Kubernetes has won. That shouldn't be a matter of debate when Mesosphere is doing product releases with top-line functionality designed to make it easier for you to operate Kubernetes.[1]

And Swarm has been a clear loser for a while now.

I say this despite us running a reasonably sized Aurora/Mesos deployment! Three years ago this was probably the right choice. Today I think you end up debating things like whether or not you should go with self-hosting Kubernetes vs managed vs what Mesosphere is pitching now.

[1] https://mesosphere.com/blog/dcos-1_11-overview/

Reply on news.ycombinator.com