WSO2 API MicroGateway deployment patterns
Introduction
WSO2 recently announced the latest version of it’s API Gateway which is API Microgateway 3.0. This release comes with a cloud-native, enterprise-grade, open-source API gateway along with full API lifecycle management capabilities. You can find more details about the WSO2 API Microgateway by referring the link below.
https://wso2.com/api-management/api-microgateway/
With this new microgateway, WSO2 allows enterprises to deploy API gateway with a whole new set of deployment patterns. In this article, I will be talking about a few possible deployment patterns with WSO2 API Microgateway. Though this article is focused on WSO2 API Microgateway, some patterns can be used independent of the same.
WSO2 API Manager components
WSO2 API Manager is designed in a composable manner where each functional module can be deployed independently. On top of this modularity, WSO2 API Microgateway comes with the ability to run fully isolated from all other components of the API Manager in a standalone (offline) mode. The main functional components of the WSO2 API Manager are
- API Gateway/ Microgateway — This is the API runtime which accepts the requests from API consumers and enforce security, rate limiting, throttling and caching while publishing analytics data to the analytics runtime. API Microgateway 3.0 comes with the ability to run in full isolation where it can validate tokens (JWT), enforce local throttling policies as well as collect analytics data in offline mode so that it does not need connectivity to any of the remaining components.
- API Publisher — This is the back office developer application where API developers create APIs and goes through the full API lifecycle management before it is published to the API gateway and the API store
- API Store — This is the developer portal of the API platform where developers can browse through the available APIs, try them out, give feedback and share with their peers. This is similar to Google play store or Apple app store
- Key Manager — This is the component which provides the authentication and authorization capability to the API platform by keeping and managing the tokens as well as validating the token requests coming through the gateway
- Traffic Manager — This component is used to enforce the throttling policies which are applied at several levels (API, Subscription, User, Token) within the gateway runtime.
- API Analytics — This component collect, analyze and generate reports out of the API related activities as well as KPIs related to business. It can also send real time notifications based on certain conditions related to API consumption.
Deployment patterns
Enterprises are moving towards agile, devops friendly, highly available, maintainable deployment architectures which can scale with the demand from the consumers. As an enterprise software architect, you need to decide on the best possible deployment architecture for a given situation. Here are some of the patterns which can be used to deploy WSO2 API Microgateway along with the other components of the WSO2 API Manager.
- Decentralized API Gateway
- Locked-down/Offline Gateway
- Seasonal API Gateway
- Multi-DC API Gateway
- Service Mesh sidecar Gateway
- Hybrid API Gateway
Decentralized API Gateway
With the adoption of microservices style of architecture within the enterprise, decentralized api gateway pattern fits in nicely. Instead of having a centralized api gateway layer, each microservice can be fronted with an api gateway. WSO2 API microgateway can be deployed as a service (in kubernetes) which will provide the authentication, throttling, analytics, rate limiting capabilities to each microservice.
As depicted in the above figure 1, In this deployment mode, api consumers can either use oauth2 tokens or jwt tokens. In the case of oauth2 tokens, microgateway will communicate with the key manager component. If there is a requirement to implement shared throttling across apis, microgateway will communicate with the external traffic manager. Analytics data will be published to the analytics runtime. In this deployment pattern, api publisher and store are deployed separately and will be exposed to api and application developers. These components will not have any interaction with microgateway components during the runtime.
Locked-down/Off-line API Gateway
Sometimes applications needs to be deployed in environment where there are no connection to the public internet or any other parts of the system. As an example, If you are deploying a system which is deployed in deep water under the sea, the system will be deployed in total isolation in a locked-down mode.
As depicted in the above figure 2, WSO2 API Microgateway has the ability to run in this type of environment with it’s built in security (JWT based), rate limiting (local) and offline-analytics capabilities. The applications and microservices will get the same set of capabilities from the API Microgateway, though there is no connection at all with the rest of the components of the API Manager. The Analytics data will be collected into files and will be uploaded to the analytics runtime when there is a connection established with that component.
With this deployment pattern, API development can be entirely automated and done through the API Microgateway toolkit. The APIs can be defined in Open API Specification (OAS) format with the WSO2 specific extensions in a json file and it can generate the microgateway. This entire process can be automated and implemented through a CI/CD pipeline.
Seasonal API Gateway
If you have already deployed WSO2 API Manager (all-in-one) in a centralized manner and you are happy with the setup, deploying that in a fully distributed manner would be an overkill. But the drawback of that approach is that, if your traffic fluctuates based on the seasons, scaling all the components would add additional complexity and will take more time than expected.
With the API Microgatway, you can quickly set up a seasonal gateway with a selected set of APIs and scale them up and down as necessary without impacting the existing deployment.
Multi Data Center API Gateway
Large enterprises which has global operations requires their applications to be as much closer to the user as possible. That will give their users a better experience when they search for a product or making a purchase order. Having multiple data centers across different geographical regions is a common approach taken by these multi national corporations. These data centers can be their own or on public cloud platforms like Amazon, Google or Microsoft. One of the key challenges of deploying an API Management platform across data centers is to share data across data centers. WSO2 API Microgateway solve this complexity with it’s unique immutable design and the ability to run without any other dependency.
As depicted in the above figure 4, the only component which shares data across data centers during the runtime is the analytics component which can connect to the other data centers in an offline manner. With the API microgateway, multi data center deployment has become much simpler and easier to implement and maintain. The above mentioned data centers can span across multiple cloud IaaS providers (Amazon, Google, Microsoft) as well.
Service Mesh Sidecar Gateway
If your enterprise is deeply integrated with microservices and wanted a fully fledged microservices implementation, service mesh is a pattern which you cannot ignore. Service mesh defines a network to communicate between microservices with a similar level of protection on top of them as external communications. Some might think this as an overkill but there are enough practical examples where people has implemented microservices with service meshes for better security, visibility and management of the overall microservices implementation. WSO2 API Microgateway can be used as a sidecar proxy in a service mesh kind of microservices architecture. It provides capabilities like authentication, rate limiting, circuit breaker, timeouts as well as monitoring.
In this deployment pattern, each microservice has an API Microgateway running alongside it in the same localhost. In kubernetes, both microservice and the API microgateway runs in the same pod (can be in different containers). All the communications across microservices will go through API microgateway for ingress and egress traffic. WSO2 API Manager analytics component can be used to analyze the interactions happening through the sidecar gateway.
Hybrid API Gateway
In all the deployment patterns mentioned above, the management aspect of the deployment needs to be handled by the enterprise. It gives them the utmost flexibility and control over the platform. But sometimes, organizations with limited IT staff and skill set wants to outsource some of the management and hosting capabilities of the platform while keeping the important components. This is what exactly the hybrid API gateway pattern provides.
In this deployment pattern, the critical runtime component of the API platform which is the gateway will be running under the control of the enterprise. It can be run on a private data center, public IaaS cloud or both. In the meantime, the management components of API publisher, Developer Portal, Analytics and Key manager will be hosted and maintained by WSO2 within their public API Cloud.
The original source of this content can be found in the following GitHub repository.
📝 Read this story later in Journal.
👩💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.
