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.
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.
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.
The first release doesn't include Ingress support. This is something we plan on folding into our Routing API in an upcoming release. If you have opinions on how you'd like to see Ingress implemented, now is a great time to share your thoughts (in a GitHub issue, is probably best)!
Have you tried using envoy directly? That's what we run, and it works well. I'd be interested to hear about the kinds of problems you ran into (as in, "yikes, is there something we should be watching out for", not "marketing").
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++.
Spot on. FWIW with some effort we can get Linkerd down to ~110mb. For some companies that's acceptable. Still, it's a far cry from the ~3mb footprint that the Conduit proxies current have.
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.
Hence the ongoing efforts for value types ,some kind of reiffed generics and AOT compilation, or do you think Oracle would sponsor those changes out of charity?
However from where I am standing, it is still business as usual, regarding Java and .NET projects.
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.
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.
I came here to say exactly this. A Google of "Conduit" gets every competing dictionary's take on the word. A search on "conduit software" gets you nothing but frustrated posts of people trying to remove conduit malware.
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.
It's an "open source service mesh." They're assuming you know what that is, and what their existing product (Linkerd) does in that space. I think that's reasonable for a blog post, and you can go look at their solid documentation if you don't.
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.)
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.