3 ms·
IMO that's ideal situation: when service does not encode any routing information and just talks to another service via fake DNS name. And actual routing is perf
by vbezhenar 3y ago
IMO that's ideal situation: when service does not encode any routing information and just talks to another service via fake DNS name. And actual routing is performed by infrastructure tools which can implement TLS, collect metrics, collect full HTTP logs if asked, implement retries, caching and so on. This is about outgoing connections and incoming connections.
It could also save on container size theoretically. Implementing TLS is a daunting task and requires many kilobytes of code. Implementing HTTP is easier task. So you can strip TLS implementation and achieve lighter containers.
- adql 3y agoYou save shit all if every container comes with sidecar doing the actual TLS, it's extra component to debug and extra small latency added.
- pojzon 3y agoOr you can leverage ebpf like cillium.
- nijave 3y agoIn practice it's not that much. I think our Envoy sidecars take, maybe, 8mb of RAM when the apps are usually 500-1000MB. They usually add afaik <1ms latency. In addition, you can implement client side load balancing through Envoy so you can hit your services directly without intermediary load balancers. It adds complexity with the side car but usually you get standardized RED metrics regardless of if the service implemented them. You can also have the sidecar do connection pooling and maintain persistent or long lived TCP connections which ends up speeding things up without doing that at the app level.