5 Top Technical Reasons to use WSO2 API Manager

Not Just a Gateway - WSO2 API Manager is more than an API gateway. It is a complete platform for API Management, which includes an API gateway, security, developer portal, publisher portal, API lifecycle management, analytics and much more. It has a very comprehensive feature list and you can read about the feature list here.

Cloud and On-premise Options - WSO2 API Manager is available has a public cloud offering from here. Or it can be downloaded and installed on premise with different deployment options. Your organization can take an iterative approach and start small and grow into a API centric organization in an iterative manner.

Flexible Deployment - This is one of the strongest reasons to go for WSO2 API Manager. It offers flexible deployment patters as each organization has different network, governance policies. You can start WSO2 API Manager in different modes (profiles) to act as a gateway, developer portal and publisher portal. You can deploy different profiles at different network zones (eg. DMZ) adhering to organization network and deployment policies.

Part of a Platform - As all WSO2 products, the API Manager is built on it's comprehensive platform. That means whenever additional functionalities are required one can extend into those areas such as security, integration, real-time analytics and mobile device management and they would work together seamlessly with near zero effort. So what if you don't want any more WSO2 products? No problem, just jump into the next point.

Openness, Modularity Extensibility - WSO2 API Manager is 100% open source and distributed under Apache License 2.0. It is built on open standards such as OAuth 2.0 and has all of it's functionalities available as APIs. It is modular and extensible allowing to plug into external Identity Providers. All of these leads to into zero vendor locking.

An Iterative Approach to Transform your API Strategy using WSO2 APIM

Iterative approach is the choice for most IT related projects today. In the same wary API management at your enterprise can follow an iterative approach that will eventually lead to digital transformation.

If you have no problem using Cloud services just get a demo account and you are on your journey. 

API management can be achieved within a few hours using WSO2 APIM. You can download the latest pack from http://wso2.com/api-management/, deploy and configure it to be production ready instance within a few hours. The deployment is as follows.

Pros
1 - The cost is for single instance and you will get 24*7 WSO2 production support
2 - Deployment is up and running within hours
3 - Minimum hardware/cloud infrastructure requirement (only one node)
4 - Suitable for starters

Cons
1 - No HA
2 - Not network friendly. Where are you going to run this instance? Not in DMZ as this need a database connectivity.
3 - The supported load really depends on your use-case

What if you want HA? This is the next level. You need  high availability. The system should be up and running 99.99%. Then you will need another node.

Pros
1 - The system is highly available
2 - The cost is for single instance and you will get 24*7 WSO2 production support
3 - Deployment is up and running within hours

Cons
1 - Not network friendly. Where are you going to run this instance? Not in DMZ as this need a database connectivity.
2 - The supported load really depends on your use-case

What if your load goes high? You can make the passive node as a traffic serving node. This means production subscription changes from 1 instance to 2 instances. 

Pros
1 - The system is highly available
2 - The cost is for two instance sand you will get 24*7 WSO2 production support
3 - Deployment is up and running within hours

Cons
1 - Not network friendly. Where are you going to run this instance? Not in DMZ as this need a database connectivity.
2 - The supported load really depends on your use-case


What if you want to support more TPS OR complex throttling OR adhere to standard network patterns, where the un-trusted connections are throttled out at the gateway itself. Then you need a distributed deployment where the deployment looks like below. This deployment allows different functional component of API management to scale differently - and these components scale at different proportions.

For this type of deployments you can get solution architecture help from the WSO2 team. This is an API empire that needs to be planned precisely. 

WSO2 ESB - Serving Multiple Modern Apps from a Slow Legacy System

The story of serving thousands of requests sent by multiple modern applications in the downstream from a system that serves only 2 requests per second, basically how to get more bang from the existing buck!


Scenario - Vehicle Licensing Department of the Liliput Kingdom is going through digital transformation. As a step in this process they are going to introduce multiple applications to their manual processes. The apps can include,

• Mobile app running on vehicle owner's devices to check their vehicle licenses
• Customer service web app to check status of vehicle licences
• EverGreen - a third party organization that check vehicle emissions. It needs to get details of the licenses and vehicles.
• The vehicle license printing service needs to be automated

All the vehicle license information in a mainframe(MF) and this MF has one method for listing all the vehicle licenses. Calls for this method cannot exceed 2 per second. The goals of the architecture,

• Implement a solution by retrieving records from MF
• Expose REST services for the mobile, webapps and third parties
• Expose a SOAP API that the printing service is capable of calling
• Calls to down stream must not exceed 2 calls per second
• Calls to MF should be done over CICS

This is the solution proposed for Liliput VLD is based on WSO2 ESB. It helped VLD to remove point to point connections and perform mediation, transformation in minimal time.

High lights of the architecture,

• Create an intermediate database between the MF and new system - let's call it IDB
• Periodically retrieve delta from the MF and update the IDB
• Expose the data in IDB as a REST service
• Integrate data using the ESB to create composite interfaces
• Expose all APIs over APIM to be consumed by applications. This provides throttling, security and API analytics

The Vehicle Licensing Department of Liliput Kingdom achieved digital transformation much faster and less cost, due to this architecture.