Reasons to Use an API Gateway
Organizations are increasingly adopting microservices for the architectures inherent flexibility and scalability, but to fully realize the benefits of a microservices approach, you need an API gateway.
A microservice-based system can consist of dozens or even hundreds of individual services communicating with each other via APIs. While its possible for a client be that a web browser, application or IoT device to make requests to the relevant microservice directly, this approach has a number of disadvantages.
Direct client-to-microservice communication means exposing the APIs for each microservice. Developers wanting to interface with the system need to understand the network of services in order to identify the microservices they require. While this may be manageable for very simple applications, in many cases this will involve multiple requests to different microservices, some of which may not use web-friendly protocols. When changes are made to the system, such as combining or splitting services, consumers will be required to update their client-side requests. In addition, functionality such as API authentication, rate limiting and monitoring must be applied to each microservice, which will often require the logic to be implemented in multiple languages.
The alternative to direct client-to-microservice communication is to use an API gateway. A gateway acts as an abstraction layer for your microservices and provides a single point of entry for consumers of your application.
Why Use an API Gateway?
A key benefit of an API gateway is the abstraction of the backend microservices. An API gateway acts as a proxy for your application's microservices, exposing the public-facing API endpoints, routing incoming client requests to the relevant services, transforming them as required and aggregating the response data before sending the response to the client. An API gateway provides a clean interface for clients to interact with, making your system easier to use and therefore more attractive in a competitive marketplace.
Client Request Performance
Using a gateway also avoids overly chatty requests from clients. This is particularly relevant for remote client apps, where multiple roundtrips for requests can introduce high levels of latency and result in poorer performance. Being able to make a single request to an API gateway, which then routes the calls and collates the responses, is far more efficient.
Decoupling API Endpoints
Decoupling your system's public-facing API endpoints from the microservice architecture underneath allows you to make changes to the individual microservices without impacting the consumers of the public API. This consistency for consumers is not just important for existing microservice-based systems but also for organizations moving from a monolithic architecture to microservices. In the latter case, implementing an API gateway at the start of the migration process provides a consistent interface for clients to interact with while the architecture is broken down and re-built behind it.
As the single point of entry to your system, API gateways restrict access to your microservices from the outside world, reducing the potential attack surface compared to a direct client-to-microservice design. API gateways can be used to manage IP whitelists and blacklists and implement authentication and authorization. Not only does this ensure that only valid requests are allowed through, but it is also more efficient than implementing the logic in each microservice, which may mean replicating it for multiple languages and frameworks.
Load Balancing and Distribution
One of the many advantages of a microservice architecture is the ability to scale services independently according to load. An API gateway can provide load balancing to ensure even or weighted distribution of incoming requests across the available instances of a service.
Where high availability is required, load balancing can be combined with rate limiting and throttling to protect the system from unexpected spikes in traffic, including denial of service attacks. Implementing these features at the API gateway provides a central platform for managing this functionality. Again, this avoids the duplicate effort that would be involved in applying the functionality to individual microservices in multiple languages.
Best Practices When Using an API Gateway
As the interface that consumers of your system will interact with, an API gateway should be designed to meet their needs. If your system serves multiple types of clients, it may be appropriate to provide multiple API gateways based on those types. This design, known as backends for frontends, allows different endpoints to be exposed as well as different security and traffic management policies to be applied.
Being the single point of entry for your system does not mean an API gateway should become a bottleneck or a single point of failure. For applications requiring high availability, setting up a cluster of API gateways with requests load balanced across them ensures a more resilient system.
In order to protect your organization's assets, API gateways should be designed and configured with security in mind. This includes being mindful of what data is made available via public-facing endpoints and response headers, using secure communication channels, and implementing authentication, rate limiting and throttling.
API gateways provide a central platform for managing these cross-cutting concerns efficiently, ensuring a microservice architecture doesn't result in duplicated effort. With Kong Gateway, configuring your public-facing endpoints is simple. Kong Gateway includes support for high-availability clusters and includes an extensive range of plugins to address cross-cutting concerns, including authentication, security, rate limiting, throttling, transformations, analytics and monitoring.