WSO2 API Manager Microgateway — This is applicable for version 2.5.0(initial release) only
Important- please note that this article applicable for API Manager initial release 2.5.0 only. Please refer this article for more accurate details and comparison about API Manager microgateway 3.0.0 and later releases.
https://sanjeewamalalgoda.blogspot.com/2019/12/wso2-api-manager-microgateway-and.html
What is WSO2 API Manager Microgateway?
WSO2 API Manager Microgateway is lightweight message processor for APIs. On a very high level, microgateway used for message security, transport security, orchestration, routing, and other common API Management related quality of services. It can process incoming and outgoing messages while collecting information required for usage metering and throttling capabilities. And microgateway natively support scaling in highly decentralized environments including microservice architecture. In addition to that immutable, ephemeral microgateway fits microservice architecture verywell. Microgateway capable to operate in lockdown environments such as IoT devices, since connectivity to API Management system from microgateway is not mandatory unlike API gateway.
Setting up micro gateways closer to your backend servers and on premise deployments not only reduce network latency, but it also adds additional security as you can run it in fully control environment with selected set of APIs. You can run micro gateway in regional data center, same instance your service implementation runs or if need you can do same in your local workstation as well.
In summary microgateway is simplified lightweight version of API gateway. It also supports most of the API gateway capabilities such as authentication/authorization, usage data metering, throttling etc. However microgateway only supports subset of capabilities of API gateway.
Key Advantages of Microgateway
Fits microservice architecture : Characteristics if microgateway helps it to fit well in microservice architecture. Since microgateway have small startup delay and consumes less resources its native support container based deployments. When there is requirement to scale microgateway we can do that easily. Immutable, ephemeral gateways helps to build cloud-native API Management solutions and if we have simple and infinitely repeatable deployments which use continuous integration/delivery it would be much easier with microgateway. Also with these capabilities server and node failures do not result in your service going down.
Accelerate rapid development : Unlike full API gateway, users can easily run set of selected APIs in controlled environment within seconds in microgateway. As example if some developer need to do quick debug on API invocation flow, then he can simply setup microgateway in local workstation without doing full blown deployment.
Low resource consumption and efficient — Microgateway is capable to run with very low memory and CPU consumption. Its lightweight design allows microgateway to load minimum required components to process API calls.
Reduce network latency — Users can deploy microgateway closer to backend services as per requirement. If need microgateway can deploy in regional data center or same sub net where your services resides. With this you do not need to route your API calls through internet or different network segments.
No configurations — Users do not need to do specific configurations when starts microgateway unless you need to change default behavior. Also its very easy to install, run and manage microgateways.
Dev-opts friendly — No programming need to setup and manage microgateway and we can do it only using configurations or environment variable which can override configurations. Also if need we can easily integrate microgateway management with container management system and automate deployment process.
Enhanced Security — If your API consumer and producer both resides in same network or close proximity then there is no point of routing that traffic through cloud gateway. We can simply route that traffic through microgateway resides within same network. It will help us to reduce network latency. And also route traffic within the same network boundaries help us to address some security concerns and compliance with certain regulations.
API Microgateway 3.0.1 Feature Comparison with API Gateway
When to use microgateway,
- When we need to run gateway in lock-down environment or offline mode which do not have connection API Management system.
- Run set of selected APIs in in controlled environment such as private jet gateway mode. Specially when we see unusual traffic pattern on one API and need to scale it alone.
- Scale only set of selected APIs according to traffic patterns. Independently scalable set of APIs can run with microgateway.
- Internal or on premise API gateway deployment where we have consumers(delivery channels) and service instances resides within same network. In such cases having microgateway within close proximity to backend server will reduce latency.
- When there is a requirement to run gateway in sidecar mode along with application server within same runtime(or same pod in k8s world)
When to use API gateway.
- When there is requirement to throttle API calls based on counters across all gateway nodes.
- Run API gateway as centralized gateway which can handle requests for many different APIs and different backend servers.
- Traditional SOAP architecture which requires Gateway to perform mediations, orchestrations.
Dependency on API Management Core Runtime
From API Manager 2.5 release onward we will distribute API Microgateway toolkit which is responsible for microgateway related management tasks. It comes with command line tool which accepts commands issue by user. With this command line tool users will be able to communicate with API Management core runtime(API publisher) and build microgateway runtime. API Microgateway toolkit can communicate with API publisher to retrieve API metadata that required to create microgateway runtime.
API labeling concept allows API creators to add set of labels for APIs they create. Similar to tagging we can logically group APIs into different labels based on API characteristics. We can use different concepts for labeling APIs such as departments(as example we can think of HR, Finance, Engineering departments etc), privacy(internal, external, private), deployment locations(as example cloud, on-premise, hybrid) etc. API Microgateway toolkit designed in a way it can create microgateway per label basis. Usually when API gateway toolkit initiates label it will communicate with API core runtime and retrieve API data with specific label. Then create micro-gateway projects in provided workspace.
- Upon API Gateway CLI setup users are suppose to provide label name API Management core base URL, username and password. So with this information CLI can communicate with APIs exposed from API core. Then it will create project in workspace for given label and that will include all APIs under given label.
- And also it will create all throttling policies that we need for runtime. You can those policies under /src/policies directory of each project.
- Then when we issue build command it will build project and create single distribution that contains ballerina runtime with API definitions. Users can directly run this in their on premise deployment or local workstation.
- Then users can run generate microservice in any environment they preferred.
Hybrid API Management Deployment with Microgateway.
Most API Management solutions have some sort of API gateway within their component stack. And typically its acting as policy enforcement point and usage metering agent for API calls. Also it can add some other quality of services. If API Management solution offered as SaaS then typically this gateway running on cloud deployment and users can access that through internet.
Some organizations have strict security requirements due to internal policies and all API traffic management through the gateway must be done on-premise. Like discussed above there are some other advantages like reduced network latency also available with on premise deployments.
When we need to utilize capabilities of both these deployments we should go to some hybrid solution. Hybrid API Management is not a new thing for us at WSO2 and we keep supporting hybrid API Management for last few years. WSO2 solution to hybrid API Management is having centrally controlled API Management system while having set of on premise gateways.
What you need to know about APIs in Microgateway
API Manager Microgateway contain set of APIs retrieved from API Manager publisher. Also when we initialize microgateway it will retrieve some of the information which required to authenticate API calls. In addition to that when we initialize micro gateway we will generate required throttling policies and embed them to gateway project. So that means microgateway instance created will have all required information to process(authenticate, throttle requests etc) API calls. Microgateway toolkit capable to communicate with centrally deployed API Manager (publisher node) and retrieve all information required to bootstrap microgateway runtime.
API Microgateway and Analytics
When API traffic route through API gateway we will read incoming/outgoing messages and process them asynchronously to generate usage data. This asynchronous process allows gateway to process message without adding additional overhead to API invocation time. After extracting required information from messages they will publish to specific streams and eventually written to file system.
In gateway we do have configured periodic task to read these usage data files time to time and send them to central API Management system’s analytics node as compressed file stream. So analytics node can read these files and summarize them as usual. Then from that point onward analytics process have no difference in microgateway scenario and default synapse based gateway.
API Microgateway security
Role of Central API Management System.
Like discussed early API Microgateway toolkit need to communicate with API Manager runtime to retrieve all API metadata that need to bootstrap gateway runtime. And also API Manager runtime plays important role as its the one manage all client applications, access token management etc.
- Whenever user need to consume API which is deployed in microgateway, user will need to go to API store and subscribe to that API. Then same as usual process user need to generate access tokens or self contained token to invoke API. None of these user flows are different for microgateway as well.
- Since micro gateways do not have access to any persistence store or database it do not communicate with central API Management system via file access or direct database calls. Microgateway will communicate with central API Management system only via web service calls and later we will see how that communication happens.
Client app authentication
- Microgateway supports client authentication through OAuth 2.0 based access tokens and self contained tokens that end user can obtain.
- Self contained token will be validated within microgateway itself and it do not need to communicate with central API Management runtime. So if you are having requirement of offline gateway then self contained token is the ideal solution for that.
- But when user passed OAuth 2.0 based access token microgateway will communicate with central API Management system to validate access tokens. The main reason to perform above call is to retrieve additional information required to build authentication context within microgateway.
Can I move my existing APIs to Microgateway?
Yes you can do that. If you have any mediation, orchestration related logic with your API then you will have consider moving that to separate microservice or integration layer before move that API to microgateway. With that approach we will able to utilize microgateway as per its design. And also dynamic endpoints, endpoint security do not support by microgateway right now.