API Microgateway
In the monolithic architecture API Gateways are mainly used to expose application services to external third-parties, partners, internal users, or systems, while handling security, rate limiting etc. But in microservice architecture (MSA), API gateway will have additional responsibilities than the monolithic architecture.
In MSA, multiple individual microservices are composed to handle a single application functionality by communicating via network calls. These calls are mainly API calls. If we don’t have a mechanism to govern these APIs it will lead to create unmanageable issues in the production deployment. To overcome these issues we can use API Gateway. Let’s look at API Gateway functionality in the MSA.
Role of API Gateway in MSA
Microservices are focused on small but specific business problems. Individual smaller teams are analyzing, developing, testing etc these services. While these teams focusing on smaller business problems, API Gateway can be used as enforcement point of API governance policies. Following are the key functionality of the API Gateway;
- Authentication and Security :
While microservices are mainly focusing on business logic, authentication and security can be implemented in the service level as well. But it will duplicate the functionality and increase the maintainability issues. One main benefit of MSA is the heterogeneous language support for service implementation. Having API Gateway will enforce to have standard authentication and security across the all microservices.
- Dynamic API Discovery and Routing :
Application are going through series of different life cycles stages. These life cycles can be different from organization to organization. Dev, test, staging and prod are very common lifecycle stages or sometime called as environments. In the development stage, developer need to discover other microservices for inter-communication. Addition to discovering, these inter-communication links should be work in different environment without altering anything. Dynamic discovery and dynamic routing should be a key functionality in API Gateway.
- API Rate Limiting :
Load handling capacity is different from microservice to microservice. Overloading few microservices might lead to an unresponsive application and recovery from this kind of situation is very hard. API gateway should be allowed requests that could be handled in each microservice and dropped requests that go over the limit.
- API Monitoring and Insights:
API Gateway can capture important facts like availability, response times, usage patterns etc. This data can be used to generate accurate insights which is the key to identifying the behavior of the microservice deployment.
- API Loadbance and Failover :
To make microservices highly available or scalable, we need to run two or more of the same microservices in a deployment. In such a case API Gateway can handle the load balancing or failover functionality.
- API Shaping :
API Gateway can optimize the API response depending on the nature of the API consumer. For example if the API consumer is a mobile device, we can stript down some content of the response to optimize bandwidth usage compared to a web consumer.
- API Composition :
Especially when we exposing API to external parties, we might need to aggregate multiple microservice responses and create a single composite API response. API Gateway will play a major role in these kind of edge compositions.
- API Mediation and Transformation :
The same microservice may need to support new microservice consumers as well as legacy consumers. Mediation and message transformation in the API gateway will be very useful in such a situation.
- Response caching :
Response caching could be handy in some situations rather than expecting the backend to process each and every request. API Gateway will work in handy in this kind of requirements.
These API Gateway functionalities can be used in slightly different variations based on the deployment pattern chosen.
API Gateway Deployment Patterns in MSA
In the MSA, API governance can be achieved via 3 main API Gateway deployment patterns.
- Centralize API Gateway
- Private Jet API Gateway
- Sidecar API Gateway
Centralize API Gateway
Centralized API Gateway is the well established and popular deployment pattern. Shared cluster of API Gateways will handle all API requests. These requests can be internal as well as external API calls. API Gateway cluster can be scaled horizontally and the load will be distributed among all the API Gateway containers.
In this deployment, the API Gateway will be adding an additional hop into inter microservice communications. The same Gateway cluster can be used to manage external APIs as well as internal APIs. All mentioned API Gateway functionalities can be achieved with the centralized API deployment pattern.
Private Jet API Gateway
In this pattern each individual microservice will have a dedicated API Gateway. This will provide maximum security as well as guaranteed resource allocation for API execution. A single Private Jet API Gateway can be attached to a cluster of microservices of the same type. Load Balancing, failover features will be necessary and naturally fit into this kind of scenario.
Private Jet API Gateway itself can scale independently. This pattern also increases one network hop in inter microservice communication like the centralized API Gateway.
Sidecar API Gateway
Hetrogeneos services are one of the key benefits in the microservice architecture. Microservices can be written in different languages depending on the benefits. In such a situation the sidecar deployment pattern can be used. The API Gateway can be attached as a sidecar to the microservice, which can then benefit from all the capabilities of the API gateway.
The Sidecar pattern will reduce the additional external network hops that were required in the centralized and private jet Gateway patterns while having the local network call to communicate.
Sidecar is heavily used in service mesh architectural pattern. Offloading all service to service communication matters like discovery, reliable delivery, routing, failover, load balancing etc into mesh sidecar will give freedom to developers to focus on business functionality.
Sidecar API gateway pattern can be used when and where you want to have service-mesh architecture.
Offline capability of API Gateway
Compared to monolithic architectures, MSA will add a significant amount of network calls. Each network call will end up adding latency to the final response. One way to optimize latency is to deploy self sufficient microservices. Traditional API Gateways fire multiple network calls to perform authentication and other security requirements. Based on some deployment pattern we need to have self sufficient API Gateway. Which means they should be able to operate in a fully network isolated environment. To achieve offline capability API-Key, Signed JWT can be used for API security. This mode is very useful in a Sidecar deployment pattern.
Why does the Gateway need to be Micro?
As microservices are designed to be micro, to derive the maximum benefits out of the API gateway, the API gateway too should be micro. Fat Monolithic API Gateways required significant amount of resources and scaling these Gateways are not easy. Private Jet API Gateway and Sidecar API Gateway pattern are not feasible with monolithic API Gateways.
WSO2 Cloud Native API Microgateway
WSO2 API-M introducing API Microgateway that is powered by Ballerina. WSO2 API Microgateway is architected ground bearing Cloud Native [1] in mind. Following are few cloud native characteristics of the WSO2 API Microgateway.
- Fast boot ( < 1 second)
- Smaller size ( < 50 MB)
- Low footprint ( < 100 MB)
- Immutabile
- Auto discovery
- Local cache
- Independant scalability
- Configurable through environment variable
If you like to know more detail of Cloud Native, please see my blog post “Redefining Cloud Native”
WSO2 API Microgateway support almost all the deployment patterns mentioned in the above section. It is 100% written by using Ballerina.
Ballerina is a general purpose, concurrent and strongly typed programming language with both textual and graphical syntaxes, optimized for integration. We can write our microservices by using Ballerina itself. In such a situation, we can embed microservice into WSO2 API Microgateway which brings the most optimal API Gateway functionality which can be achieved in MSA.
Summary
Still Microservice Architecture (MSA) is new and developers and architects are learning best practices the hardway. Microservices introduce many APIs. If we lose API governance we will end up in a deep hole which we can’t get out of. API Gateway has a very important role in MSA. Depending on the requirement and usage we can identify 3 main API Gateway deployment patterns in MSA. Cloud native API Microgateway is key to get real benefits from a real MSA deployment.