An API Gateway is a reverse proxy that exposes microservices as APIs. As the name implies, it acts as a “gatekeeper” between clients and microservices, dealing with what is often called “north-south” traffic. Typical features of an API Gateway include the ability to authenticate requests, enforce security policies, load balance between backend services and throttle them if necessary. Organizations that employ API Gateways benefit from reduced complexity in their client and server code, a more manageable way to enforce access and impose limits, plus occasionally, a reduction in the overall network latency that would otherwise be required to satisfy client requests.
In our post, “2018 in Review: The Biggest Developments in Microservices, API Gateways, Kubernetes and Service Mesh,” we predicted that 2019 would see continued acceleration by organizations looking to “decouple everything.” As a result, API gateways should see stronger adoption as they move towards decoupling service implementation from product presentation. At Glasnostic, we believe that when an organization adopts an API gateway, it is often a leading indicator that the eventual destination for the organization is to have an environment of “connected applications” or, put another way, an “organic architecture.”
In this post, we will review the basic architecture and benefits of using an API Gateway to help manage north-south traffic, what it does (and doesn’t) and how it differs from a service mesh. Plus, we will also review some popular API Gateways.
The fundamental purpose of an API Gateway is to avoid exposing backend services and data sources to the outside world. Let’s say, for example, that we have a mobile e-commerce application with features like login, product search and reviews, a shopping cart and shipping notifications.
To deliver these features, our mobile app will need to interact with a variety of in-house data sources, as well as external services such as a payment processor. Depending on the frequency, payloads and the cost of opening and closing connections, your backend services and your network can quickly become overwhelmed if there is no middleware between clients and your data sources. Instead, the more secure, performant and manageable architecture would be one that makes use of an API Gateway and exposes the backend microservices as APIs to the clients.
An API Gateway provides an abstraction layer from which you can manage:
- Security-related tasks like SSL termination, whitelisting, firewalling, authentication and authorization.
- Performance related capabilities like throttling (or rate limiting), request aggregation, routing, load balancing and caching.
- Administrative tasks like logging, monitoring, metering and API versioning.
When client and backend services are decoupled, the client doesn’t need to know how the individual services have been decomposed. This decoupling makes it easier to maintain client code and to refactor services without one code base impacting the other. Also, with an API Gateway, developers don’t need to build logic into their apps to keep track of endpoints or how to handle request failures so that they don’t end up delivering a bad user experience.
A single operation from a client app might require calls to multiple backend services. For example, we might do a product search in our e-commerce app and as a result, it will return a list of products, the top review for that product, and how many are on hand. Without an API Gateway, instead of a single request, the client will need to make multiple network round trips to the backend services and in the process, add significant latency, particularly in the mobile world. Of course, high latency is directly related to bad user experiences. With an API Gateway, requests can be aggregated and routed efficiently to minimize the “chatter” required to deliver a completed request.
Without an API Gateway, each backend service has to make its own security-related decisions about each incoming client request. For developers, this adds complexity to the code required to deliver a service because they first have to determine if a request is authorized, if the communication is secure or if the client is issuing too many requests. For operators, more complicated code means more bugs, more maintenance windows and potential downtime, plus an increase in the overall attack surfaces available to bad actors. Instead, with an API Gateway, organizations have a centralized place from which to handle authentication, SSL, client rate limiting and other security-related policies for all their backend services.
The above is just a sample of the many API gateways that are available, including some highly specialized ones. Additional gateways include those offered by Microsoft, Akamai, Mulesoft/Salesforce, Dell Boomi, Google/Apigee and Bank of America Merrill Lynch.
Because the primary purpose of an API Gateway is to expose microservices as APIs, it won’t handle the communications and networking infrastructure between the microservices themselves, also known as “east-west” traffic. To manage this east-west traffic, smaller organizations with microservice-based architectures on Kubernetes will use a service mesh like Istio to manage service-to-service communications, while larger organizations running many connected applications as an “organic architecture”, will use an operational control plane such as Glasnostic to manage the large-scale communication issues that come with the territory.
Check out our “Should I Use a Service Mesh?” blog to learn more about the special problems organizations encounter when they adopt an organic architecture.
In summary, an API gateway is a reverse proxy that offers up microservices as APIs. An API gateway also helps to minimize the potential dangers of exposing backend services and data sources directly to clients. The use of an API gateway makes for cleaner and simpler client code, less latency, and more simplified authentication and encryption. There are a variety of open source and managed API gateways organizations can choose from, written in a variety of languages. However, we should remember that, although API Gateways can provide microservices with an API, security, performance and administrative features, they can’t offer intra-application observability or control of the networking or fault-tolerance characteristics of a given service. This is why many fully-realized microservice architectures that operate at scale have to make use of an API gateway as well as a control plane that performs interaction management and provides availability and observability capabilities.