API Gateway Vs API Microgateway
All of us are very familiar with cleaning our hands using soap/ hand-wash or hand sanitizer. For less complexity less consider soap (a piece of solid used washing purposes… not the SOAP protocol🙈)for the rest of the discussion.
On a Sunday morning assume that you are cleaning your cupboard and your hands got dirty. Since your hands weren’t visibly dirty you prefer using hand sanitizer instead of soap. That’s perfectly okay.
On the same day evening, since you got bored, so you went and did gardening in your backyard. Your hands were all covered with soil, fertilizers and what not.
Now, will you prefer using hand sanitizer to clean your hand? No right? Since the hands were very unclean you obviously want to use soap and wash your hands.
Let’s take these 2 scenarios and analyze. In both situations, your hands got dirty but at different ratios, you were in a position to clean your hands, you had to use some product for cleaning, the time that was spent in cleaning varied and the level of cleanliness also varied. In a nutshell, these are the explanations for API Gateway and API Microgateway.
Let’s discuss these concepts separately for better understanding. Please note that I’ll be discussing WSO2 products such as APIM and its components in the rest of the blog to explain the topic.
Say API Gateway!
The term stands for itself… Gateway… Just like any other gate that we see in our day to day life, “Gateway” also allows certain things through itself. Now, what are these certain things mean? Well, an API Gateway allows API calls to reach their corresponding destination points also known as microservices in a system. Routing the API calls might be the core responsibility of an API Gateway, but it doesn’t stop there itself. It provides security, caching, load balancing, rate-limiting, dynamic discovery and routing, management and scales the API calls.
Think about the responsibility of a security guard at a university entrance. What is his job role? He should allow the students to enter into the university only upon a successful security check. The security check might be validating the student ID or getting the fingerprints.
This is what happens when an API call hits the API Gateway. In WSO2 APIM, when a subscriber access an API in the API store, an API call will be sent to the API gateway. The gateway validates the API call by sending the API call’s token to the Key Manager which will validate the token by searching it in the database that has been set at the backend. Upon a successful validity check of the API call, the gateway will route the API call to its corresponding microservice.
Be Practical…!!!
In a system that handles API calls will not have the same use case all the time. Depending on the requirements the processes that take place on each of the API calls might differ. API Gateway provides an encapsulated way of capturing all these use cases and handles the API calls accordingly. Just for the explanation purposes, let’s assume a bank is using WSO2 APIM to handle all their transactions. Since the bank is handling thousands of transactions per second there will be huge traffic in the system network. To avoid this, the bank has come to the conclusion that if someone is trying to get the loan eligibility details from the system, no security checks should be done for those calls. Also if there is a transaction done at the customers’ end for more than Rs 100000.00 then there should be a very strict security mechanism to confirm the user and the transaction he/she intended to do.
In the above scenario, you can see that within the same system to handle two different use cases the system should have different approaches towards security. This is achieved through API Gateway. When an API call hits the gateway, the gateway captures certain important attributes from the call and depending on those values it decides whether to impose security check on it or not.
Even though the API Gateway provides various advantages, just like any other technology invention this too has disadvantages. The major disadvantage is that whenever a new microservice is added or modified in the backend, the API Gateway should be updated. This might involve a significant amount of time cost. These are like an overall idea oh what is an API Gateway, the functionalities, advantages, and disadvantages.
API Microgateway: Junior API Gateway
As I explained in the introduction API Microgateway is a customized version of the API Gateway. Let’s dive deep into API Gateway and explore some unknown facts about it.
What is API MG capable of?
WSO2 API MG is a lightweight (version of API Gateway)message processor for APIs, which implies that the API MG make necessary alterations to the messages and route them to the appropriate destination points. In a system, each microservice can have each API MG placed in front of them to manage the requests. It is capable of providing,
- Message security
- Transport security
- Routing - Directing the API calls to the corresponding microservices.
- Throttling - Setting a limit for successful API calls to hit the API MG in order to control the traffic
- Able to work in a lockdown environment - A “Lockdown” environment is a controlled or minimum privileged environment. For example, a system’s administrator limits the functionalities of clients in order to provide better security. Working in a lockdown system is possible for WSO2 API MG because the connectivity between APIM and API MG is not mandatory.
- Fitting the microservices architecture - The startup latency in API MG is very less and occurs only once. It consumes a very minimal amount of resources as well.
- Supports CD/CI - Due to this feature, the server and node failure will not affect the system to go down.
- All the other common API management related services
Having said all the above-mentioned advantages API MG still lacks in functionalities when compared to API Gateway. Therefore, it is not suitable to use in all circumstances.
Now let’s see when to use API Gateway and when to use API Microgateway.
API Gateway
- To throttle API calls based on counters across all Gateway nodes depending on the requirements
- To have a centralized component to control the inbound and outbound API calls and to serve as the connector between multiple APIs and backends
- To mediate and orchestrate the flow when following a SOAP architecture
API Microgateway
- When there is no connectivity between the API gateway and the Key Manager, during an offline state of the system or in a lockdown environment, API MG is the most suitable option to use
- To run a set of selected APIs in an unusual traffic
- In internal or on-premise API Gateway deployments where consumers (delivery channels) and service instances reside within the same network. In such cases, having the Microgateway within close proximity to a backend server reduces latency.
- When there is a requirement to run a Gateway in sidecar mode along with an application server within the same runtime (or same pod in Kubernetes).
Summary!
So folks, in this blog we have seen what is a gateway and microgateway, the capabilities, the advantages, disadvantages, and the practical use cases for each of them. I hope that this has given you an overall idea of API gateway and microgateway. Please note that this blog is only to give an overall idea about the topic and this doesn't cover all the elements and points related to it. Happy learning… and see you all in another interesting topic…
Reference: WSO2 Documents
