Service Mesh: A Hole in the Pocket?
summary
Service mesh adoption at scale adds concrete bills: control-plane config pushes can be megabytes to gigabytes across fleets up to ~100k nodes, Envoy sidecars add CPU/memory and latency, and metrics/logs can consume a majority of observability budget. Practical levers are explicit: tune HTTP/2 max_concurrent_streams and Envoy worker concurrency, sample or discard 2xx and healthcheck access logs, filter and roll up proxy stats before storage, and prefer local endpoints with outlier detection to reduce cross-AZ egress costs.
AI-written summary · about
chapters (12)
- 0:00Intro
- 2:13Service Mesh Costs
- 3:14Explicit Costs
- 4:09Hidden Costs
- 5:43Integration Costs
- 7:15Developer Costs
- 8:13Support Costs
- 10:50Strategies for Controlling Costs
- 12:35Onward
- 14:57Metrics
- 17:12Open Problems
- 19:14Summary
related talks
07mGetting the most out of service mesh
09mLightning Talk: The Hardest Part of Operating a Service Mesh: Envoy Proxy
11mWelcome & Opening Remarks
53mDo you need a Service Mesh?
20mKeynote: Service Meshes and Observability
10mWhat the heck is a Service Mesh ?
09mLightning Talk: Dissecting Service Mesh Overheads
20mThe Unexplored World of OpenTelemetry and Service Mesh