21–30 of 54 posts
> 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.
However from where I am standing, it is still business as usual, regarding Java and .NET projects.
> 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.
It's not surprising that Istio settled on Envoy, which is written in C++.
> 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.
> 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.
> 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.
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 tha…
The link to the tower library in the article is not working ( https://github.com/BuoyantIO/tower )
Earlier quoted context omitted.
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 tha…
It is kind of sad that writing resource efficient software is considered a special case.
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.
> 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.
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 tha…
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.