Understanding WSO2 API Manager Deployment patterns
WSO2 API Manager comes with a modularized architecture so that users can scale the components based on their needs. When scaling the WSO2 API manager deployments, it is essential to understand the interconnections between different components. As depicted in the below figure, WSO2 API Manager has 6 main components.
- Publisher — Creates and Publish APIs and manage API lifecycle
- Developer Portal (Store) — Discover APIs, Subscribe to APIs, Test APIs
- Gateway — Process the API requests. Traffic handling component
- Key Manager — Validate the authenticity of the requests (traffic) coming into the gateway
- Analytics — Provide analytics on API usability
- Traffic Manager — Provide throttling and rate limiting of API access
The interconnections of these components happen through database, user store(LDAP) sharing. The interconnections are depicted in the below figure.
As depicted in the above figure, once the API is created and published from the API publisher, meta data will be push into the registry database. From that, API developer portal will get the meta information and show them in the portal. In the meantime, API file will be deployed to API gateway through the web service (admin service) call from publisher to gateway. If there are any throttling policies attached to a given API, that information will be pushed to the traffic manager. User information will be shared through user management database as well as user store (LDAP). When an API user generates a token for his application, that information will be stored in the API management database which is shared across publisher, dev portal and key manager. When the application sends an API call to the gateway, it will call the key manager and validate the token using the API management database.
Those are basic information about the componentized architecture and how they interact with each other during an API creation, publishing, subscription and invocation process. When these components are distributed for scalability, these interconnections needs to be maintained using relevant database sharing options mentioned above.
WSO2 API Manager All-in-one deployment
This is the simplest deployment pattern which can be setup using the WSO2 API Manager and APIM Analytics components. This is suitable if you have a considerably low traffic requirements (<1000TPS) and need not to worry about scalability as such. The deployment would be 2 All-in-one nodes in active/active mode with one APIM analytics node.
If you are going with this approach, it is essential to deploy the load balancer in DMZ and put the APIM deployment within LAN as depicted above.
WSO2 API Manager partially distributed deployment
The next level of deployment pattern is to partially distribute the API manager components so that scaling and non-scaling profiles are separated. In WSO2 APIM, we have 3 major scaling components
- Gateway
- Key Manager
- Traffic Manager
Compared to Gateway and Key Manager, Traffic Manager scales at a low rate (10:1) and hence we can consider that as a non-scalable component. Due to that reason, If you need some kind of scalability while keeping the setup less-complex with less costly, you can use the partially distributed deployment mentioned in below figure.
In the above mentioned setup, Key Manager and Gateway components are installed in separate JVMs while Publisher, Store and Traffic Manager components are installed in the same JVM. If you need to further scale down this solution, you can think of keeping both Gateway and Key Manager nodes combined into one JVM so that you can further reduce the number of nodes by 2. But that is optional.
WSO2 API Manager fully distributed deployment
If users need the full control of the WSO2 API manager deployment with scalability, users can utilize the fully distributed deployment as depicted in the below figure. In this setup, all the components are deployed in separate JVM instances and based on the requirements, scaling profiles can scale up and scale down.
WSO2 API Manager Internal/External deployment
If your organization needs to separate out the internal and external API gateways, that can be achieved by using this deployment pattern. In this setup, there is only one API publisher which is publishing the APIs. There are separate gateways for handling internal and external traffic.
When publishing the APIs, users can select which gateways to be published the API and the store will only display the APIs relevant to specific tenants which are accessible from outside.
