Designing API Management Solutions with WSO2 API Manager: Everything You Need To Know
Need for API management solutions
The world is moving at a pace where connectivity is the future i.e. connecting multiple applications and sharing data across them. But when providing access to data for a third-party vendor to create an application we need to have an effective data source to share the data with certain authorities. APIs are used to achieve this.
API is a set of operations and protocols provided by service providers that allow developers to interact/access data without the hassle of sharing the entire code. Let’s assume a developer has to write a web application that is to be used internally within his organization to compare the features and prices offered by its competitors. He can do it easily by writing a code to retrieve the needed data from the competitor APIs and then compare them. This would certainly help businesses to achieve their goals and objectives. But this will be not reliable all the time since it can be subjected to inconsistent information access and to security vulnerabilities. To manage this need we need to have a powerful API management solution. This solution should cover aspects like API life cycle management and maintenance, security (API security, access control, rate limiting), performance, scalability, and monetization.
WSO2 API Manager
WSO2 API Manager is an open-source enterprise solution that addresses the full API life cycle management operations from designing and publishing APIs, creating and managing a developer community, securing and routing API traffic in a scalable way, and analytics in one cleanly integrated system.
Why WSO2 API Manager
- Open source, extensible and transparent
- Available as a cloud / SaaS solution and a single downloadable package
- It is a part of an integration platform so it can leverage those components to effectively manage and secure APIs. (Identity & Access Management, Enterprise Integrator)
- Provides flexible deployment choices — Single node (all-in-one), Hybrid API management, Fully distributed, Geo-distributed and clustered
- Governs APIs and provides a marketplace to publish the APIs to application developers/consumers
- Monitors the APIs closely and detects anomalies to provide business insights
Components of WSO2 API Manager
The WSO2 API Manager comprises the following high-level components:
- Gateway — Secures, protects, manages, and scales API calls. Intercepts API requests, applies policies such as throttling and security using handlers, and manages API statistics
- API Publisher — Design, create, and publish APIs, share documentation, provision API keys, and gather feedback on API features, quality, and usage.
- Developer Portal — Search/discover APIs and their functionality, subscribe to APIs, evaluate them and interact with API publishers.
- Traffic Manager — Regulates API traffic, makes APIs and applications available to consumers at different service levels, and processes throttling policies in real-time. Contains a dynamic throttling engine to process throttling policies in real-time, including rate-limiting of API requests.
- Key Manager — Manages all clients, security, and access token-related operations. Checks the validity of OAuth tokens, subscriptions, and API invocations. Provides a token API to generate OAuth tokens that can be accessed via the Gateway
- Analytics — Provides monitoring and analytics. Provides statistical graphs and an alerting mechanism on predetermined events when anomalies are detected.
Let’s get started :)
Let’s design API management solutions using WSO2 API Manager without ado by following the steps discussed below.
1. Design the high-level solution architecture diagram
If organizations require APIs to be used within their organizations among employees and partners, they would deploy such systems on their internal data centers. If they need to further scale-out (for high availability etc.), geographically distribute or for disaster recovery they can also reach to public cloud infrastructures. Organizations who are currently running their systems on public cloud infrastructures can continue to deploy the API management solutions on the same platform.
Regardless of the scenario the high level architecture of the solution will be designed by studying the business use case. This high level architecture diagram will demonstrate:
- systems involved (internal, external and third party vendors)
- integrations among these systems
- mediations used (transformations, routing, filtering etc.)
- messaging channels required
- handle security aspects using identity providers (identity and access management system)
- monitoring and analytics
and other aspects of the API management solution that is needed to expose and manage the APIs at different levels of the organization. This will ensure that all stakeholders involved in the project will have a thorough understanding of the high level requirements of the solution to help the business needs.
To understand the business use case when developing an API management solution the following information is gathered from the end user before designing the high level architecture:
- The expected deployment if it is on-premise, cloud or if it should be a hybrid deployment
- If high availability (HA) is a requirement for the deployment
- If the system will consume services from multiple systems (by invoking them directly or by producing integrated services)
- If the system will communicate with third-party systems such as Saleforce, Jira, Concur etc. using organization level API subscription
- If the system will expose their APIs externally for their partners and third-party application vendors to consume their business services
- The expected capacity (both average and peak) at a high level (Transactions per second/minute/day etc.)
- If there is a peak period for business transactions, if so the expected capacity during the peak time
- The message size of the expected payloads (in KB/MB)
- The number of APIs that are expected to be created
- The number of applications that are expected to be created
- The requirement to have an identity provider or if there’s an external identity provider that is already in use
- The expected security requirements (SSO, Identity federation etc) /standards (OAuth2, SAML etc).
- Scalability requirements in the future
- The required mediations/orchestrations and mediation types (transformations, routing, filtering etc.)
- Elaborate on the need to monitor and analyze API usage statistics to detect anomalies
- The expected number of users of the system and concurrent (active) users
- The number of environments required except for the production environment (development, testing, staging etc.)
- The requirement to have human-interaction based workflows that would require users to approve/reject tasks
After collecting the above information a high level solution architecture can be designed.
2. Design the detailed solution architecture diagram
After modelling the high level solution architecture diagram, the architects can design a detailed solution architecture diagram to visualize :
- actual interactions between systems (internal, external and third party)
- protocols and messaging channels to be used
- APIs and its resources to be defined
- systems that will be integrated to provide identity and access management and analytics capabilities
- information flow from internal networks to external networks and vice versa
- infrastructure required for each system and their geographical distribution (This will have a direct impact on the API latency and user experience depending on the latencies between data centers etc.)
For an example the integrations between systems can be implemented by following the standard Enterprise Integration Patterns (EIPs).
So this detailed solution architecture diagram will give you an in-depth overview about the API management solution by describing how the systems will interact with its users, external systems, data sources, and services i.e. the communication flow, protocols/channels that will be used etc.
3. Work out the capacity requirements
Another important part of designing an API management solution is to determine the throughput required by each component in API manager. The throughput is usually calculated by the number of transactions/requests that a component can handle per second (TPS)
API Gateway gets the highest number of requests since it will be intercepting all requests that are coming into the API manager. For each request that the API Gateway receives it will publish a statistics message to the Analytics Server and usage data will be published to the Traffic Manager.
Key Manager will only get requests from the API Gateway if the tokens pertaining to the request cannot be satisfied using the cache. Developer Portal will not get a high load if it is not exposed to a large number of application developers who would use the API management solution as a value added service. API Publisher Portal will hardly have a load since it will be only used by API developers and administrators to manage the APIs and API subscriptions.
WSO2 runs regular performance benchmark and long-running tests with actual use-cases to identify the throughput that can be handled by the API manager solution based on different message sizes, varying number of active users and back-end latencies. The latest test results carried out for WSO2 API Manager 2.6.0 can be found here.
According to these results when the API manager components are decomposed each component can perform better than the having them all together i.e. API Manager all in one deployment. Roughly one instance of API Gateway can handle 2242.12 TPS for a simple pass-through scenario (without mediations and back-end latencies) for 50 concurrent users with 10.24 KB of data in the payload. One instance of API Gateway can handle roughly 587.37 TPS for a mediation scenario (without back-end latencies) for 50 concurrent users with 10.24 KB of data in the payload. However the throughput can decrease when the message size increases, back-end latencies increase and depending on the complexity of the mediations used.
When working out capacity requirements it is always wise to note down the following:
- average and peak requests expected at a given time (TPS)
- back-end latency (delay added by the back-end services)
- message size of the payloads (request payload size)
- complexity of mediations used in the APIs (types of mediations i.e. transformations, routing, filtering etc.)
- number of users accessing the application at the same time (concurrent users)
These rough figures will be used to estimate the capacity needed at the initial phase of the solution. However before implementing an API management solution it is recommended to carry out a performance benchmark test with the actual use cases to identify the actual throughput figures that will be dealt in actual production deployments.
4. Select the suitable infrastructure
After doing capacity requirements planning i.e. after calculating the number of instances and cores needed to handle the incoming load, suitable infrastructure that will be used to deploy the solution should be selected.
WSO2 API Manager can be deployed on :
- any virtual machine based platforms
- Kubernetes, Docker, OpenShift, Ansible, Puppet, Vagrant
- DC/OS (Distributed Cloud Operating System) container cluster management platforms
Instructions for installing WSO2 API Manager on all of the mentioned infrastructures based on the deployment patterns discussed before are provided in the documentation.
5. Design the deployment architecture diagram
Based on the infrastructure selected design the deployment architecture diagram for your solution. You can deploy the solution on-premise, on cloud or do a hybrid deployment where some components will be deployed on-premise and others on cloud. This depends upon how you need to place your components of the solution according to the infrastructure selected.
WSO2 has defined 5 deployment patterns for WSO2 API Manager. These patterns are based on the following aspects:
- throughput required by each component i.e. capacity/load that can be handled by each component
- dynamic scalability of each component i.e. how easily the each component can be scaled independently
- internal and external API management
- hybrid cloud deployments
After modelling the solution architecture diagrams and working out the capacity requirements, the deployment architecture of the solution can be designed by taking into consideration the factors given above.
Deployment Options
WSO2 has defined 3 deployment options for WSO2 API Manager.
- On-premise — Self hosted and self managed by the end user. The end user has the flexibility to do any customization required. Upgrades and patches should be also managed by the end user.
- WSO2 Managed Cloud — Privately hosted but managed by WSO2. WSO2 will manage upgrades and patches and will ensure guaranteed up time. End user has the flexibility to do customization and better control over the solution.
- WSO2 API Cloud — Hosted and managed by WSO2. The cloud is multi tenanted and all resources are shared among the tenants. Provide support for hybrid API management. Since the cloud is hosted by WSO2 guaranteed up time. Limited options in customizing since the resources are shared among tenants. Available across multi regions.
Deployment Patterns in WSO2 API Manager
Pattern 1 : API Manager minimal deployment with high availability
- Simple all-in-one deployment with analytics
- 2 node deployment for high availability
- API artifacts will be synchronized across the 2 nodes with rsync
- Recommended if you are working with low throughput
- A shared volume would be needed to synchronize the API files and throttling policies among the 2 API manager instances
- Dynamically scaling the API manager and Analytics instances in this pattern will not be possible. So if you need to dynamically scale the instances based on demand you can go ahead with Pattern 2.
Pattern 2: Deployment with separate Gateway and separate Key Manager
- API Gateway and Key Manager have been taken out from the all-in-one instance and deployed separately for dynamic scalability. When the Gateway component is scaled, the Key Manager should also be scaled since it needs to handle the access token requests.
- Other components including Publisher, Developer Portal and Traffic Manager will run within the same instance (single JVM using 2 instances)
- Suitable for scenarios that require high throughput with a shorter token lifespan
- Based on the performance numbers the recommended ratio is to have 10 Gateways to 1 Traffic Manager (one Traffic Manager can handle the load of 10 Gateways, one Gateway handling the load of ~5000 TPS). If the Gateway count exceeds 10 instances, then you’ll have to manually scale the Analytics and Traffic Manager components else you can use Pattern 3.
Pattern 3: Fully distributed deployment with high availability
- Maintain scalability and higher flexibility at each component independently, so the performance numbers are superior than the all-in-one mode.
- Suitable for scenarios that require higher throughput at the API Gateway and UI components (Publisher and Developer Portal).
- API Gateway, Publisher, Developer Portal and Key Manager components can be dynamically scaled based on incoming request load.
- But the Analytics and Traffic Manager components should be manually scaled and their dependent components needs to be updated/scaled accordingly when required.
Pattern 4: Internal and external (on-premise) API Management
- Suitable for scenarios that require a separate internal and external API Management with separated Gateway instances.
- It is the same deployment as Pattern 2 but additionally 2 API Gateway instances are added. These additional Gateways are used to manage the external API traffic.
- Since there is a separation of internal and external API traffic, each API Gateway cluster will be able to handle more traffic and they can be dynamically scaled based on the demand.
Pattern 5: Hybrid API Management — Cloud / On-premise
- Suitable for scenarios where API management capabilities are required in both private and public cloud environments.
- The on-premise deployment can be designed using any of the deployment patterns according to the requirement of the solution.
- The public cloud API deployment can utilize the shared WSO2 API Cloud or they can have a dedicated deployment of WSO2 API Manager in the organization’s public cloud infrastructure.
- This type of deployment can be used if you need to utilize the public cloud as a Disaster Recovery option and to manage the separation of internal and external APIs.
Select a suitable deployment pattern for the solution from the patterns discussed above and place the components of the solution correctly.
Finally it’s done :)
After designing the deployment architecture diagram for the solution you have successfully designed an APIM solution using WSO2 API Manager. Now you can deliver this to the end user, and they can implement and deploy the solution accordingly in the infrastructures selected.
In summary designing API management solutions using WSO2 API Manager involves the steps discussed above:
- identify the business use case and requirements
- design the high level solution architecture diagram
- design the detailed solution architecture diagram
- plan capacity requirements i.e. calculate the number of instances needed according to the load
- select the suitable infrastructure that will be used to deploy the solution
- based on the infrastructure selected design the deployment architecture diagram
For more information, refer the following:
https://docs.wso2.com/display/AM260/Key+Concepts
https://docs.wso2.com/display/AM260/Deployment+Patterns
https://docs.wso2.com/display/AM260/WSO2+API-M+Performance+and+Capacity+Planning
Now as for how to end with a bang? Well, that’s another blog post for another time so stay tuned:) :)
