API Gateway vs. Service Mesh

A common question that people ask is “should I use Ambassador if I’m using a service mesh (usually Istio)?” After all, both Ambassador and Istio are built on the Envoy Proxy. Moreover, Istio recently added support for explicitly managing ingress with the Gateway abstraction. So, do you need an API Gateway if you’re using a service mesh?

Ambassador (and API Gateways in general) focus on north/south traffic, i.e., traffic into your data center. Istio (and other service meshes) handle east/west traffic, i.e., traffic between services in your data center. If your service mesh already manages L7 traffic, can you use it for managing north/south traffic?

TL;DR

Our current perspective on service mesh and API Gateways is:

• The edge use case is sufficiently different that API Gateways and service meshes will both be needed
• Envoy Proxy will be used for L7 routing in both API Gateways and service meshes but will be managed with different control planes for North/South and East/West traffic
• Expect greater integration between API Gateways and service meshes over time
• Most organizations will start with an API Gateway over a service mesh, because everyone needs an ingress solution, while not everyone needs a service mesh.
• For many applications, API Gateways can provide much of the functionality that a service mesh provides, e.g., observability, canary releases, and dynamic routing.

At the Edge, You Don’t Control the Client

The fundamental difference between edge routing (north/south) and internal (east/west) routing is that with the edge, you don’t control the client. In the east/west scenario, you do have control of the client and therefore are able to make simplifying assumptions around your deployment architecture.

At the edge, though, you can’t explicitly control the client. The client can make requests with arbitrary formats and types, and you need to handle all of these permutations. Some examples of edge-related issues we’ve had to support in Ambassador include:

• Supporting redirection from HTTP to HTTPS. There are many nuances to redirection, depending on where you’re doing the TLS termination (external load balancer? inside Ambassador itself?).
• Support for theX-Forwarded-For HTTP header
• Human to machine authentication via OAuth, OIDC, and the like.
• Cross-origin resource sharing
• Lots of different ways of routing, such as regular expression routing, header-based routing, host header routing

Will API Gateways and Service Meshes Converge?

When we started the Ambassador project, service meshes were in their infancy (in fact, Istio had not yet been announced). We thought that, over time, service mesh functionality would subsume API Gateway functionality. After all, a service mesh provides rich controls and observability over Layer 7. We expose many of those same controls in Ambassador, with integrated monitoring, canary releases, shadow traffic, and distributed tracing.

A year later, we’re not sure that convergence is inevitable. At the very least, if it happens, it’s a long ways off. Thousands of Ambassador users have given us feedback on the different ways they’re deploying Ambassador at the edge. For us, we seem to learn about more edge-specific use cases every week.

API Gateway and Service Mesh Integration

Service meshes do address use cases that API Gateways don’t cover. Particularly as more services are added to your application, observability, control over L7, and resilience become more critical. Ensuring that an API Gateway can integrate with popular service meshes is an area that we continue to invest in. Thanks to our community, we’ve successfully integrated Ambassador’s distributed tracing and monitoring with Istio. We also have users who have integrated Ambassador with Istio’s mTLS to gain end-to-end encryption throughout the cluster.

Final Thoughts

Building a general purpose control plane that manages north/south as well as east/west traffic is a huge task. Moreover, how do you build a control plane that works for developers and operators? With Ambassador, we’re focusing on the edge use case and discovering hidden complexity with just this use case. We’re just as curious as anyone else to see how control planes evolve over the next few years. Stay tuned!