API Gateways…. How to use it properly
API gateway is a typical pattern that many API developers are using to encapsulate their API endpoints. But, it is common that many are using API gateway anti-patterns as well. This article focuses on the correct usage of the API Gateway pattern.
What is an API Gateway ?
An API(Application Programming Interface) Gateway is an interface where it sits in front of other back-end (Micro)services. API Gateway is the single-entry point for the back-end architecture where the communication channel normally ends in a database. API Gateway is ensuring architecture characteristics such as security, scalability, and high availability.
Can we implement our services (e.g., RESTFull or SOAP ) without using an API Gateway? Of course, we can. But the individual services need many non-business-specific functionalities such as Routing, authentication and authorization, TLS, Logging, and tracing, etc… Most importantly, if you do not use an API Gateway to expose your API endpoints, a client would know the back-end service distributions and deployment details. This is not a big issue if you are using your API endpoints to integrate with an internal front-end application. This is not a good practice for an Enterprise API Gateway, which can be exposed to unknown, on-demand clients.
Can we use a Reverse Proxy or a Load balancer as a Gateway?
If you are using your Gateway only to abstract a single back-end or just to terminate your TLS communication, Reverse proxy or Load balance would be sufficient. But, inherently, a proper API Gateway would fulfill the following functionalities.
- Multiple Back-ends ( Microservices )
- Service Discovery
- Circuit breaking
- Authentication and Authorization
- Rate limiting
- Logging and tracing
- Routing
- Retry logic etc..
Single API Gateway, Good or Bad?
If you deploy a single API Gateway, even though it is simple and easy to manage, you are asking for the following troubles.
Single point of failure: If your API Gateway stops functioning properly, your entire back-end communication will go down. This is a disastrous situation and should be avoided at all costs. As a solution, you can have a scalable API Gateway cluster behind a hardware load balancer where the load balancer can be notified of the backpressure.
Various traffic requirements would traverse through a single API Gateway stack: Depend on the various business functionalities, the API requirements are different in terms of performance, security, compliances, etc. If you do have a single API Gateway cluster, all traffic will traverse through that, and you won’t be able to cater to different needs as required. This is not a good idea, especially if you are building an Enterprise API Gateway.
Make your DevOps functionality difficult: If you do any routing change or protocol change in any of your back-end services, it will impact your API Gateway as well. Hence, once you deploy such a change, the API gateway also needs to get updated using a single cluster of API Gateway.
Hence, the best option would be to have multiple API Gateways, specifically designed to cater to specific needs.
We can identify two flavors of API Gateways as follows.
- Enterprise API Gateway
- Microservices API Gateway
The Enterprise API Gateways are mainly using for the API marketplace where you are expecting any 3rd party to come and use your API after paying for the usage. Most of the API integrations cater to this nature, and the following are the main concerns you need to focus on when developing an Enterprise API Gateway.
- A separate enterprise integration team would do deployment. A manual process of QA →Staging → UAT → Production would be used.
- DevOps pipelines would hardly be used in this kind of scenario.
- Error encapsulation(Custom errors) for clients.
- Need to monitor invocation rates and HTTPS status. Maybe your billing would depend on this.
- We need to focus more on security, data compliance, and standards, etc.
In Microservices, Gateway’s concerns are as follows.
- Using inside your ecosystem where the API Gateway is exposed only to your internal clients.
- High usage of CI/CD pipelines with deployments types such as Canary, Shadow, Blue-Green, etc.
- The API may expose full details of errors along with the stack trace.
- Non-functional requirements such as latency and performance would be considered over enterprise-level constraints such as standards, compliance, security, etc.
API Gateway Anti-patterns
Following can be identified as the API Gateway Anti-patterns.
- Overburning the Gateway by routing most of the traffic through a single service.
- Not considering the scalability and resiliency factors of services that API Gateway is dependent upon ( Eg: Authentication, Service discovery. Routing, etc…) Failure of these services would affect directly to the API Gateway’s availability.
- Avoid using the API Gateway as ESB by rerouting internal traffic using the API Gateway. The API Gateway should route only the external incoming traffic to your service layer.
- Ensure a single point of failure is mitigated and managed.
- Let your API Gateways unmonitored and isolated.
What are the commercial and open source products that we can use.
Thats all folks ! Thanks for reading !
