5 ms·

> 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 stand

by geodel 9y ago

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

pjmlp 9y ago
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.
lobster_johnson 9y ago
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 9y ago
  It is kind of sad that writing resource efficient software is considered a special case.
  - lobster_johnson 9y ago
    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.
- williamallthing 9y ago
  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.

by geodel 9y ago

pjmlp 9y ago

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.

lobster_johnson 9y ago

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 9y ago
It is kind of sad that writing resource efficient software is considered a special case.
- lobster_johnson 9y ago
  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.
williamallthing 9y ago
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.