3 ms·

Service Meshes are something necessary for a small portion of Fortune 500s which have 1000s of microservices. Sure you could use load balancers but it becomes c

Service Meshes are something necessary for a small portion of Fortune 500s which have 1000s of microservices. Sure you could use load balancers but it becomes cost efficient to move towards a client-side load balancer. If you aren't a Google, Apple, Microsoft, ...etc scale company than a service mesh might be a tad overkill

remram 3y ago
Isn't kube-proxy already a client-side load-balancer?
xyzzy_plugh 3y ago
You're close, but it's really when you have thousands of microservices using either shitty languages or shitty client RPC libraries where you can't easily perform client-side load balancing. There are plenty of languages and RPC frameworks where you can solve this without resorting to a service mesh. Practically, and to your point, service meshes solve an organizational problem, not a technical one.
marcosdumay 3y ago
I don't get this either. Doesn't the mesh become an scalability bottleneck just like load balancers? On that scale I'd expect people to use client-selected replicated services (like SMTP), and never something that centralizes connections (no matter where it's close to). You can always add observability at the endpoints. Unless your infrastructure is very unusual (like some random part of it costing millions of times more for no good reason, as on the cloud), this is not a big challenge; you add it to the frameworks your people use. (I mean, people don't go and design an entire service with whatever random components they pick, or do they?)
- crackez 3y ago
  With Istio (envoy) you run a "sidecar" container in your pods which handles the "mesh" traffic, so it scales with the number of instances of your pods.
  - marcosdumay 3y ago
    Oh, thanks. That does solve the issue.
packetlost 3y ago
So like a DNS SRV record with multiple entries. Or Anycast, if you're being fancy
- remram 3y ago
  Or IPVS... wait that's built into Kubernetes, it's kube-proxy.
  - packetlost 3y ago
    Right? Like, I really don't understand the problem that service mesh solves that isn't already solved by more standardized technologies
  - kircr 3y ago
    kube-proxy operates at L3/L4 while service meshes generally operate at L7 so it can load balance on a per HTTP request basis. Particularly useful for long lived connections commonly used in gRPC and others.

remram 3y ago

Isn't kube-proxy already a client-side load-balancer?

xyzzy_plugh 3y ago

You're close, but it's really when you have thousands of microservices using either shitty languages or shitty client RPC libraries where you can't easily perform client-side load balancing. There are plenty of languages and RPC frameworks where you can solve this without resorting to a service mesh. Practically, and to your point, service meshes solve an organizational problem, not a technical one.

marcosdumay 3y ago

I don't get this either. Doesn't the mesh become an scalability bottleneck just like load balancers? On that scale I'd expect people to use client-selected replicated services (like SMTP), and never something that centralizes connections (no matter where it's close to). You can always add observability at the endpoints. Unless your infrastructure is very unusual (like some random part of it costing millions of times more for no good reason, as on the cloud), this is not a big challenge; you add it to the frameworks your people use. (I mean, people don't go and design an entire service with whatever random components they pick, or do they?)

crackez 3y ago
With Istio (envoy) you run a "sidecar" container in your pods which handles the "mesh" traffic, so it scales with the number of instances of your pods.
- marcosdumay 3y ago
  Oh, thanks. That does solve the issue.

packetlost 3y ago

So like a DNS SRV record with multiple entries. Or Anycast, if you're being fancy

remram 3y ago
Or IPVS... wait that's built into Kubernetes, it's kube-proxy.
- packetlost 3y ago
  Right? Like, I really don't understand the problem that service mesh solves that isn't already solved by more standardized technologies
- kircr 3y ago
  kube-proxy operates at L3/L4 while service meshes generally operate at L7 so it can load balance on a per HTTP request basis. Particularly useful for long lived connections commonly used in gRPC and others.