ebook

The Difference
Between API Gateways
and Service Mesh
Why API Management and Service Mesh are
Complementary Patterns for Different Use Cases

KongHQ.com
1 © Kong Inc. The Difference Between API Gateways and Service Mesh
 Table of contents

03 15
Introduction Cheat Sheet

04 16
API Gateways Example:
1. APIs as a Product A Financial Institution
2. Service Connectivity
3. Full Lifecycle API Management

09 18
Service Mesh About Kong
1. Service Connectivity

13
API Gateway vs. Service Mesh

2 © Kong Inc. The Difference Between API Gateways and Service Mesh
 Introduction
For many years, API management (APIM) — and the adoption of API
gateways — was the primary technology used to implement modern
API use cases both inside and outside the data center.
API gateway technology has evolved a lot in the past decade, capturing bigger and more
comprehensive use cases in what the industry calls “full lifecycle API management.” It’s not just
the runtime that connects, secures, and governs our API traffic on the data plane of our requests
but also a series of functionalities that enable the creation, testing, documentation, monetization,
monitoring, and overall exposure of our APIs in a much broader context — and target a wider set
of user personas from start to finish. That is, there is a full lifecycle of creating and offering APIs
as a product to users and customers, not just the management of the network runtime that allows
us to expose and consume the APIs (RESTful or not).

Then around 2017, another pattern emerged Over time, the technology implementations
from the industry: service mesh. Almost caught up with the original vision of service
immediately, the industry failed to recognize mesh, and more and more users implemented
how this pattern played with the API gateway the pattern and told their stories. This allows us
pattern, and a big cloud of confusion started to now have a more serious rationalization as
to emerge. This was in part caused by the to what service mesh is (and what it is not) and
complete lack of thought leadership of pre- what the role of API gateways (and APIM) is in
existing APIM vendors that have failed to a service mesh view of the world.
respond adequately to how service mesh
complemented the existing APIM use cases. Many people have already attempted to
describe the differences between API gateways
It was also in part because service mesh and service meshes, and it’s been commonly
started to be marketed to the broader industry communicated that API gateways are for north-
by the major cloud vendors (first by Google, south traffic and service meshes are for east-
later by Amazon, and finally by Microsoft) at west traffic. This isn’t accurate, and if anything,
such a speed that the developer marketing it underlines a fundamental misunderstanding
clout of this new pattern preceded the actual of both patterns.
mainstream user adoption, therefore creating
a misperception in the industry as to what In this piece, we’ll illustrate the differences
service mesh really was (developer marketing) between API gateways and service mesh — and
and was not (technology implementations). when to use one or the other in a pragmatic
It was almost like a mystical pattern that and objective way.
everybody spoke about but very few mastered.

3 © Kong Inc. The Difference Between API Gateways and Service Mesh
 API Gateways
The API gateway pattern describes an additional hop in the network
that every request will have to go through to consume the underlying
APIs. In this context, some people call the API gateway a centralized
deployment.
Being on the execution path of every API request, the API gateway is a data plane that receives
requests from a client and can enforce traffic and user policies before finally reverse proxying
those requests to the underlying APIs. It can — and most likely will — also enforce policies on the
response received from the underlying API before proxying the request back to the original client.

An API gateway can either have a built-in CI/CD pipelines. However, the API management
control plane to manage and configure the landscape has settled on separating the data
data plane, or the data plane and the control plane from the control plane for reasons of
plane can all be bundled together into the resiliency, security, and manageability.
same process. While having a separate control
plane is certainly better, some API gateway The API gateway is deployed in its own
implementations were able to thrive with a instance (its own VM, host, or pod) separate
DP+CP bundle in the same process because from the client and separate from the APIs. The
the number of API gateway nodes that would deployment is therefore quite simple because it
be deployed was usually of a manageable size is fully separated from the rest of the systems
and updates could be propagated with existing and it fully lives in its own architectural layer.

API gateways usually cover three primary API use cases for both internal and external service
connectivity as well as for both north-south (outside the datacenter) and east-west (inside the
datacenter) traffic.

4 © Kong Inc. The Difference Between API Gateways and Service Mesh
 api gateways

1. APIs as a Product
The first use case is about packaging the API as a product that other
developers, partners, or teams will consume.
The client applications that are built can initiate of the product (that’s exposing the API) that
requests from outside of the organization (like they are consuming.
in the case of a mobile application) or from
inside the same company (like in the case of This use case is very common whenever
another product, perhaps built by another team different products/applications need to talk to
or another line of business). Either way, the each other, especially if they have been built by
client applications will run outside of the scope different teams.

5 © Kong Inc. The Difference Between API Gateways and Service Mesh
 When offering APIs as a product, an API gateway will encapsulate
common requirements that govern and manage requests originating
from the client to the API services.
For example, AuthN/AuthZ use cases, rate- could be running east-west traffic if it’s being
limiting, developer on-boarding, monetization, deployed in the same data center as the APIs
or client application governance. These are it’s consuming. The direction of traffic is
higher-level use cases implemented by L7 fundamentally irrelevant.
user policies that go above and beyond the
management of the underlying protocol since API gateways are also used as an abstraction
they govern how the users will use the API layer that allow us to change the underlying
product. APIs over time without having to necessarily
update the clients consuming them. This is
The APIs exposed by an API gateway are especially important in those scenarios where
most likely running over the HTTP protocol the client applications are built by developers
(i.e., REST, SOAP, GraphQL, or gRPC), and the outside of the organization that cannot be
traffic can be both north-south or east-west forced to update to the greatest and latest APIs
depending if the client application runs inside every time we decide to update them. In this
or outside the data center. instance, the API gateway can be used to keep
the backward compatibility with those client
A mobile application will run mostly north- applications as our underlying APIs change
south traffic to the API gateway, while over time.
another product within the organization

6 © Kong Inc. The Difference Between API Gateways and Service Mesh
 api gateways

2. Service Connectivity
The second use case is about enforcing networking policies to
connect, secure, encrypt, protect, and observe the network traffic
between the client and the API gateway, as well as between the API
gateway and the APIs.
They can be called L7 traffic policies because different versions of our APIs (in this context,
they operate on the underlying network traffic it can also enable blue/green and canary
as opposed to governing the user experience. deployments use cases), as well as fault
injection, and so on.
Once a request is being processed by the
API gateway, the gateway itself will have to The underlying APIs that we’re exposing
make a request to the underlying API in order through the API gateway can be built in any
to get a response (the gateway is, after all, a architecture (monolithic or microservices)
reverse proxy). Usually, we want to secure the since the API gateway makes no assumption
request via mutual TLS, log the requests, and as to how they are built as long as they expose
overall protect and observe the networking a consumable interface. Most likely the APIs
communication. The gateway also acts as a are exposing an interface consumable over
load balancer and will implement features like HTTP (i.e., REST, SOAP, GraphQL, or gRPC).
HTTP routing, support proxying the request to

7 © Kong Inc. The Difference Between API Gateways and Service Mesh
 api gateways

3. Full Lifecycle API Management

The third use case of an API gateway is being one piece of a larger
puzzle in the broader context of API management.
As we all know, managing the APIs, their Furthermore, when offering APIs as a product,
users and client applications, and their traffic the APIs will have to provide a portal for end
at runtime are only some of the many steps users to register their applications, retrieve the
involved in running a successful API strategy. credentials, and start consuming the APIs.
The APIs will have to be created, documented,
tested, and mocked. Once running, the APIs will
have to be monitored and observed to detect
anomalies in their usage.

This broader experience, which is end-to-end and touches various points of the API lifecycle (and
most likely different personas will be responsible for different parts of the lifecycle), is called full
lifecycle API management, and effectively most APIM solutions provide a bundled solution to
implement all of the above concerns in one or more products that will in turn connect to the API
gateway to execute policy enforcement.

8 © Kong Inc. The Difference Between API Gateways and Service Mesh
 Service Mesh
With service mesh, we’re identifying a pattern that fundamentally
improves how we build service-to-service connectivity among two or
more services running in our systems.
Every time a service wants to make a network request to another service (for example, a monolith
consuming the database or a microservice consuming another microservice), we want to take
care of that network request by making it more secure and observable — among other concerns.

Service mesh as a pattern can be applied so they could enhance the connectivity
on any architecture (i.e., monolithic or of any outbound — or inbound — network
microservice-oriented) and on any platform requests that their application would either
(i.e., VMs, containers, Kubernetes). make or receive. The application teams were
implementing these use cases by writing
In this regard, service mesh doesn’t introduce more code in their services. This means that
new use cases, but it better implements different teams would be re-implementing
existing use cases that we already had to the same functionality over and over again
manage prior to introducing service mesh. — and in different programming languages,
Even before implementing service mesh, creating fragmentation and security risks for
the application teams were implementing the organization in managing the networking
traffic policies like security, observability, connectivity.
and error handling within their applications

Prior to service mesh, the teams wrote and maintained code to manage the network connectivity to third-party
services. Different implementations exist to support different languages/frameworks.

9 © Kong Inc. The Difference Between API Gateways and Service Mesh
 With the service mesh pattern, we’re The proxy will be on the execution path of
outsourcing the network management of any every request, and it’s therefore a data plane
inbound or outbound request made by any process. And since one of the use cases is
service (not just the ones that we build, but implementing end-to-end mTLS encryption and
also third-party ones that we deploy) to an observability, we would run one instance of the
out-of-process application (the proxy) that will proxy alongside every service so that we can
manage every inbound and outbound network seamlessly implement those features without
request for us. And because it lives outside of requiring the application teams to do too much
the service, it’s by default portable and agnostic work and abstracting those concerns away
in order to support any service written in any from them.
language or framework.

We run one instance of the proxy alongside every instance of our services.

Because the data plane proxy will run alongside same machine (VM, host, pod) as the service
every replica of every service, some will call that we’re running. Ideally, if the benefits of
service mesh a decentralized deployment (as the proxy are valuable enough and the latency
opposed to the API gateway pattern, which is low enough, the equation would still turn in
a centralized deployment). Also, since we’re favor of having the proxying as opposed to
going to be having extra hops in the network having fragmentation in how the organization
and in order to keep the latency at a minimum, manages the network connectivity among our
we would run the data plane proxy on the services.

10 © Kong Inc. The Difference Between API Gateways and Service Mesh
 The proxy application acts as both a proxy In order to configure them all, we would need
when the request is outgoing and as a reverse a control plane that acts as the source of truth
proxy when the request is incoming. Because for the configuration and behavior we want to
we’re going to be running one instance of enforce and that would connect to the proxies
the proxy application for each replica of our to dynamically propagate the configuration.
services, we’re going to be having many proxies Because the control plane only connects to
running in our systems. the proxies, it isn’t on the execution path of our
service-to-service requests.

The service mesh pattern, therefore, is more service replica) is considered to be the industry
invasive than the API gateway pattern because standard since it guarantees the best, highest
it requires us to deploy a data plane proxy next availability and allows us to assign a unique
to each instance of every service, requiring us identity (via a mTLS certificate) to every replica
to update our CI/CD jobs in a substantial way of every service.
when deploying our applications. While there
are other deployment patterns for service With service mesh, we’re fundamentally dealing
mesh, the one described above (one proxy per with one primary use case.

11 © Kong Inc. The Difference Between API Gateways and Service Mesh
 service mesh

1. Service Connectivity
By outsourcing the network management to a third-party
proxy application, the teams can avoid implementing network
management in their own services.
The proxy can then implement features like mutual TLS encryption, identity, routing, logging,
tracing, load-balancing, and so on for every service and workload that we deploy, including third-
party services like databases that our organization is adopting but not building from scratch.

Since service connectivity within the From a conceptual standpoint, service mesh
organization will run on a large number has a very simple view of the workloads that
of protocols, a complete service mesh are running in our systems: everything is a
implementation will ideally support not just service, and services can talk to each other.
HTTP but also any other TCP traffic, regardless Because an API gateway is also a service that
if it’s north-south or east-west. In this context, receives requests and makes requests, an API
service mesh supports a broader range of gateway would just be a service among other
services and implements L4/L7 traffic policies, services in a mesh.
whereas API gateways have historically been
more focused on L7 policies only.

Because every replica of every service requires The address can be associated with any
a data plane proxy next to it and the data plane meta- data, like the service name. By doing so,
proxies are effectively client load-balancers a service mesh essentially provides a built-
so they can route outgoing requests to other in service discovery that doesn’t necessarily
proxies (and therefore other services), the require a third-party solution. A service
control plane of a service mesh must know discovery tool can still be used to communicate
the address of each proxy so that the L4/ L7 outside of the mesh but most likely not for the
routing capability can be performed. traffic that goes inside the mesh.

12 © Kong Inc. The Difference Between API Gateways and Service Mesh
 API Gateway vs. Service Mesh
It’s clear by looking at the use cases that there’s an area of overlap
between API gateways and service meshes, and that’s the service
connectivity use case.

The service connectivity capabilities that API management lifecycle, which still belong to
service mesh provides are conflicting with the the API gateway pattern.
API connectivity features that an API gateway
provides. However, because the ones provided Since service mesh provides all the service
by service mesh are more inclusive (L4 + L7, all connectivity requirements for a broader range
TCP traffic, not just HTTP, and not just limited of use cases (L4+L7), it’s natural to think that it
to APIs but to every service), they’re in a way would take over those concerns away from
more complete. But as we can see from the the API gateway (L7 only). This conclusion is
diagram above, there are also use cases that valid only if we can leverage the service mesh
service mesh doesn’t provide, and that is the deployment model, and as we’ll explore, this
“API as a product” use case as well as the full isn’t always the case.

13 © Kong Inc. The Difference Between API Gateways and Service Mesh
 One major divergent point between the two patterns is indeed the
deployment model: in a service mesh pattern, we must deploy a
proxy data plane alongside every replica of every service.
This is easy to do when a team wants to deploy 4. Services deployed in the same service
service mesh within the scope of its own mesh will have to use the same CA
product — or perhaps its own line of business (Certificate Authority) to be provided with
— but it gets harder to implement when we a valid TLS certificate to consume each
want to deploy the proxy outside of that scope other, and sharing a CA may not be possible
for four reasons: or desirable among services that belong
to different products or teams. In this
APIOps focuses on establishing four core instance, two separate service meshes
technical pillars: (each one with its own CA) can be created,
and they can communicate with each other
1. Deploying a proxy application alongside via an intermediate API gateway.
every service of every product within the
organization can be met with resistance, Given that API gateways and service meshes
since different products, teams, and lines focus on different use cases, I propose the
of business may have fundamentally following cheat sheet to determine when to
different ways to build, run, and deploy their use an API gateway and when to use a service
software. mesh, with the assumption that in most
2. Every data plane proxy must initiate a organizations, both will be used since both
connection to the control plane, and in use cases (the product/user use cases and
certain cases, we don’t want — or we can’t the service connectivity one) will have to be
— grant access to the control plane from implemented.
services that are deployed outside of the
boundaries of a product, a team or a line of
business within the organization.
3. It isn’t possible to deploy the proxy data
plane alongside every service because
we don’t 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.

14 © Kong Inc. The Difference Between API Gateways and Service Mesh
 Cheat Sheet
It’s clear by looking at the use cases that there’s an area of overlap
between API gateways and service meshes, and that is the service
connectivity use case.

We’ll use an API gateway to offer APIs “as a your systems via a decentralized sidecar
product” to internal or external clients/users deployment model that can be adopted and
via a centralized ingress point and to govern enforced on every service. Commonly used
and control how they are being exposed and within the scope of an application, and to
on-boarded via a full lifecycle APIM platform. create point-to-point connectivity among all the
Commonly used when different applications services that belong to the application.
need to talk to each other, and also used to
create an abstraction layer between the clients Most likely, the organization will have both of
and the underlying APIs. these use cases and therefore an API gateway
and service mesh will be used simultaneously.
We’ll use service mesh to build reliable, secure
and observable L4/L7 traffic connectivity
among all the services that are running in

15 © Kong Inc. The Difference Between API Gateways and Service Mesh
 Example: A Financial
Institution
Given the chart above, we can provide the following example.
It’s very common for an organization to have different teams building different products, and
these products will have to talk to each other. For example, a financial institution may have a
“banking product” to perform banking activities and a “trading product” that would allow trading
on the stock market, but the two products will have to communicate to share information
between them.

These teams will also decide at one point in the Therefore they want to set up policies in
roadmap to implement service mesh in order place to on-board the team as if it were an
to improve the service connectivity among the external user via an internal API gateway. The
services that are making up the final product. mobile team also will have to consume both
Because different teams run at different products, and they’ll have to go through an
speeds, they’ll implement two service meshes edge API gateway ingress point to do that. The
that are isolated from each other: “Service architecture would look like this:
Mesh A” and “Service Mesh B.”

Let’s assume that in order to be highly

available, both products are being deployed on
two different data centers, “DC1” and “DC2.”
The banking team wants to offer its service
as a product to their internal customer, the
trading team.

16 © Kong Inc. The Difference Between API Gateways and Service Mesh
 Service Mesh A and Service Mesh B

17 © Kong Inc. The Difference Between API Gateways and Service Mesh
 About Kong
Kong is the foundation that enables any company to become an API-
first company — speeding up time to market, creating new business
opportunities, and delivering superior products and services.
Built on the world’s most adopted API gateway, Kong’s easy-to-use cloud API platform
delivers fast, reliable, secure digital experiences. Increase developer productivity, security, and
performance at scale with the unified platform for API management, service mesh, and ingress
controller.

18 © Kong Inc. The Difference Between API Gateways and Service Mesh
 Konghq.com

Kong Inc.
[email protected]

77 Geary Street, Suite 630

San Francisco, CA 94108
USA

19 © Kong Inc. The Difference Between API Gateways and Service Mesh