Do you need a Service Mesh?
summary
Kubernetes cluster gets an installed service mesh control plane and transparently injected sidecar proxies next to each pod; a simple bookstore microservice demo shows 3 ratings versions and proves you can change routing from random to deterministic with header-based routing so one tester sees v2 while everyone else sees v1. The mesh emits logs, metrics and distributed traces and enforces mTLS and circuit breakers; configuration is declarative and pushed at runtime, and the demo largely works despite minor hiccups.
AI-written summary · about
chapters (18)
- 0:00Start
- 2:04Business Value
- 3:02Break the Monolith
- 4:04don't just distribute it!
- 6:39In-process libraries and frameworks
- 7:45Polyglot environments
- 8:00Must-have primitives
- 10:25And declarative infrastructure
- 12:26They work by adding a proxy to every servi
- 14:34And a control plane
- 33:14Observability
- 34:21Declarative Traffic Management
- 35:32But I have an Edge Proxy!
- 36:21But I have an API Gateway!
- 37:20But I have an APM system!
- 37:42But I have an ESB!
- 38:21There are many options
- 38:47Istio has the most momentum
related talks
01h 03mJust what is a "service mesh", and if I get one will it make everything OK?
53mDo you need a Service Mesh?
58mUsing Service Meshes and Kubernetes to Solve Service-to-Service Communications...
30mA Developer’s Introduction to Service Mesh
26mAn Introduction to Service Mesh in Action
34mService Mess to Service Mesh
34mService Mesh for Developers
50mMulti-Cluster Kubernetes and Service Mesh Patterns
