API Gateway and Service Mesh Uses Cases

There is a connectivity overlap within level 7 between the API Gateway and a Service Mesh.  Service Mesh’s, which are decentralized proxies running against each container, are used to manage network and routing between services.  API Gateway policies (centralized) can do the same.  When you design an API Gateway within a Service Mesh architecture you must clearly delineate the ‘owner’ of the service overlap.

Within Level 7 (networking) the service proxy connectivity capabilities will conflict with the API Gateway connectivity features.  The capabilities of the Service Mesh around networking are more comprehensive since they include both Level 4 and Level 7 traffic, which means they cover all TCP and not just HTTP traffic.  More use cases are thus covered by the service mesh for networking and can be ‘decoupled’ from the API Gateway.  However, the full API management life-cycle-management will still reside in the API gateway pattern.

We need to consider the design of both the API Gateway and Service Mesh.  Within the Service Mesh we will deploy a proxy data plane alongside every replica of every service.  This can be easy to do when a single team wants to deploy service mesh within the scope of its own product, or perhaps its own line of business, but it gets harder to implement when we want to deploy the proxy outside of that scope for four reasons.

Complications when deploying a Service Mesh:

1. Deploying a proxy application alongside every service of every product within the organization can be met with resistance, since different products, teams and lines of business may have fundamentally different ways to build, run and deploy their software.

• Every data plane proxy must initiate a connection to the control plane, and in certain cases, we don’t want — or we can’t — grant access to the control plane from services that are deployed outside of the boundaries of a product, a team or a line of business within the organization.

• It is not possible to deploy the proxy data plane alongside every service because we do not control all the services in the first place, like in the case of a third-party application built by a developer, customer or partner that is external to the organization.

• Services deployed in the same service mesh will have to use the same CA (Certificate Authority) in order to be provided with a valid TLS certificate to consume each other and sharing a CA may not be possible or desirable among services that belong to different products or teams. In this instance, two separate service meshes (each one with its own CA) can be created, and they can communicate to each other via an intermediate API gateway.

In summary API gateways and Service Meshes focus on different use cases, as given below.