Grab's service mesh evolution: From Consul to Istio

Summary

Grab describes migrating its service mesh from Consul and the Catcher fallback across a microservices ecosystem of more than 1,000 services spanning VMs, EKS clusters, AWS, and GCP. The existing setup exposed fleet-wide risk from a single Consul server issue, added fallback complexity, and lacked advanced traffic management, security controls, and robust multi-cluster support. After evaluating Application Load Balancer, Istio, AWS Lattice, and Linkerd for stability, performance, integration, and operational simplicity, the team selected Istio for its Kubernetes integration, flexible deployment models, and feature set. The design uses multiple control planes on dedicated Kubernetes clusters, active-active pairs, organization-based mesh boundaries, custom resource definitions, and cross-cluster endpoint discovery to support isolation, availability, routing, security, and observability. Migration began in Q4 2024 with GCP-to-AWS work alongside gRPC and HTTP traffic initiatives, using gradual shifting, rollback mechanisms, and performance monitoring while teams manage legacy systems and cross-mesh connectivity.

Takeaways

1. 1

   Grab selected Istio after comparing Application Load Balancer, Istio, AWS Lattice, and Linkerd on stability under high load, communication performance, infrastructure integration, and operational simplicity.

2. 2

   The planned architecture departs from the one-control-plane-per-cluster pattern by using multiple control planes on dedicated Kubernetes clusters, with active-active pairs for isolation, scalability, and high availability.

3. 3

   Migration began in Q4 2024 and combines cloud migration with gRPC and HTTP traffic initiatives, using gradual shifting, quick rollback mechanisms, and close performance monitoring to maintain service continuity.