Making Envoy Sustainable
summary
Platform team builds a boring, testable Envoy gateway: config stays as merged YAML from console with a local starter instead of XDS at first, a linter enforces rules (no Lua, sane timeouts, regex checks), and nightly tests against Envoy master push failures into Slack so breakages get fixed immediately. The process adds required tech plans, test plans and small consumer agreements, plus automatic config migration scripts and deprecation tracking to make upgrades actually doable.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:25Deploying service meshes like Envoy
- 3:51Resisting Envoy updates
- 5:57Semantic versioning pitfalls
- 9:51Fixing upgrade resistance
- 13:42Easy upgrades for interns
- 16:05Envoy as technical debt
- 18:14Keep service mesh simple
- 20:43Planning features
- 21:24Structuring team agreements
- 23:48Managing deprecations
- 25:50Communicating expectations
- 26:11Q&A
related talks
17mLessons Learned: Four Years with Emissary-ingress and Envoy
33mThe End of a De...
29mUnderstanding, maintaining and securing Envoy's supply chain
05mWelcome + Opening Remarks
13mClosing Remarks
31mThe Practices That Made Me Go 'Wow': What Every CNCF Project Can Learn From Envoy
01h 02mEnvoy Overview and Maintainer Q&A
10mLightning Talk: Who is Envoy