Istio and API Management Integration with Envoy WeAssembly Extensions
summary
Claims that mixer’s control-plane calls become a latency and scaling bottleneck and that pushing policy into Envoy via istiod and WebAssembly fixes it. Demonstrates a Red Hat 3scale WebAssembly extension deployed to Envoy sidecars on OpenShift with Istio service-mesh 2.x, records authentication and usage in 3scale while tracing in Jaeger/Kiali, and shows per-request traces around 20–32 ms. Shows the extension runs in a sandbox, scales per workload selector, and replaces the old mixer adapter pattern with envoy-sidecar WASM filters.
AI-written summary · about
chapters (26)
- 0:00Intro
- 0:28Agenda
- 1:21Traditional API Management
- 2:02Managing External Clients
- 3:06Managing Microservices
- 4:22Service Mesh
- 5:18API Management vs Service Mesh
- 7:57When to use API Management
- 8:39Challenges with API Management
- 9:21Intradomain traffic vs interdomain traffic
- 11:13Red Hat Integration
- 11:56Customers and Stakeholders
- 12:34API Management and Service Mesh
- 13:04Service Mesh Architecture
- 15:17Mixer
- 18:00Why WeAssembly
- 19:55Deployment
- 20:27WebAssembly
- 22:23Proxy
- 23:30Istio Integration
- 24:58API Management Mixer
- 28:05Demo
- 30:30Demo with API Management Platform
- 33:56Demo with Service Mesh
- 37:43Istio Service Mesh
- 42:58Wrap up
related talks
32mIstio: Weaving the Service Mesh [I]
42mIstio: Weaving, Securing and Observing microservices
48mIstio An open platform to connect, manage, and secure microservices
32mIstio: Sailing to a Secure Services Mesh
42mAmbient Mesh: new sidecar less & faster Istio for zero trust
46mStop reinventing the wheel with Istio
16mUsing Keycloak Authorization Service for Kubernetes Service-to-Service…
42mSecuring Kubernetes Workloads with Istio Service Mesh