Distributed systems patterns with Spring Cloud, Service Meshes and eBPF
summary
Compares concrete stacks: Spring Cloud embeds discovery, config and resilience in-app so changes need rebuilds; Kubernetes supplies DNS, Services and ConfigMaps but not per-call circuit breaking; service meshes like Istio/Linkerd inject a proxy per pod (noticeable latency and memory overhead) to enable mTLS and weighted routing (demo shows a 90/10 split across two PetClinic versions), and eBPF (Cilium) runs one agent per node offering a lower-latency, sidecar-less mesh tested across two clusters with jMeter — demo shows traffic visualization working but occasional fragility.
AI-written summary · about
chapters (14)
- 0:00Start
- 7:02Resilience
- 8:26Security
- 9:17Canary Deployment
- 12:58Spring Cloud Classic
- 18:07Kubernetes
- 22:50Conflict Maps and Secrets
- 24:11Resiliency Patterns
- 24:51Service Mesh
- 25:38Why Does Kubernetes Do that
- 30:26Granularly Split the Traffic
- 41:36Wordpress on Kubernetes
- 43:53Load Test
- 46:40Hubble Ui
related talks
34mDistributed applications and Kubernetes
37mThe Service Mesh Wars: A New Hope for Kubernetes
31mClean-up Your Service Mess with Service Mesh
43mService MESH without the MESS
32mService Mesh - Beyond the Hype
45mService Mesh Big Survey
28mConnectivity Patterns for Cloud Native Applications
41mService Mesh beyond single clusters