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.
I love seeing things move from Java/PHP/Ruby to Go (or better) Rust. Memory usage plummets.
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?
So, yes, Conduit uses something that competes with Envoy ;) But I would not say that Conduit and Envoy are equivalent things.
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.
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!
It does seem like JVM based products standard answer "Buy More hardware" is becoming untenable.
It's not surprising that Istio settled on Envoy, which is written in C++.
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.
However from where I am standing, it is still business as usual, regarding Java and .NET projects.
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.
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.