The Past, Present and Future of Cloud Native API Gateways
summary
Survey of 25 years of edge evolution claims that architecture and workflow — not buzzwords — drive gateway choices, and gives three concrete Kubernetes strategies: spin up an additional k8s API gateway, extend existing F5/Citrix gateways via controllers, or deploy an in-cluster edge stack built on Envoy for single-source-of-truth GitOps. Cites real failures: header stripping between old and new gateways, missing HTTP/2 blocking gRPC, and recommends Argo/Flux-style pipelines plus a playground (app.getambassador.io) to validate before migration.
AI-written summary · about
chapters (10)
- 0:00Intro
- 0:23tl;dr
- 1:58Edge: The boundary between your data center & your user(s)
- 2:35Thesis
- 2:46History
- 10:20Challenges with microservices
- 16:44Thesis
- 17:112 biggest challenges with k8s & the edge
- 20:173 strategies for the edge with k8s
- 28:43Conclusion
related talks
50mGateway API, 10 Years of Maturation for a New Kubernetes API
25mBuilding APIs in a Cloud Native era
39mAPI Gateway to Service Mesh: Navigating a Changing Landscape
45mGrowing at the Edge: Doubling Traffic While Changing the API Gateway
39mEnvoy Gateway: The API Gateway in the Cloud Native Era
30mGateway to the Future: A Brief History of Kubernetes Ingress
10mCutting Through the Kubernetes Confusion: NGINX Ingress, Gateway Fabric, and What's Next
29mThe API Gateway Maturity Matrix: Where Do You Rank?