
Introducing Conduit – open-source service mesh for Kubernetes - steveklabnik
https://buoyant.io/2017/12/05/introducing-conduit/
======
penland
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 of use are the most important
qualities of a new framework or way of working.

Rails / Go / K8S dominating Mesos / Containers over Jails / Maven over ANT /
on and on. ActiveRecord is great, and Rails routing is great. Together they
are magical for what they provide a user. Envoy is great. Istio is great. But
there isn't a simplistic way to unify them even though for 95% of the industry
it appears their functionality should go hand in hand.

We'll see if Conduit can fill that gap.

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

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

~~~
steveklabnik
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.

~~~
twic
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.

------
gechr
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/](https://www.envoyproxy.io/)

~~~
olix0r
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.

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

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

~~~
tybit
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.

------
user1241320
I immediately thought of
[https://github.com/snoyberg/conduit](https://github.com/snoyberg/conduit)

------
SEJeff
I'm genuinely surprised they don't make a comparison to envoy or istio given
the users they're attempting to target.

------
maktouch
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!

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

[https://github.com/heptio/contour](https://github.com/heptio/contour)

------
geodel
> One thing we’ve learned is that there are deployment models where Linkerd’s
> resource footprint is simply too high.

It does seem like JVM based products standard answer "Buy More hardware" is
becoming untenable.

~~~
lobster_johnson
This is something of a special case. Running Linkerd as a sidecar container —
which is the pattern that's increasingly adopted in the Kubernetes world for
service meshes and proxies — means you're going to run a large, memory-hungry
JVM in every single container. Just guessing, but that's likely 300-500MB per
container. It just doesn't mesh (heh) well with how Kubernetes is supposed to
be run.

It's not surprising that Istio settled on Envoy, which is written in C++.

~~~
geodel
It is kind of sad that writing resource efficient software is considered a
special case.

~~~
lobster_johnson
Not really what I meant. It's a "special case" because the sidecar container
is a niche where the JVM doesn't work well. That doesn't mean you can't run
JVM successfully elsewhere, which of course people do.

For example, you may be deploying a bunch of lean Go microservices that, at
maximum, consume perhaps 20MB of memory each (peak). You can run 100 instances
of said app and only consume 2,000MB, but add a big JVM that weighs, say,
200MB a piece, you now need 22,000MB of memory instead.

JVM startup time might be another factor, but I've not measured this.

------
jacques_chester
At Pivotal there's a lot of interest in Istio. You might swing past the NYC
(still in Brooklyn?) or SF offices and try to talk people into looking at
Conduit.

------
csears
How does this compare to Istio or Envoy?

~~~
olix0r
Conduit will probably have quite a bit of feature-overlap with Istio,
especially, as it matures.

However, I think you'll find that the projects will be quite different in the
way that they prioritize features and operate.

Our goals for Conduit are to provide a minimal, production-ready,
commercially-supportable service mesh in the near-term. Time will tell how
each projects goals and constraints lead to different user experiences.

------
thunderman10
They should have chosen name that doesn`t immediately make users want to
uninstall it.

~~~
olix0r
If you think Conduit is bad, you should see the list of names we _didn't_ use!
;)

~~~
choward
Number 17 will shock you.

------
rrampage
The link to the tower library in the article is not working
([https://github.com/BuoyantIO/tower](https://github.com/BuoyantIO/tower))

~~~
klingerf
Updated to [http://github.com/tower-rs/tower](http://github.com/tower-
rs/tower) \-- thanks for the heads up.

------
sbr464
Nice, checkout Ambassador from Datawire also.

------
mkevac
What is service mesh? Seems that I need some more info to understand what is
this for...

------
juandazapata
There's a company named Conduit. Possibly incurring into trademark violations.

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

~~~
bmurphy1976
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.

~~~
dsl
I just force every application to use a standard reliable transport library.
Didn't realize I built a service mesh startup by accident...

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

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

------
Lukesys
Please don't release a toolbar ;)

