We compare the benefits and drawbacks to 3 key API management styles

APIs are complex. Each component would be complex on its own, but when these APIs communicate with one another, this complexity is only compounded. Add in external clients, and you have an intricate web of cross-communicating codebases, competing paths for information, and separate sources of truth.

Accordingly, vendors have developed many solutions to help control these complexities. Some are highly effective, others less so. But of note, all attempt to solve the core problem of complex communications between disparate data layers.

Today, we’re going to look at three core solutions – the API Gateway, the API Microgateway, and the Service Mesh. Each of these solutions offers a unique approach and can be leveraged to great effect in specific scenarios and use cases. That being said, they are very particular in their applications – as well as their usefulness.

API Gateway

An API Gateway does exactly what it sounds like – it acts as a gateway between your APIs and external clients directly requesting services. Instead of a client sending a request directly to the services, the request is instead sent to a gateway, which then processes the request and forwards it along the appropriate route.

Nginx summarizes it plainly as such:

“An API gateway takes all API calls from clients, then routes them to the appropriate microservice with request routing, composition, and protocol translation. Typically it handles a request by invoking multiple microservices and aggregating the results, to determine the best path. It can translate between web protocols and web‑unfriendly protocols that are used internally…An ecommerce site might use an API gateway to provide mobile clients with an endpoint for retrieving all product details with a single request. It invokes various services, like product info and reviews, and combines the results.”

In essence, an API Gateway serves as a central interface for all external communications. This is especially important with microservices. In the microservice paradigm, the “service network” can be made up of a ridiculous amount of differently named microservices with different locations, properties, and methods – an API Gateway is meant to alleviate the weight that such a network can add to client interactions.

In practice, gateways can often support much more advanced functions than simple routing. Sophisticated authentication schemes (including federation and delegation) are often handled on the backend through a centrally managed gateway credential. Input validation and filtering typically occur at the gateway level, which can help alleviate the need for duplicate content checking code on each microservice element. Metric collection can occur at the gateway for comparative metrics. The gateway can even transform both requests and responses, as it functions as the first layer of the network that the request hits before it’s carried internally. In essence, a Gateway can take a wide variety of forms and functions and is ultimately a powerful first-line of interaction.

Benefits and Drawbacks

API Gateways offer simpler execution and interaction than other methodologies. In essence, the API Gateway is sort of an “API of APIs,” and as such, clients only really need to talk to a single endpoint. Everything else is internally handled and resolved by this single source of truth, meaning that the gateway can be focused upon when an error occurs.

Having a single transport hub and focus also means that the network of microservices at large typically boasts lower latencies, like input validation, load balancing, and other such systems don’t have to be replicated locally – everything is handled in a single spot by a single endpoint. This also means that limited and specific scopes can be employed to push data to other internal endpoints and systems by the gateway, improving the efficiency of the overall system pretty substantially.

When using a gateway, APIs can also take advantage of increased security. Because the only exposed endpoint is the gateway entrance point, the internal APIs are obfuscated and made unexplorable. While this is not a perfect method for security, it does make it harder for attackers to mount an effective expedition into your network architecture and structure.

A Gateway can also make an API more friendly within a wider collection of APIs. Because the interaction is ultimately far simpler, the collected APIs that are displayed to the end-user are necessarily less troubling to deal with, and as such, represents a significant increase in positive user experience.

Additionally, this approach delivers better metrics, as everything can be drilled down really well to a single source of failure. Problems can be effectively isolated to a single node, function, or transport system, and as such, they can be more effectively and quickly iterated upon and resolved.

This all adds complexity to the system, however – and this is a major drawback for gateways in general. While this approach does simplify already complex networks, simple single-endpoint APIs don’t have much complexity on the other side of the scale. In essence, without having a need to adopt a gateway, the gateway itself can become problematic.

API Microgateways

Monolithic gateways can do quite a bit, but in essence, they really have a single core function – they expose API endpoints to external clients. Microservice collections do more than just talk externally, though – they also talk internally quite verbosely, and as such, require facilitation for that communication process.

APIfriends defines it as such:

“One of the tenets of successful microservice strategy is the adherence to Conway’s Law which results in an organization where there are independent teams creating independent microservices. This brings challenges to operators and security personas who want a central control and governance for API traffic flowing within the organization. This is where an API microgateway is helpful.An API microgateway is a proxy which sits close to the microservice. As a result, it provides value to the developers by extracting governance, discovery, observability and stability in a reusable agent and gives value to the operators by exposing the Policy Enforcement Point (PEP) and Security Controls in a centralized control panel.”

This exposure, and specifically the control of exposure, can make catalogs of interrelated APIs more complicated, but ultimately present a much more granular approach than other solutions on offer. While a Gateway in principle is far simpler, it doesn’t offer a “ground level” view of the entire API ecosystem, which can lead to some obfuscation that is rather obstructive – utilizing a microgateway can alleviate some of this.

A related concept to API Gateways, API Microgateways are designed entirely for internal communication between services. In essence, a Microgateway is a lightweight, distributed API proxy that is designed to enforce policies and business logic at or near the service endpoints proper. It’s effectively an inner gateway paired with a microservice instance, ready to spin up and provide communication connections. They are by their very nature low latency, small footprint solutions.

Benefits and Drawbacks

API Microgateways boast lower latency than regular gateways, as there’s no need for a line of requests to “wait their turn” in the queue of gateway functionality. Of course, this comes with the caveat that, in some cases, this means that you will have code duplication across multiple microservice instances, which can be somewhat of a problem if the code is not efficient or does not offload functions to other endpoints.

That being said, if the code is properly developed to support intelligent structuring, then your overall footprint will be smaller. You may see code duplication, but the overall code needed will be significantly lower per instance, as there is no “monolithic gateway”. This process by its very nature abstracts much of the connection logic away from the system, though some of this connection logic is still required to drive interaction between the gateways internally.

Service Meshes

A Service Mesh is a layer of communication between microservices. In such a design, all service to service communication takes place on a service mesh that is designed to facilitate network communication using standard methodologies. This is akin to what is often termed a “sidecar proxy” or “sidecar gateway”.

Kasun Indrasiri noted the following key features of a service mesh:

“In a nutshell, a Service Mesh is an inter-service communication infrastructure. […] A given Microservice won’t directly communicate with the other microservices. Rather all service-to-service communications will take places on-top of a software component called service mesh (or side-car proxy).”

Service meshes include built-in support for network functions like resiliency, error checking, service discovery, etc. This approach allows developers to spend their time working on business logic, instead of having to work on network logic and processes. This also means that, since you’re using standardized network logic, Service Meshes are entirely language agnostic. In essence, a service mesh is much like a microgateway, but abstracted away from the business logic entirely.

Benefits

Service meshes are an interesting beast. In essence, they entirely abstract the network communications from the API business logic. In practice, they essentially serve as a network minder than also does request transferral. The same logic that derived from business logic endpoints to gateways is mirrored here, deriving from network logic to smaller gateways.

This does come with some concerns around duplicating code. While this is less of a concern since the network uses entirely standard methods, it can also result in a situation in which you have many mesh nodes that don’t do quite as much as a single gateway might. That being said, the gain of using standard methods is huge – the network is the network, and as such, the service mesh is entirely language agnostic by design.

The biggest gain here is the fact that adopting a service mesh allows for developers to focus on business logic without having to worry about the network – the network logic is a given, and does not need to be iterated upon, freeing up significant development resources for the core business offering.

Conclusion

Each of these implementations has a very good value proposition, but they are almost independent of each other – while they certainly cross some of the same territory at times, they are very particular in the problems they solve. Accordingly, they are most appropriate in a given situation – Gateway monoliths can be very effective, but can be overwhelming for simple implementations, for instance.

That being said, any of these solutions can be made to work, and are very effective at what they do. What do you think? Are there any major caveats we missed? Let us know below!