Pre-Project Evaluation With WSO2 Products

Executive Summary

When your team starts pre-project evaluation work writing a project charter for a stakeholder pitch, there are certain elements that help you plan the project and determine the effectiveness of the project before moving forward with it. The potential cost is one of them.

At WSO2, we regularly meet people who contact us with new project ideas trying to check how they can use open source products during the pre-project evaluation stage as it could help them to continue with their work with freedom without having to make any commitments. Also, there are independent consultants who try to evaluate WSO2 products, capabilities, and subscription pricing as a part of their own documentation processes so that they could consider proposing WSO2 products for suitable projects with necessary details.

Similar to everything else related to WSO2, even the WSO2 price list is openly available for anyone to download. However, sometimes it can be difficult to understand how this price list information could be used to calculate the potential costs as it also requires some knowledge of WSO2 solution patterns and deployment patterns to determine what your end solution mostly will look like. This article will help you with that.

Introduction

WSO2 has different products. Based on the project requirements the products you choose and how you run them will be different in many combinations. Therefore, I intend to use one of the most common and complex examples so that I could discuss all the necessary details to cover the entire scope of knowledge.

WSO2 API Manager, being the most popular of all WSO2 products, comes with the most complex and distributed patterns depending on the scaling and redundancy related requirements. Therefore, I will be using a WSO2 API Manager based solution as an example. We will start with the most minimalistic deployment patters (which is the pattern that nearly 50% of the customers currently use) and look into how you could iteratively improve that by separating the product profiles into highly scalable, independently distributed clusters.

Let’s start with a quick introduction to the WSO2 API Manager product and its profiles.

WSO2 API Manager and Its Profiles

WSO2 API Manager consists of multiple profiles in terms of functionality.

Gateway

This provides access to APIs/services by routing API traffic to the relevant endpoints. The API Gateway enforces security, rate-limiting, and transformations on API requests while feeding information from these requests to API Analytics.

Key Manager

This is the profile that handles the tasks related to API security such as issuing access tokens, renewing tokens, authorize API requests, and integration with third-party identity providers.

Traffic Manager

This helps the API gateway to enforce traffic policies based on the quota and throttling limits. In addition to applying the available policies, it is possible to create custom policies on the traffic manager, to be enforced by the API gateway.

Store/ Developer Portal

A UI portal and/or a set of REST APIs for onboarding application creators. It allows application creators to discover, subscribe, test, and consume APIs through their applications.

Publisher

A UI portal and/or a set of REST APIs for API creators to design, implement, and document APIs and allow API product managers to manage API lifecycles and create API products by using one or more APIs.

Analytics

This monitors traffic routed through the API gateway to analyze usage patterns, SLA violations, and consumer behavior to provide business insights and other usage statistics.

When you download WSO2 API Manager binary pack and start it by running the ‘wso2server.sh’ shell script, it spins up a JVM instance with 5 functional profiles.

Or, we simplify this on our diagrams by having a single icon of a box that depicts the idea of encapsulation of more than one functional profile of WSO2 API Manager. Therefore, please note that these two versions represent more or less the same idea when you notice them later in this document.

Also, we will be using the following icons in this article to depict other WSO2 products and their profiles.

Integration

WSO2 Enterprise Integrator - Integration profile is a configuration-driven integration runtime based on the cloud-native variant of the battle-tested WSO2 Enterprise Integrator/Enterprise Service Bus runtime. This is used for general integration purposes such as services, messaging, and file integration.

Workflows

WSO2 Enterprise Integrator - Workflows profile is a runtime that hosts and executes BPEL and BPMN based business processes with the support on human-tasks.

WSO2 Streaming Integrator

WSO2 Streaming Integrator is a cloud-native, lightweight component that understands streaming SQL queries to capture, analyze, process, and act on events in real-time. This comes as a profile of WSO2 Enterprise Integrator 7x series.

WSO2 Identity Server

WSO2 Identity Server is an API-driven open source identity and access management (IAM) product designed to help you build effective CIAM solutions. It is based on open standards such as SAML, OAuth, and OIDC with the deployment options of on-premise, cloud, and hybrid. It supports complex IAM requirements given its high extensibility.

Also, when you find the jargon “node”, please understand that as a Virtual Machine or Container (i.e Docker) with a WSO2 JVM/Product instance running in it.

The Composition of API Management Solutions

Any given deployment of WSO2 API Manager consists of a few JVM instances of these profiles in different combinations. The number of JVM instances is decided based on either the expected Scale or the expected level of Availability of the runtime.

The most minimalistic installation of WSO2 API Manager that we recommend is 2 such JVM instances. This number is proposed considering the Availability factor, assuming that the required scale is below the capacity of the most minimalistic deployment.

However, let’s forget both ideas of Scalability and Availability for now so that we could understand the basics of implementing an API management solution with WSO2 API Manager and supportive products.

Please note that I do not include information about the actual solution architecture or integration architecture in relation to the example we use in this document. Here, I discuss mostly the deployment option of WSO2 products. That is because I intend to keep things more simple at the beginning so that even non-technical audiences could see the right level of detail that helps them.

WSO2 API Manager With Analytics

You can see 2 separate JVM instances of WSO2 products.

Figure 1

In this case, the Analytics profile (which comes as a separate runtime) runs on its own JVM environment while other profiles of WSO2 API Manager (which come in the same downloadable binary package) share the second JVM environment depicted in the diagram. This is a very simple deployment pattern which is, by the way, used by nearly 50% of WSO2 customers.

Separation of the Gateway

Depending on scaling-architecture, security-architecture, geographical or network-zone separation requirements, some customers choose to install separate Gateway environments. At the basic level, this can follow 2 patterns.

1. Installation of an additional Gateway environment
2. Moving the existing Gateway to its own JVM

Installation of an Additional Gateway Environment

Figure 2

In this case, you can observe that there are 2 gateway environments. Additional to the existing gateway that shares the JVM α with the other 4 profiles, there is a separate JVM of API Gateway installed and configured.

Moving the Existing Gateway to Its Own JVM

Also, some customers choose to have a clear separation between the runtimes of Control Plane and Data Plane of the solution. In such cases, you can completely ignore the Gateway that shares the JVM α with the other 4 profiles.

Figure 3

Note the greyed-out Gateway of JVM ẟ in the diagram.

This deployment topology allows you to create many replicas of the Data Plane (API Gateway in the diagram) and distribute across different network-zones or geographical locations.

Figure 4

All the Gateway replicas will be controlled & managed by the same Control Plane (JVM ẟ & Analytics in the diagram).

Separation of Key Management

This can be performed in 2 methods.

1. Move the Key Manager to its own JVM
2. Replace Key Manager with WSO2 Identity Server

Move the Key Manager to its own JVM

In this case, what we have to do is install a separate instance of WSO2 API Manager, configure it as Key Manager and run it in Key-Manager profile mode on its own dedicated JVM environment.

Figure 5

Note the greyed-out Key Manager of JVM ẟ in the diagram. Similar to the Gateway in the earlier scenario, we ignore the key manager that shares the JVM ẟ with other profiles. Then this has been configured to redirect all the key-management requests to the newly installed Key Manager instance.

Even if the Key Manager doesn’t require scaling up at the same ration as the gateway, this deployment topology allows you to scale it independently if/when it requires to do so.

Replace Key Manager with WSO2 Identity Server

The Key Manager profile of WSO2 API Manager provides most of the API security-related functionalities including identity federation with third-party identity providers as long as they support the standards such as SAML, ODIC, and OAuth. But there can be scenarios where you require more advanced capabilities in identity integration (e.g. User accounts provisioning, Strong Customer Authentication, Adaptive Authentication, Development of Connectors to IAM solutions with proprietary standards). This is one use-case of Replacing the Key Manager with WSO2 Identity Server.

Figure 6

“Key Management” in WSO2 Context is a subset of Identity Server functionalities too. It consists of the same feature module of the Key Manager of WSO2 API Manager. Therefore, WSO2 Identity Server can be used to replace the “Key Manager” while adding more advanced IAM capabilities to the solution.

Enhancements with WSO2 Enterprise Integrator

WSO2 Enterprise Integrator can be used mainly in 2 forms to enhance this solution.

1. Workflow engine (profile)
2. Integration profile

Figure 7

In the above diagram, you can observe WSO2 Enterprise Integrator workflows element in the Management & Control Plane. By installing this (WSO2 Enterprise Integrator Workflow profile), you can power up the API management solution with Approval workflows such as API Creation, Subscription Creation, and User Account Creation. When these workflows are engaged, the given actions remain in a staging state until an Admin user approves or rejects such actions.

Note: By the time this article was written the latest available version of WSO2 API Manager was 3.1.0. With version 3.2.0, WSO2 plans to include workflow support in WSO2 API Manager itself which may not require installing the WSO2 Enterprise Integrator workflow profile for this purpose.

The second usage of WSO2 Enterprise Integrator is performing advanced mediation/integration work that might be required when exposing APIs through the API Gateways. While the gateway itself is capable of performing mediation tasks such as reading/writing headers or content-type switching (JSON → XML), WSO2 advises customers not to use the gateway JVMs for heavy message processing tasks such as (XSLT like) message schema transformation, service chaining or orchestration and integration with non-HTTP backend systems. Instead, we advise customers to implement the API Facade pattern by having WSO2 EI (or any Integration platform or microservices, etc) behind the API Gateway JVMs to perform such heavy mediation tasks. If WSO2 Enterprise Integrator is used for this purpose, you can observe the pattern depicted in the above diagram (see Integration segment in the Data Plane).

Hardware Resource Allocation

Now you have an idea about the nature and the number of WSO2 JVMs we discuss here. Each rounded square/rectangle in our diagram represents a WSO2 JVM instance.

Figure 7.1

For example, you see 10 of WSO2 JVM instances here altogether.

WSO2 recommends installing each WSO2 JVM in its own Virtual Machine (VM) or Container with a standard hardware specification. For example:

1. 2~4 cores (vCPUs)
2. 4~8 GB RAM
3. 10 GB Free disk space in VMs/Containers at a given time

Since each WSO2 JVM is installed in its own VM/Container, let’s consider that each WSO2 JVM instance in the diagram is equal to a single VM/Container with the given hardware specification.

The version of this diagram that appears below shows the allocation of processing cores/vCPUs. The recommended minimum hardware specification consists of 2 cores in most cases. To understand the recommended minimum hardware requirements for each WSO2 product, please refer to the installation-prerequisites pages of official documentation.

WSO2 API Manager 3.1 Installation Prerequisites

WSO2 Enterprise Integrator Installation Prerequisites

WSO2 Integration Studio Installation Guide

Installing WSO2 Streaming Integrator in a Virtual Machine

WSO2 Identity Server Installation Prerequisites

With some products and profiles, we recommend allocating at least 4 cores depending on the nature of work those nodes are supposed to do (See on the top-left of each node. Each node has 2 cores except for the Analytics and WSO2 Identity Server nodes that have 4 cores each).

Figure 8

High Availability and Redundancy

Our example so far was a simplified version of WSO2 product deployment. But WSO2 highly recommends customers to install these nodes in clusters with at least 2 nodes each. Therefore, an actual production deployment should look like figure 9 below.

The distribution of the replica nodes can be either within the same data center or in a data center located in a different geographical location. WSO2 recommends having these Active replica nodes within the primary data center itself (high-availability within the data center) having another replica of the same in a disaster-recovery data center in a different geographical location.

Note: The disaster-recovery data center deployments are not counted under WSO2 subscription cost.¹

¹ Node = A Virtual Machine or Container with a WSO2 JVM instance running in it.

Figure 9

Pricing

How Pricing Works In WSO2 Subscription

WSO2 subscription cost for a deployment is calculated proportionally to the amount of work performed by the solution - which is measured by the number of processor cores allocated.

However, some of the nodes are ignored (or considered as free-of-charge) depending on the product/profile running in it. For example, the “Analytics” nodes, Passive nodes, and nodes that are installed in disaster recovery data centers are not counted in pricing. Please refer to the WSO2 pricing sheet in order to understand such exceptions in detail.

Core-Based Pricing Model

Let’s count the total number of processor cores in our reference/example deployment. This diagram only indicates the cores that are counted under subscription pricing.

Figure 10

This comes to a total of 34 cores.

1. 14 cores in the Management & Control Plane
2. 24 cores in the Data Plane
3. Analytics nodes are free of charge
4. Workflows nodes have been charged by only 50%

Exercise: Now refer to the WSO2 pricing sheet and calculate the annual subscription cost.

Once you come back after the calculation: This example is a significantly larger deployment than most of the actual deployments and it was constructed hypothetically for the purpose of explaining things in detail. Also, this has not considered other commercial offers such as discounts on WSO2 subscription.

Transactional Pricing Model

Depending on how different customers use WSO2 products and especially in complementing cloud-native deployments, WSO2 also provides a secondary pricing model targeting the Data Plane nodes. This is called the “Transactional Pricing Model”. (Please refer to the WSO2 pricing sheet to understand which products/profiles that this model only applies to.)

Under this model,

1. The customer can use any number of Data plane nodes (hence cores)
2. The cost for the Data plane nodes is based on the monthly transactional-volume2

The Management & Control Plane nodes will always follow the primary pricing model of WSO2, which is the “core-based” model we discussed earlier.²

² “Transactional-volume” is the number of API requests & integration requests served.

Figure 11

Note that we currently assess API calls (API Gateway) and incoming requests (Integration calls) as separate tiers. For example, 10M API calls + 10M integration requests is not at a 20M total tier. That’s a price tier segment of 10M API calls + price tier segment of 10M Integration requests.

Wrap Up

What Discussed So Far

Our example explained how the JVMs of WSO2 products and their profiles are typically deployed and how WSO2 subscription cost is calculated.

We have considered high-availability in the latter part of this study. We also have included a part related to geographical redundancy in relation to the Data Plane so that you could evaluate the possibilities/choices based on common deployment patterns. (see Region A, Region B, Region n).

We did not focus on “scaling” in this in order to keep this as simple as possible. When it comes to Scaling, however, it is the Data Plane that you have to consider in most cases as that is the part that is highly sensitive to the increase of API traffic and workload. WSO2 recommends horizontal scaling in general, which is adding more API Gateway nodes (and WSO2 Enterprise Integrator Integration nodes if any) to the existing clusters as the throughput demand increases (instead of vertical scaling, that is increasing the number of processor cores and RAM in the existing nodes). In most cases, the clusters of 2 nodes are sufficient as a cluster of 2 nodes handles nearly up to a peak of 2000 requests per second.

To perform these calculations, please request the performance test numbers of the products from WSO2 or send the expected capacity numbers and nature of the use cases to WSO2.

Next Steps

Note that our example study so far only covered a scope specific to API Management solutions. We chose that because we find the most complex deployment patterns and possibilities/choices with WSO2 API Manager compared to other WSO2 products. However, the products like WSO2 Enterprise Integrator or WSO2 Identity Server is used to implement different solutions instead of just complementing API management. For example, we can consider solutions that are purely built to address use cases of other domains such as Customer IAM (CIAM) and Integration platforms (File gateways, ESB, Complex Event Processing platforms). The other WSO2 products are independently used in these solutions.

You can use the same set of techniques when finding out what the final deployment would look like and how to calculate pricing for such solutions based on the core-allotments or transactional tiers (if/where applicable) presented in the WSO2 pricing sheet.

Take a look at the below-given deployment of an Integration Platform built using WSO2 Enterprise Integrator. Here, we have followed the segmented architecture when deploying groups of nodes based on the nature of the work they are supposed to do.

Figure 12

Unlike with the other profiles of WSO2 Enterprise Integrator, WSO2 recommends allocating 4 cores per node of the streaming integrator profile (in the Streams Integration segment of the diagram). This is the reason why 4 cores are indicated on each streaming integrator node. In summary, the subscription cost of this integration platform will be calculated by counting 18 cores.

Note: Also, we would mostly recommend increasing the RAM of EI nodes of the File Gateway segment as file processing usually consume more memory compared to normal applications/services integration scenarios (as file processing requires building document models in memory in most cases). But an increase in RAM does not impact WSO2 subscription cost.

Now you can start evaluating WSO2 products and find out what are the suitable deployment patterns that would address both your technical requirements and procurement related concerns. I believe that you will find this information helpful, especially during the pre-project evaluation to plan the project and determine the effectiveness of it.