API gateway patterns: edge vs service mesh — when to use which?
Yara Morales
·491 views
we're running Kong as our API gateway at the edge, handling things like authentication, rate limiting, and basic routing for external traffic. however, our platform team is now pushing to introduce Istio as a service mesh for inter-service communication within our microservice ecosystem. this brings up concerns about feature overlap.
both Kong and Istio offer capabilities like load balancing, circuit breaking, and traffic management. how do teams typically divide responsibilities between an edge API gateway and an internal service mesh? should the edge gateway primarily handle north-south traffic and security, while the service mesh focuses entirely on east-west communication and observability? or are there specific features where one excels over the other that dictates the split? avoiding redundant configurations is a priority.
12 comments