Service mesh vs. API gateway: Where, why and how to use them – TechTarget

Getty Images
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:
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.
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.
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.
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:
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.
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.
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 sidecarwhich 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.
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.
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.
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.
Chaos engineering tool options include the original (Chaos Monkey), open source projects like Chaos Toolkit and Chaos Mesh and …
Docker Desktop is now part of all Docker subscriptions, including a new Business tier with added security, but enterprise users …
Any Agile team that wants its team’s culture to be squarely centered on improving software quality, should consider the following…
The EC2 Instance Connect feature enables users to securely connect instances, but there are certain pitfalls to avoid. Here are …
While it’s inevitable that certain cloud-hosted applications will share resources, the vulnerabilities these connections expose …
A poorly executed cloud resource tagging strategy, or having no strategy at all, can cost a bundle down the road. Build the best …
Here’s why Java is still the most popular programming language for everything from mobile development to enterprise and …
Are you prepared for a cloud-native migration? This quiz contrasts the microservice vs. monolithic approaches to software …
Do you need to loop through a collection of objects and need to decide between a Java Iterator or an Enumeration? Here’s why you …
All Rights Reserved, Copyright 2019 – 2021, TechTarget

Privacy Policy
Cookie Preferences
Do Not Sell My Personal Info

source