What is an API Gateway?

API Gateways have become a critical component in the current Microservices based architectures, providing common functionalities required by APIs such as routing, API authentication, access control, rate limiting, billing, capturing analytics, monitoring and providing much needed decoupling between a client and the backend services. To understand further onto what an API gateway is, it is best to start from how it has evolved to exist.


There are two clearly identifiable categories of API gateways in the market;

  • Reverse proxy products that revolved into becoming API gateways, adding features to the core product eg. Nginx
  • API Manager vendors who broke their monolithic application into microservices which let one of those to be API gateway.


Starting from the first category is best to understand the initial requirements. Reverse proxies were already in the market, addressing the need of hiding the internal details of a system and providing an abstract interface for the external parties, interacting with the system. This made reverse proxy a central component which is commonly used by various backend services. Each of these backend services also has the requirements to monitor, secure, control access and limit consumption rates. This is when engineers started to explore how to move those functions to a central point, similar to reverse proxy, rather than implementing the same set of functions in each backend service, which is a repetitive effort without a gain. While this innovation is progressing API Management vendors also realized the need to embrace microservice architecture in their own architecture.


Monolithic API Managers provided both API lifecycle management and API gateway functionalities. From these two functions gateway responsibilities are the most critical and most demanding set of functions which has the scaling requirements. As all the backend service calls go through the API gateway it can easily become a bottleneck. Any negative impact from the gateway such as added latency, can escalate quickly, affecting a vast amount of services. So these vendors separated out the responsibilities to dedicated components making the API gateway an individually scalable entity. Finally, coming from either path, a conventional API gateway in the current market can be defined as below in the diagram.


API Gateway Overview


What API gateway is not?


As any technology, API gateway is also not a silver bullet. Ability to scale for high demands and minimum impact on service calls are critical features for an API gateway. When pushing responsibilities to the API gateway at system design phase, those core values need to be honoured, in order to enjoy the full benefits of using an API gateway and allocated infrastructure.

  • Not a mediator of heavy API payloads : If there are large payload conversion logics placed in the API gateway it will start consuming a considerable amount of memory and CPU causing delays to other services. When such heavy mediations are needed it’s best to delegate the task to a separate mediator component.

  • Not an API orchestrator : If there are transactional API calls to be made in a chained manner, API gateway may not be the ideal solution. Having to keep track of transactional states implies a need to become stateful which can negatively impact scalability of the gateway deployment.

  • Not a firefall : While the rate limiting functionality of API gateways can provide security against Distributed Denial of Service(DDoS) attacks, they are not firewalls. Unless the API gateway is providing special features for proactive security measures, those need to be calculated and addressed.


When applied correctly, API gateways can reduce a large amount of effort and drastically simplify the system designs, in the modern microservices based architectures.


Comments

Post a Comment

Popular posts from this blog

Sign into Dokuwiki with Google

Image
Dokuwiki(https://www.dokuwiki.org/dokuwiki) is a nice and helpful gift by the opensource community. Being a favor of administrators for ease maintenance and integration options, it caters the needs of a content management system or as a corporate or a personal note keeper. In this post I am sharing an approach we followed to keep this simplicity as it is, while making it available for an existing Google user-base via Single Sign On capabilities. We made use of the extend-ability of Dokuwiki via plugins and OAuth 2.0 protocol based integration provided by Google for this purpose. Let's look at the flow and then how this was configured.   Flow As in the diagram, when the user comes to the Dokuwiki login page, we want to show them the option of login via Google. With this feature available, if they are already logged into Google, they will be automatically logged into Dokuwiki with Single Sign On in action. If not, they will go through the Google login procedure at Google site, as usu
Read more

Single Sign On Integrations - Intro

Image
Single Sign on(SSO) is everywhere and provides lot of convenience to users. Let me give you few more examples. Have you noticed that when we are logged into our Gmail account and go to Youtube within the same browser, we are automatically logged into Youtube without any further requests for user credentials or authentication.  In today's cooperate world with COVID-19 impact, employees and partners heavily use cooperate applications such as Zoom, Salesforce, Jira in working from home efforts. Authenticating once and letting them securely use all these cooperate applications in another productive use of Single Sign On. In the Education sector also, COVID-19 impact has made the students and teachers to heavily depend on online tools. At such occasion also Single Sign On integration among these educational applications such as Moodle, Office365, Yammer etc, provide lot of convenience. User convenience is not the only benefit of Single Sign on though. It provides a lot more convenience
Read more

Shibboleth based SSO for SAP

Image
  This was a very interesting project I did with a customer from Israel. They had already selected Shibboleth as the IDP for the solution, where they wanted to login to SAP Hana Cockpit and provide Single Sign-On with variety of other web applications they have. Main reason behind selection of Shibboleth has been free use being a free and open source software. I did setup an OpenLDAP instance for the user base with an structure selected based on the hierarchy they wanted and integrated it with Shibboleth first. SAP Hana Cockpit platform was new to me, but they had good documentation and with little effort could figure out on SAML based authentication they supported. Then we did the integration with Shibboleth which made the scenario complete as follows. User comes to login to SAP Hana Cockpit platform via it’s link. User is redirected to Shibboleth and provided it’s login screen. (We branded it.) User enters credentials which were validated against the OpenLDAP . (We are to have SMS b
Read more