Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Conduit – open-source service mesh for Kubernetes

buoyant.io

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Introducing Conduit – open-source service mesh for Kubernetes

#41

Post by manigandham »

penland wrote: post #30

I'm happy for the guys at Bouyant, they've been great to work with in the past. There's a very large complexity payment inherent in the new "cloud native" architectures that fundamentally isn't worth it for a large swath of use cases. Conduit, at first glance, appears like it might solve a large portion of it. If there's anything the last 10 years have shown us as an industry, it's that convention and programmer ease…

Istio actually uses Envoy as the traffic proxying layer so what do you mean by unify them?

Re: Introducing Conduit – open-source service mesh for Kubernetes

#42

Post by manigandham »

gechr wrote: post #5

At first glance, this looks like a direct competitor to Envoy[1]. I'm sure the documentation will improve as the product matures, but right now much is left to the imagination. Could you perhaps go in to more detail on the differences between the two? [1] https://www.envoyproxy.io/

It’s more of a competitor to Istio, which uses Envoy to proxy traffic.

Re: Introducing Conduit – open-source service mesh for Kubernetes

#43

Post by mtone »

moomin wrote: post #40

Great, another OSS project with a name that’s a commonly used word. Let’s hope they’ve checked there’s no existing projects with that name. (Spoilers: they haven’t.)

What I associate with the name is a malware browser ad/toolbar network a few years back.

Re: Introducing Conduit – open-source service mesh for Kubernetes

#44

Post by manigandham »

maktouch wrote: post #34

How does it work with ingress? Does it ship with its own ingress like istio? We tried istio a while back and it was too slow and hungry. Reverted back to no service mesh and it worked fine. I'm gonna be trying this next!

If you just want Ingress with Envoy, Heptio now has the Contour project:

https://github.com/heptio/contour

Re: Introducing Conduit – open-source service mesh for Kubernetes

#47

Post by otterley »

gmiranda23 wrote: post #13
olix0r wrote: post #9

Earlier quoted context omitted.

Like Linkerd, Envoy is a proxy that can be used used to build a service mesh. Conduit is a service mesh that includes a proxy. So, yes, Conduit uses something that competes with Envoy ;) But I would not say that Conduit and Envoy are equivalent things.

A service mesh needs a data plane (e.g. Envoy) and a control plane (e.g. Istio). Conduit has both in one product.

But how is Conduit better than the combined products? Doing two things poorly is worse than doing one thing well. (I'm not suggesting that Conduit does anything poorly, but it's not clear how it's superior in any way to any competing implementation.)

Re: Introducing Conduit – open-source service mesh for Kubernetes

#48

Post by bmurphy1976 »

dsl wrote: post #14

But what in the hell is it? If your product is so revolutionary it defines a new market segment, you might want to bring the people with the money people up to speed.

Typically a mesh is a set of proxies that are colocated with each service you deploy. The proxies facilitate service discovery and secure communication with other services. They abstract this functionality such that each service doesn't have to individually (and poorly) reinvent that wheel.

Your service would connect to database:5432, but instead of going straight to the database it goes to a proxy and the proxy has all the smarts to find and connect to the database, even if it's in another data center. The proxy can also do it securely such that you can go over the public network if necessary.

There's a good chance you don't need this complexity, but if you are hosting 100's of small services across multiple cloud providers, regions, or data centers, this starts to become an attractive option.

Re: Introducing Conduit – open-source service mesh for Kubernetes

#49

Post by twic »

steveklabnik wrote: post #19
Xeoncross wrote: post #17

> Conduit's Rust-based data plane proxies run in less than 10mb RSS and have sub-millisecond p99 latencies. I love seeing things move from Java/PHP/Ruby to Go (or better) Rust. Memory usage plummets.

It's becoming something we're increasingly hearing from production users. To some of them, low, stable memory usage is almost more important than some of Rust's other features.

For components you run alongside your applications, it's really great. I once worked on an infrastructure where we deployed a lightweight but JVM-based proxy in front of every app, and that was basically a tariff of 256 MB on everything we deployed.

Re: Introducing Conduit – open-source service mesh for Kubernetes

#50

Post by tybit »

otterley wrote: post #47
gmiranda23 wrote: post #13

Earlier quoted context omitted.

A service mesh needs a data plane (e.g. Envoy) and a control plane (e.g. Istio). Conduit has both in one product.

But how is Conduit better than the combined products? Doing two things poorly is worse than doing one thing well. (I'm not suggesting that Conduit does anything poorly, but it's not clear how it's superior in any way to any competing implementation.)

What they are presumably going for is ease of use, Istio uses a pluggable service mesh with Envoy being the most common one, and Linkerd being one of the alternatives.

I'm guessing they think Conduit can bring value by being an intergated solution out of the box, and I'm excited to see if they can deliver on that.

Post reply on HN