Getty Images
Service mesh vs. API gateway: Where, why and how to use them
While they're both central to inter-application communication processes, it's important to understand the fundamental differences between a service mesh and an API gateway.
API gateways and service mesh have made a name for themselves as ways to manage the complex application communication processes that occur within a distributed system. Both of them, in their own way, play a role in supporting high-performance applications that are as scalable as possible. For instance, architects and developers use them to:
- streamline communications between disparate software resources;
- expose the data required to monitor and observe transactions within applications; and
- eliminate the need to code communication-based logic directly into an individual service or application.
So, does your development team need to implement an API gateway, or a service mesh? In many cases -- particularly in enterprise-level application development -- you'll need both. It is important for developers and architects to understand just as much about the differences between these two approaches to software communication as they do the similarities. Only then can teams make reliable decisions about the role these communication approaches should play in their application system and whether they are capable of managing either an API gateway or service mesh effectively.
Let's review the basics of what both of these application communication approaches are. Then, we'll examine some of the major differences that dictate when it's appropriate to implement service mesh vs. an API gateway.
What is an API gateway?
An API gateway is a service that accepts incoming API requests from clients, directs the request to the appropriate application service, processes that service's response and relays that response to the requesting client.
To understand how an API gateway works, consider a banking app that contains a collection of various microservices. One microservice might look up bank account data, while another service formats that account data for display on a web page. A user's request to view bank account details will trigger calls to both of these microservices, so they'll need an intermediary that ensures they handle that request correctly and in the right order. In this case, the API gateway would serve as a central point that accepts the requests, forwards it to the two microservices and sends the information back to the application so it can display the results to the user.
Technically, an API gateway isn't necessary. Developers could just embed code within the application that tells it how to handle requests (i.e. where to send requests and how to format the returned data). However, this approach requires a significant amount of extra development work. Furthermore, it may increase security risks, as any number of coding errors could expose an API to unauthorized access and potential abuse.
By managing API requests from external systems through a central gateway outside of the application, developers can create a more secure application while also simplifying communication management. API gateways also make it easier to monitor API requests, balance requests across multiple instances of a microservice and move microservices from one endpoint to another without disrupting the way API requests are handled.
What is a service mesh?
A service mesh is a component of IT infrastructure that manages communications between internal microservices and components, and helps them share the data that fuels application functionality. For example, in the banking app described above, the microservice that retrieves account data might need to issue another request to a microservice that validates user identities. The service mesh helps these two microservices communicate with each other and efficiently deliver the right results.
Like API gateways, service mesh isn't a strict necessity: It's possible to embed code that supervises these transactions into each microservice. However, this would be a difficult coding job, especially since network addresses assigned to individual microservices tend to change frequently. To keep up, developers would have to update application code whenever a microservice changes. Or, they would have to implement code-based mechanisms that help the microservices perform automatic self-discovery and keep constant track of changing network addresses, or any other identifying qualities that might change.
A service mesh solves this problem by automatically keeping track of the location and identify of each microservice and moving data between them. Say a certain microservice, which we'll call Service A, wants to share data with another microservice, Service B. In this case, Service A simply channels that data to the service mesh implementation, which will then forward the data to Service B. The service mesh will eventually collect a response from Service B that it will return to Service A.
Service mesh vs. API gateway: 5 key differences
Now that we defined both API gateways and service mesh, let's take a look at the major differences between the two approaches to application component communications:
External vs. internal communication
API gateways manage requests that originate externally, such as a request by an application user to view a certain page. In contrast, service meshes handle the internal requests that microservices make to other microservices within an application. In technical terms, API gateways supervise client-to-server communication, while service mesh deals with service-to-service communication.
Placement within an architecture
API gateways and service meshes operate within different layers of a typical software architecture stack. The API gateway is typically a public-facing infrastructure component, sitting between the edge of a network and the back end of an application -- including the service mesh. As external components and systems fire requests at the application, those requests are received and validated by the API gateway.
Eventually, the service mesh will likely help carry through the requests that an API gateway approves and passes to the back end. However, it starts at the API gateway.
Deployment and management
Compared to service mesh, API gateways are often simpler for the average developer to manage. Typically, you'll only need to deploy a gateway within your software stack once, and they usually lend themselves to easy, centralized monitoring.
A service mesh needs to integrate with and adapt to each application service that it helps manage. The most common implementation approach is to run service mesh agents in a proxy container -- often called a sidecar -- which operates alongside each instance of a containerized microservice and abstracts communication-centric logic away from that microservice. Thus, a service mesh introduces a flurry of moving parts and exponential complexity to deployment and monitoring.
Monitoring and observability
API gateway metrics provide the most value when tracking the overall health of an application, such as how long it takes to respond to specific API requests or how much the performance is impacted by high traffic. API gateway metrics may help identify problems with specific APIs, particularly when those problems can't be attributed to a network outage, application crash or some other common cause.
Meanwhile, service mesh metrics help teams identify issues with the individual microservices and components that inhabit an application's back end, rather than the overall application. Service mesh monitoring is helpful for pinpointing the source of certain application performance problems. However, it likely won't provide any indication of the effect of those problems from an outside perspective, such as how an issue with a specific microservice's response time impacts an end user's experience.
Tooling and support
API gateway tools or platforms are less likely to be open source. However, most API gateways work with any type of application or architecture.
Conversely, there are many open source options for service mesh support, such as Istio, Linkerd and Envoy. Keep in mind, however, that some service mesh tools are designed only to work in certain types of environments. AWS App Mesh only works within the AWS cloud, for example. Other service mesh options, like Linkerd, are built to support microservices that are deployed via Kubernetes.
Which one do you need?
Most applications can benefit from using API gateways and service meshes at the same time. While an API gateway can simplify the way the application handles external requests, the service mesh plays a crucial role in streamlining internal communication. An API gateway may forward a request to a specific microservice, but that microservice needs to communicate with another microservices, which is where the service mesh comes in.
As we discussed before, it's possible to use an API gateway without a service mesh, and vice versa. However, doing so is increasingly rare. If you want to maximize the agility of your application and minimize the effort developers expend on managing communications, you'll want to use both.
