API gateway vs Microgateway (Microservices gateway)
Every person using a smart phone, laptop, tab or any other smart device is consuming thousand of APIs everyday without knowingly. As the number of services as well as the consumption of services grows, common entry point is needed for the services of your organization. This entry point allows the services to be consumed by the outside parties. So in a simple terms API gateway is a single entry point for your services where outside parties can consume your services exposed as APIs. Apart from being the interface to the outside world, API gateways provide many more functionalities that is required by all or most of the services exposed via the gateway. Authentication, authorization, transformations, rate limiting and providing business insights through analytics are most common QoS provide by gateways.
API Gateway and microgateway more or less provide the same functionalities. But the architecture and design of both gateways can be different and the underlying implementation of the same functionality is achieved via different technologies based on the design goals of each gateway. I will briefly do a comparison of the two gateways based on different criteria. And finally I will be doing a feature comparison of WSO2 Microgateway vs API Gateway.
Design and deployment comparison
- Architecture
API Gateways are designed to expose services designed for monolith architecture. Usually these services provides a complete end to end business capability. API gateways are used to expose number of monolith applications and their services. In most cases the particular organizations services are exposed via cluster of load balancing API gateways.
Microgateways are specifically designed for the microservices architecture. In microservices architecture managing a single gateway cluster to expose all the microservices would again causes the architecture to be pushed to monolith, since gateway layer can not be deployed, scaled and managed by teams developing microservices. The concept of microgateway comes with the idea of per API gateway. Idea is to provide the capability to the team managing the microservices to control how they are going to securely expose the services. Same developer team will manage and maintain their microservices and microgateways, so they can fix bugs, provide updates, perform improvements independently and quickly push the changes to the production with less interaction with other dependencies.
2. Scalability
Since API gateways are designed for monolith architecture, their design may require to connect with external third party legacy components. Legacy API gateways provides functionalities like security, rate limiting and analytics by having inevitable connections with external components like IDPs(Identity Providers), STS(Secure Token Services), Message brokers, streaming engines. Hence individually scaling the API gateways when scaling the services can be challenging, due to necessarily scaling required by external components.
Modern microgateways are designed to work alongside with the microservices. Hence the microgateway design can not have any necessary connections with external components. Having a necessary connection would pose a limitation when scaling the microgateway with the microservices to cater the high throughput requirements. Microgateways are designed in a way that it will have the capability to provide each QoS factors like security , rate limiting, transformations on its own. So microgateways will provide an additional QoS layer for microservices without having a necassary connection to external components. This will provide the ability to scale the microgateways horizontally without any limitation.
3. Centralized vs decentralized
API gateways are designed as centralized gateways where it can be hosted on premise or on cloud, that will expose all the APIs/services of a particular organization. A cluster of API gateways can act as a single entry point for your organisation’s business APIs.
Microgateways are designed as decentralized gateways. The idea of a centralized gateway contradicts with the microservices architecture(MSA) and will push back again to the issues which are to be solved by the MSA. Hence microgateways should be designed as decentralized gateways where it can holds a single API or few APIs. A load balancer or an ingress gateway can be fronted in order to route the traffic to respective microgateway.
4. Resource consumption
API gateways are legacy components which are heavyweight. API gateways can consume more memory, cpu and disk space compared to microgateways. Microgateways are lightweight processes which runs with the microservices consuming less memory, cpu and other hardware resources.
5. Network isolation
API gateways usually provides limited functionalities when used in a lockdown environments where external connections via network is not allowed. This is due to its design to connect with external parties in order to provide different QoS functionalities.
On the other hand microgateways will keep working without an issue in a complete network isolated environments (terminal devices, POS devices and etc) due to its nature to perform QoS factors on its own.
Security Comparison
API gateways are mostly used to control the inbound or the north south traffic of a deployment. Hence providing a strong security mechanisms are expected when exposing services via API gateways. Hence API gateways uses strong standard authentication and authorization techniques like OAuth2 , openID , role based access control with scopes. And also API gateways should also able to provide multi level security by combining different technologies. Some organizations may enforce to have Oauth2 and also require mutual ssl between the gateway and the client. Hence API gateway should provide two layers of security. Similarly mutual ssl and API key security mechanisms.
Microgateways are used to secure traffic among the microservices which is east west traffic as well as the inbound or the north south traffic as well. Hence based on the requirement microgateway should be able to support strong security mechanisms as well as less strong mechanisms in order to protect the east west traffic. Most of the time certain organizations may use self contained tokens, mutual ssl, basic auth or API key kind of security mechanisms to protect the the service to service communication. Since service to service communication is internal and not exposed to external networks, so organizations may consider it as an additional overhead to have a security mechanism like oauth2 or openID.
In certain cases microgateways can also be used to expose the microservices to the external parties in which it will be handling the north south traffic. In situations like this microgateways should be able to support the security mecahnisms like oauth2, openID connect and etc. When microgateways are used as an ingress gateways it should be able to handle the incoming traffic with one security mechnism and outgoing traffic with another security mechnism when connecting with internal microgateways which sits alongside with microservices.
Let me now briefly summarize the comparison of WSO2 API gateway vs WSO2 Microgateway based on the aspects discussed earlier. Please note that here the comparison will be done on API gateway version 3.0.0 and microgateway version 3.0.2
- Design Comparison
2. Security Comparison
3. Feature Comparison
There are plenty of cool new things happening with both WSO2 API Manager as well WSO2 Microgateway. So keep in touch.
If you are interested in what happening with these products please star our github repos microgateway and API Manager. And also join wso2-apim slack channel for all the latest updates and to clarify any of the question regarding these products.
