In this article, you will learn about Microservices Design using the Gateway Pattern.
The gateway pattern or API gateway pattern is an integration pattern for clients communicating with your system services and acts as a single entry point between client apps and microservices. It is designed to provide a buffer between the underlying services and the client's needs. This single layer becomes the interface for the outside world into your system as a whole. It is similar to the Facade pattern from OOP design.
Let’s understand the problem of direct communication between the client app and microservices. Here, we have three services, and those services are directly interacting with the client applications.
In this scenario, the client has the ability to call directly to any services which can create chaos, and operational and maintenance costs will be significantly higher across the system, as we are allowing any client directly to use services as per their wish. This problem grows even more chaotic when the number of clients increases, especially if third-party vendors start consuming APIs.
Secondly, we need to have public IP for each microservice, and those IPs will be exposed publicly through the internet. As a result, we are providing more surfaces for attackers to attack.
Also, implementation of cross-cutting concerns such as authorization, data transformations, and dynamic request dispatching b/w client app and services can require significant development effort on each service. This means we'll have lots of duplicated code and code rework is required in case any modification. That is not a good practice in general.
Sometimes client apps need to call multiple services to implement certain functionality, which required multiple API calls. Multiple calls mean multiple network round trips between the client and the server which causes significant latency.
In addition, what if client apps communicate with a service that uses non-HTTP protocols like AMQP.
Why API Gateway useful in Microservices architecture?
To overcome the various shortcomings of direct client-to-microservice communication, we can design and introduce a middle proxy layer in between which can be called an API gateway. This could be something like another WebHost service running as a container in the middle.
API gateway acts like a reverse proxy that will receive the client request and redirect it to the microservice that the client apps want to connect to and when getaway receives a response back from that service, the API gateway will return that response to the web app or mobile app.
The reverse proxy solves the security problem, as we do not need to expose microservices IPs as public IPs over the internet. We will only expose the public IP of the API gateway, those microservices could live inside one shared network with private IPs, and that network could be secured.
The key API gateway features and functionality include:
- Can mutate the calls, or it can limit the calls based on what the gateway itself exposes.
- Can put security and authorization logic in a single integration point.
- Can restrict or allow request access based on the client and its credentials.
- Can aggregate multiple HTTP requests into a single request that reduces the number of requests/roundtrips. Internally gateway makes the underlying calls to required services and assembles the data into a single payload for the client.
- Can also decorate payloads, sometimes, we need to have common headers or other data points in the payload that are not necessarily relevant to the underlying service. By using the gateway, we can apply that decoration in one place in a consistent way.
- Can achieve response caching and extracting all the crosscutting concerns of microservices and adding them to the API gateway.
- Enhances service discovery integration as API gateway could know the different endpoints through swagger API definition and we do not have to update the web app directly which results in less coupling between the web app and different services.
- Can implement load balancing inside the API gateway and they can define multiple policies for distributing the charge or the requests on top of the different instances of my microservice.
- Can perform logging, tracing, and correlation from each request.
The Implementation Approach
The detailed design is actually very straightforward. The gateway pattern gives you a contract-driven API point, they can be static while the underlying services can change, migrate, and move as needed. The gateway implementation may change, but your clients do not need to feel the pain of that change, because it adheres to your public contract.
First, we need to define APIs contracts and this will be the public touchpoint. Then, expose those APIs definition in the gateway component (For example - It could be done through uploading APIs Swagger JSON file).
In order to keep these API contracts static, we can have strict version control like semantic versioning to keep APIs growing. Of course, the versioning is not enough. We need to make our changes passive as well, based on that versioning strategy.
While implementing the API Gateway pattern, sometimes we need to split the API Gateway tier into multiple API Gateways based on the based on business boundaries and the multiple client apps. However, this is completely based on your requirement and business need. That is why splitting into multiple gateways based on the client app type referred to as "Backend for Frontend" (BFF) pattern. An example Illustration is shown below.
In terms of API Gateway products, we have multiple options available as a readymade solution that we can easily intergrade with our microservices. You can choose one of them based on your requirement and technology stack.
- Ambassador API Gateway
- Kong Gateway
- Apache APISIX
- Ocelot (.NET API Gateway)
- Amazon API Gateway
- Azure API Management
Challenges
One of the major challenges of API gateway is that we are creating a single point of failure for our entire application. If the API gateway will get down or if it crashes or does not work for any reason, then the entire application will not work even though microservices are live.
This can be addressed through scaling the API gateway, for example, you might have multiple instances of the API gateway if one instance gets down then the second and third instances will get the load instead of the first one.
Excellent! Now we have a clear understanding on the usefulness of the API Gateway pattern in Microservices architecture.
Hope you find this information useful! Happy Reading!