Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Understanding WSO2 API Manager Deployment Patterns

DZone's Guide to

Understanding WSO2 API Manager Deployment Patterns

Get a better understanding of WSO2 API Manager's modularized architecture and its different components when scaling WSO2 API Manager deployments.

Free Resource

The Integration Zone is brought to you in partnership with Cloud Elements. What's below the surface of an API integration? Download The Definitive Guide to API Integrations to start building an API strategy.

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.

apim-compo.png

  • 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.

APIMDeployment.png

As depicted in the above figure, once the API is created and published by the API publisher, metadata will be pushed 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 the 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 need 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.

api-dep-1.png

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 the 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.

full-distributed-apim-dep.png

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.

Your API is not enough. Learn why (and how) leading SaaS providers are turning their products into platforms with API integration in the ebook, Build Platforms, Not Products from Cloud Elements.

Topics:
wso2 ,wso2 api manager ,integration ,deployment

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}