Capacity Planning for WSO2 based solutions

We have already discussed how a solution could be composed with WSO2 middle-ware products in a lego-block approach. If you have read my previous article—The "Lego Story" of Middleware—the next step to follow would be defining the deployment architecture and activities related to capacity plannning. Especially, if you work for a WSO2 partner or a System Integrator, this article would help you while trying to project and explain capacity and cost related matters to your customer.

The approach

1. Model the solution's architecture
   • L0 architecture
   • L1 architecture
2. Capacity requirements and nodes count of each component
3. Model the deployment architecture
4. Price for the JVM instances those actively contributing to serve the production traffic

Model the solution's architecture

• The expected solution has a few basic use-cases or a set of basic requirements to be addressed
• Components within the solution could be identified based on parameters such as
  • Domain or the purpose(security, analytic, mediation etc)
  • Internal or External (owned and managed by a third party)
  • New or Existing (legacy systems etc)
  • Access level (public or private etc)
• Based on these, the architecture of the solution could be modeled
• This is helpful in depicting how each component of the solution is used, for which purpose

The L0 architecture diagram below was taken form the previous article to use as the basic reference for this study.

With the knowledge of the components of the potential solution, it is neccessary to find which products could be utilized in building each component. The L1 architecture diagram below was also taken form the previous article co-relating to the L0 architecture diagram above.

If you need help with the initialisms/acronyms in this diagram, please do visit the official WSO2 website, where you could find the relevant products.

Capacity requirements and nodes count of each component

• Considering a component at a time...
• Considering factors such as,
  • Expected throughput (when applicable)
  • Expected concurrency (when applicable)
  • Message sizes
• Each component is constructed and scaled in the form of a product cluster

For example, let's assume that 1 instance of WSO2 X provides a throughput of α TPS(Transactions Per Second) for message with size β under γ concurrency. If the 'Mediation' component of the above solution demands a throughput of δ for the same message sizes and concurrency, the required node count (n) of this WSO2 X cluster can be calculated similar to,

n = ⌈ (δ+(δ*(30/100)))/α ⌉

Please note that a 30% of a tolerance has been added to the original δ value above: however, this is just an example and this particular calculation would not represent all the aspects that are considered in each and every case of capacity planning

Likewise, the minimum nodes or product instances count for each component cluster can be determined. Referring back to the previously described sample, let's assume that the capacity expectation on each components is very low; hence, one node each is sufficient for each component of this solution. Depending on the level of expected high-availability(HA), two basic deployment models could be proposed for the same solution

Model the deployment architecture

The factors that matter while determining the nodes count such as throughput and high-availability(HA), have been discussed in the previous article. Therefore, these diagrams that depict the deployment models for minimum possible capacity requirements shall be used just as a reference to study the concept.

Active-Active - Provides 99.99% of HA
Active-Passive - Provides 95% of HA

The above sample diagrams depict a very simpler version of possible deployment models. Any combination of Active-Active and Active-Passive clusters (of components) can be used, based on the mission critical nature of each component. Each cluster above is totally independent of others—therefore, each can be treated and scaled independently.

Pricing

WSO2 products are 100% free and Open-source. Hence, the pricing would mainly be applicable for the Production Support. In the context of pricing, a product instance of the above diagrams is called as a JVM instance. WSO2 Production Support pricing depends on the count of the Active JVM instances those actively serve the production traffic. Therefore—in the context of pricing—only the Active JVM instances will be considered. For example, if the production support price for an instance of WSO2 ESB is USD 10,000/-, an Active-Active deployment of a 2 node cluster would cost USD 20,000/-, while an Active-Passive deployment of the same would cost USD 10,000/-. Similarly, based on the required Active JVM instances count and based on the WSO2 Production Support pricing for each WSO2 Product, the total production support cost would be calculated.