Modernizing applications often comes with the assumption that you need to move your processing off the IBM Z platform. This is attributed to the expectation that moving onto a distributed platform will lower costs. This article demonstrates two common modernization techniques in the industry that show the opposite—modernizing on the IBM Z platform results in a lower total cost.
The two uses cases that are covered include publishing data to a Kafka cluster and invoking a rules engine in Java. We demonstrate that not only do you get cost savings from staying on the IBM Z platform, you will get a simpler architecture and better quality of service.
For each use case, we have two scenarios: one where the processing is deployed on z/TPF, and another where the processing is offloaded to Linux® on IBM Z®. CPU utilization is measured for both systems as CPU is the primary cost driver in these use cases.
For all scenarios we are exploring, we are using a z/TPF system running on two cores of an IBM z15™ and a Linux on IBM Z system running on a single core of the same z15. The z/TPF system is running natively on dedicated processors while the Linux on IBM Z system is running as a z/VM guest, also on a dedicated processor.
Publishing Data to a Kafka Cluster
For the publishing data use case, the decision point is where to run the Kafka producer component. In both scenarios, the z/TPF application produces a JSON document, which is placed on the MQ queue that resides on the z/TPF system. The MQ queue is configured to not guarantee that messages are persisted.
For the z/TPF scenario, the Kafka producer is run on z/TPF using the Guaranteed Delivery for JVM support introduced with APAR PJ45923. For a visual, see Figure 1, below.
Figure 1
Figure 2
In this use case, because the Kafka Broker was located on the same physical machine as the z/TPF system, we did not use SSL in either scenario to encrypt the communications.
We ran multiple variations using an increasing message size from 1,000 bytes to 5,000 bytes to observe the effects of the message size on the relative utilization.
CPU utilization on z/TPF is categorized into general processor (GP) and transformation engine (TE) utilizations, with the TE utilization charged at a significantly discounted rate for modernization workloads. You can see in Figure 3 below, that even for very small message sizes (1kb) there was significant benefit to running the Kafka publish workload on z/TPF. While the Linux on IBM Z scenario showed a modest decrease in the TE utilization, the increased GP cost and Linux utilization far outweighs that minor difference.
In our second use case, the decision point is where to run the business rules engine. In both scenarios, we are using the “Drools” rule engine, configured to use 200 rules to calculate or modify the price of an airline ticket. The z/TPF application builds random inputs, then uses the tpf_srvcInvoke()
API to call the rules application.
For the z/TPF scenario, we are using the business engine running in a JVM on z/TPF. For a visual, see Figure 4, below.