From Custom to Community: Embracing Envoy for Service Mesh Proxies at ING
summary
ING replaces a bespoke JVM sidecar with Envoy sidecars, translating existing concepts (endpoints→clusters, retries, timeouts, mTLS, JWT auth) into dynamic XDS config served by an in-pod controller, and runs a pilot to production across 2,200 microservices while keeping the control plane unchanged. Conformity is enforced with the conformance test kit. Workarounds include running Envoy in a container on RHEL8 and contributing an SNI endpoints fix back to upstream; the migration works in production.
AI-written summary · about
chapters (14)
- 0:00ING’s service mesh journey
- 1:03Requirements for ING’s mesh
- 3:15Service mesh architecture
- 6:02Custom to sidecar pattern
- 9:30Custom sidecar challenges
- 11:13Adopting Envoy as proxy
- 13:01Envoy migration design
- 15:53Proof of concept pilot
- 16:34Final architecture model
- 18:47Reliability testing
- 20:12Migration challenges
- 21:55Contributing to Envoy
- 23:00Takeaways and future
- 24:02Q&A
related talks
29mSpanning the Globe with Envoy at Stripe
40mIntroducing A New Architecture for Simplified Service Mesh Deployments
32mService Mesh - Beyond the Hype
27mControl Plane for Large Mesh in a Heterogeneous Environment
48mProxies, Gateways, and Service Mesh. Why Are Words so Confusing?
25mEventually Consistent Service Discovery
41mService Mesh beyond single clusters
27mConsul Mesh Federation Deep Dive