Microservices based architecture is the future of complex applications. In this blog, we will ponder upon one the critical components of this architecture – API Gateway.
Why someone would have thought of an API gateway?
Let’s start with why an API gateway is needed in the first place. There are multiple challenges that a microservices based architecture faces when it serves real world requests from external systems:
- One client source needs data from multiple APIs – A client application often needs to interact with multiple APIs to get the necessary information. For example in an ecommerce application – the product data may need to be called from multiple APIs. In such a scenario a moderator is ‘good to have’, as it aggregates all the microservices and delivers the aggregated response to the request
- Multiple clients need data from the APIs - The real world comprises of multiple types of clients requesting services. Not only that, multiple client networks need different type and granularity of information. As a simple example a desktop based interface displays more information and hence needs to access more APIs than say a mobile based application. So an API gateway is needed to make available relevant APIs to consumers
- Network performance of consumers can be very different – example server side web applications need data quicker than mobile network apps. The end user, irrespective of the facts that he/she is using web or mobile network must see similar performance
- Number of service instance & their locations keeps on changing. One will need additional hops to locate where the current service is residing now.
- Services use multiple web protocols – There are some protocols that are more suitable for communication between the microservices while there are others that are better suited for external networks. A translator will ensure that the all systems communicate in the most optimal protocols
- Security is another area that can get implemented in a microservices based architecture. The API gateway can implement the authentication & authorization server which can get the users authenticated and authorized
- Rate limiting & analytics services can be plugged into the API gateway
Argument against API gateway
The API is an overhead in the architecture in terms of costs – development, performance and maintenance
But API gateway adoption is a truth
Despite the arguments against them, API gateways continue to flourish in implementations. Almost all major providers are making available their gateways. Some examples are detailed below:
- Netflix API Gateway – Zuul proxy server or edge server– Open source and free to use
- AWS API gateway – Charges based on multiple factors like API calls, data transfer, caching etc.
- Oracle API gateway
- NGnix API gateway
And hundreds of other providers are crowding the seller market. The sellers are competing in pricing and sophisticated offerings.
The benefits outweigh the demerits
By deploying multiple instances of API gateways on different nodes, the SPOF (Single Point of Failure) challenge is overcome. Also the cost saved by an API gateway exceeds the overheads it introduces into the system. Hence an API gateway is here to stay.
Below are some of the key benefits of an API gateway in any deployment.
- Brings API access and SSO together ( enable social logins)
- Inculcates monitoring and reporting
- Adds audit trails
- Insulates the consumer from how microservices are partitioned and where they are residing
- Acts as a translator of protocols
- Optimizes network hops
