Turning Your Cloud Native Apps Inside Out With a Service Mesh
summary
Claims that moving Spring Cloud client libs into an Envoy-based service mesh yields consistent traffic management, observability and security across languages and clusters while removing per-app complexity. Architecture uses an Envoy sidecar per pod, replaces Eureka/Ribbon so you can remove Eureka and Ribbon and use Envoy/istio control plane for discovery, canarying and retries, and enforces mTLS via SDS for per-service identities. Latency increases slightly; demo repo shows the before/after code and runable examples.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 2:15Rewrite
- 3:55Why
- 7:00Common Ingredients
- 9:39Transparent Network Layer
- 11:59Envoy
- 16:39Consistency
- 19:49Application examples
- 21:03Server Ingress Service Discovery
- 23:00Initial Load Balancing
- 24:37Resilience
- 26:00Security
- 27:24Request Security
- 28:26Summary
related talks
53mService Mesh: What, Why, And How?
40mComparison of Current Service Mesh Architectures
28mService Mesh: Demystifying Istio
28mService Mesh and Sidecars with Istio and Envoy
58mService Mesh and Sidecars with Istio and Envoy
26mAn Introduction to Service Mesh in Action
48mWeaving Through the Mesh: Making Sense of Istio and Overlapping Technologies
30mIntroduction to Service Mesh for DevOps
