2023 OWASP API Security Top 10 Best Practices
After four long years since the original…
If you work in the IT field long enough, you will see a new technology debut with functionality that looks like something you already have. You wonder, “Do I need this? Don’t I already have this? Why is everyone so excited about this new idea when it overlaps with an existing solution?” Vendor noisemaking can amplify the confusion, unfortunately.
The current dialogue comparing API gateways to service mesh falls into this category. The two technologies are distinct, but they are starting to converge. People are asking if they need a service mesh if they have an API gateway, among other questions. This article explores how API gateways and service meshes are similar, and how they differ, along with some thoughts on why you might want to use both.
To discuss API gateways vs. service meshes, it’s a good idea to start by differentiating the underlying technologies of APIs and microservices. Microservices, for which a service mesh handles communications, are analogous to APIs, up to a point. They’re not the same, however. To further complicate matters, microservices often get paired with an API to handle interactions with other software applications.
Briefly, then, an API is part of an application that interacts with other applications. Using an API, an app can invoke functionality, request and receive data, modify data, and more. A microservice, in contrast, is a software architectural style that serves to break up a larger application into components, referred to as “services.” An application built using services in this fashion is said to comprise a “microservice architecture.”
Thus, API and microservices have certain superficial similarities, but they are quite different from one another. As a result, the technologies that handle their management and communications—the API gateway and the service mesh, respectively—are also different.
An API gateway is software that sits in front of a group of application programming interfaces (APIs). It routes API calls (also known as API requests) to the appropriate API and manages the delivery of data and services from the API back to API consumers (also known as API clients).
The API gateway functions as a single point of entry for API calls. Think of it like a control center for API call/response traffic. It does not matter if the APIs are hosted on-premises, in the cloud, or at a separate corporate entity. API calls can similarly come to the API gateway from pretty much anywhere. API gateways are usually part of a broader API management and security solution that handles API discovery, API security, police enforcement, and the like. It can also balance traffic between API instances and handle failover and other issues related to API reliability and availability.
A service mesh is a technology pattern that takes the form of an infrastructure layer, or layers, that ride atop microservices. A service mesh handles communications between microservices. It routes messages back and forth, securing the data in the process. Working this way, a service mesh facilitates observability, reliability, and security for the microservices in the architecture. A microservices architecture needs a service mesh. Without one, it can be unwieldy to manage multiple microservices and ensure the kind of reliability and availability the microservices application needs.
If you’re paying attention, you might be starting to see how an API gateway and a service mesh are similar. They both handle requests and responses, routing data across networks. They can both take care of service discovery and policy enforcement for rate limiting, access controls, and the like. The differences emerge when comparing the details. A service mesh is meant to manage microservice-to-microservice interactions. An API gateway mostly manages traffic to and from API clients and APIs.
There’s a simplistic way to think about it, derided as wrong by some in the industry, but useful nevertheless: An API gateway handles “North/South” traffic, which comes from outside entities and into the network, and back. A service mesh handles “East/West” traffic, i.e., internal network traffic between internal microservices. It’s true some of the time, but not always. However, this comparison does capture an essential difference between API gateways and service meshes. Some key points of differentiation:
API gateways and service meshes both usually offer service discovery, which is the automatic detection of services—including APIs, microservices, devices, and data sources—on a network. Service discovery is an essential element of API management and service mesh operation. Without service discovery, it would be a cumbersome, manual task to figure out where all the APIs and microservices were located prior to using them. And, service discovery performs a vital function in identifying API and microservices that are no longer in use. Old APIs and microservices can be a source of risk exposure. Also, In a microservices architecture, resources change constantly (like containers spinning up/down) and the service mesh simplifies the continued connectivity.
The answer to the question, “Should I use both an API gateway and a service mesh?” may change as we head into the future. It’s likely that combined solutions will come on the market soon, offering API gateway with service mesh functionality. For now, though, it’s worth considering deploying both technologies.
The reason to go in this direction is that you will likely have APIs and microservices to manage in a modern enterprise. And, you probably have APIs exposing your microservices already, so you’ll need an API gateway to make them work securely and effectively.
Scalability is another reason to use both an API gateway and a service mesh. A service mesh improves connectivity between services, which enables greater scalability of microservices than is possible without the service mesh. API gateways, as a central point of contact for APIs and API clients, similarly facilitate scalability for APIs. If you’re anticipating growth in microservices and APIs, you’ll do well with both solutions.
Having both API gateways and service meshes at work in your enterprise can also make it easier for developers and architects to innovate. Being able to deploy APIs and API clients alongside microservices-based applications is a good formula for digital transformation. The two technologies working together make possible the kind of loosely coupled, flexible applications that drive transformation.
API gateways and service meshes have a number of things in common, but they are different technologies. API gateways are for APIs. Service meshes are for microservices. As your enterprise evolves, though, and takes advantage of opportunities for digital transformation through the use of APIs and microservices-based architectures, you might do well to deploy both.
Experience the speed, scale, and security that only Noname can provide. You’ll never look at APIs the same way again.