This blog is the 2^nd in a series of Cloud Pak for Integration licensing. Check out the 1^st entry in this series here. In continuing the series, I will stay in the pilot seat, and take you deeper into Cloud Pak for Integration licensing. This will help you unlock those superpowers that understanding licensing can give you as you plan your deployment.

Why do we use containers for software deployment? It’s not just because they are secure but because they are simple and repeatable. What happens once will happen every time. There are rules they follow, and they do it again and again within those rules. And deploying Cloud Pak for Integration in containers is exactly the same. But it is important to understand the licensing implications. By the end of this blog my goal is for you to not just understand how licensing works in containers, but to be comfortable and confident with how it works, and why, allowing you and your business to use it without fear or concern.

Summary of the licensing basics

First a quick refresher. You might have read other blogs from me on licensing, and certainly I suggest reading the 1^st in this series, but very quickly a summary:

·      This blog is focused on container licensing within IBM Cloud Pak for Integration

·      Container licensing in this case is core-based licensing and based on the peak (highest total) of concurrently deployed cores for chargeable programs running in a container (and more details later of what is measured for each deployed container with the program).

·      A container is deployed in a pod which has the required resources allocated to the pod (such as cpu and storage). There might be multiple containers in a pod, and licensing would be based on the containers.

·      Cloud Pak for Integration uses VPCs as tokens and a ratio table to allocate those VPC tokens to the deployed chargeable programs. Ratios are described in the documentation here.

·      Not everything deployed is chargeable. A list of chargeable and non-chargeable components can be found in the documentation here.

·      This blog is focused on the container licensing in Cloud Pak for Integration, but the license also allows you to deploy integration offerings into VMs.

·      We are not going into VM licensing explicitly here, but we do cover the similarities and differences between VM-based and container-based licensing. In the 1^st blog in the series, I described how Cloud Pak for Integration licensing allows deployment of both containers and VMs under the same CP4I VPC entitlement.

Details on container licensing for Cloud Pak for Integration

Core-based licensing, whether container or VM-based is licensed based on the amount of core-capacity available to the program.

·      If deployed into a VM, the customer must have entitlement to the size of the VM (in cores).

·      With container deployment, the program licensing is based on the cpu-limit setting for the pod/container where the program instance is running. This is very similar to VM-based capacity licensing. Let’s explain this in more detail.

CPU Request vs CPU Limit

When a container starts in OpenShift (or other Kubernetes), it is provided with a Pod specification that sets out explicitly what resources it is allowed to use:

·      CPU request

·      CPU limit

·      Memory

·      Storage and other environment variables

This information is supplied in YAML which might be represented and managed in a Helm chart, or in an Operator managed Custom Resource (CR – or Operand). When using an Operator, the Operator reads the information about resources in the Operand and creates the Pod according to these specs.

Key takeaway for licensing: the License Service only cares about the ‘cpu.limit’.

What does all that mean about containers and container licensing with regards to Cloud Pak for Integration?

·      The key information for licensing is probably best referred to as ‘cpu.limit’. This setting describes the maximum amount of cpu that the pod (where the container runs) can get access to, and hence how much the container can use.

·      For every chargeable container, this ‘cpu.limit’ setting tells the License Service how much cpu that container could potentially use to process workload, and this is what will need to be covered by the license entitlement. The actual amount of CPU that might be used at any time the pod is active could be zero.

·      There is another setting called ‘cpu.request’. This is used when Kubernetes is allocating the pod to a worker node in the cluster. It is used to set the minimum amount of cpu resource that must be available for the pod to be deployed, even though the pod might not actually need or use that amount. Licensing is not impacted by the ‘cpu.request’ setting, only by the ‘cpu.limit’ setting.

·      Containers (and pods) are best thought of as temporary and transient. You can start a container with specific resources (such as a low ‘cpu.limit’ setting), and then simply change it and the pod will restart with the new limit. There are even ways to change these settings without restart, but we will cover those later in the series.

For software that is charged on core-based licensing, container deployments charged on ‘cpu.limit’ is similar to VM-based deployments charged on the size of the VM. In both cases the licensing is based on the maximum number of cores available to the chargeable workload. It doesn’t matter if the workload is running at that maximum amount or not. It simply is charged at that potential maximum.

Fine-grained sizing for containers

One of the benefits of container licensing is that the size of a container (or pod) can be much smaller than a VM might be. Pods for ACE (App Connect Enterprise) can be as small as 0.1 cores. Pods for MQ might be as small as 0.5 cores. This means that the customer retains control over their potential costs by allocating the potential size of each pod where the containers are deployed. If the workload is not going to need to scale to the ‘cpu.limit’ setting, then by reducing the cpu.limit setting, the chargeable license total will be reduced. Later in this blog series we will also review options for ‘in-place pod resizing’ to allow ‘cpu.limit’ settings to be updated without pod restarts.

Horizontal vs vertical scaling for containers

In terms of licensing, there is another dimension to consider when thinking about total costs. For each pod instance, as well as scaling up to the cpu.limit, the customer will also likely have a number of pod replicas. If the cpu.limit setting is ‘vertical scaling’ for workload, then the number of replicas is ‘horizontal scaling’. The number of replicas can be either determined in advance and fixed, or autoscaling can be selected to allow for additional replicas (up to a limit) to be started as needed. The number of replicas can then be scaled back down by the autoscaling service once workload drops.

Putting licensing theory into practice with Cloud Pak for Integration

When planning an integration deployment, the total license entitlement can be determined in advance by understanding the total number of replicas of any container instance that could run at any time, and the size of those containers (based on cpu.limit).

The License Service runs every 5 minutes capturing:

·      the number of running pods at that moment

·      the cpu.limit for each pod

·      what is running in that pod (to determine the ratio needed to convert between cores and CP4I VPCs).

·      If a pod is not running, then it is not counted by the License Service.

Let’s imagine we have 6 different ACE containers (a, b, c, d, e and f) each of which solves a different integration requirement. We also have 3 different MQ containers (x, y and z) which hold different MQ Queue Managers. Each different container could have different CR specifications. So ‘ACE container b’ could be deployed with a cpu.limit size of 0.1 (and have 2 replicas). But there could be another ‘ACE container b’ where the CR states that the ‘cpu.limit’ is 0.4, and there can be 4 replicas. The same might go for ‘MQ container x’ with a ‘cpu.limit’ of 1 but a replica count of 3. This demonstrates there can be any number of pods deployed, at any time, with any combination of cpu usage.

The license service doesn’t care about the differences between the containers or what is running in them. It doesn’t care if it is the only instance of a pod, or one of 5 replicas. It is simply looking at the program name (to understand the ratio), and the ‘cpu.limit’ to count the size. And it will count the concurrently active containers, including active replicas, eventually providing a total for CP4I VPCs. Note that an active container is one which is ‘ready for work’. This means it has finished starting up, and registers for work. Until that point the License Service does not count it for licensing.

When I have been talking with customers about licensing, a lot of their confusion can be easily overcome through simply creating a table like this one above. Once you see the numbers come together, and work out the maths, you can understand more easily and indeed save costs simply.

Quick summary of what is counted:

·      Only concurrently running pods are counted.

·      Only the ‘cpu.limit’ of each pod is counted.

·      The name of the program in the pod tells the license service what ratio to apply to produce the CP4I VPC total.

·      Rounding up is ‘per program type’.

The table above illustrates the logic used based on a License Service snapshot for a total of 7 running pods.

·      2 pods for ACE production (cpu.limit of 0.5 cores each)

·      2 pods for ACE non-production (cpu.limit of 0.3 cores each)

·      1 pod for MQ Advanced production (cpu.limit of 4 cores)

·      2 pods for MQ Advanced non-production (cpu.limit of 2 cores)

The license service uses this information, and then applies the ratios

·      ACE production: 1 core (total) of ACE requires 3 CP4I VPCs

·      ACE non-production: 0.6 cores (total) of ACE requires 1 CP4I VPCs

·      MQ Advanced production: 4 cores of MQ Advanced requires 2 CP4I VPCs

·      MQ Advanced non-production: 4 cores (total) of MQ Advanced requires 1 CP4I VPCs

Within a cluster totals of the same program type get rounded up to the nearest whole number of CP4I VPCs. So, in the example above:

·      The 2 ACE non-production pods each total 0.45 CP4I VPCs, which together total 0.9 VPCs.

·      The total ACE non-production usage of CP4I VPCs for that cluster is rounded from 0.9 to 1, as all VPC totals for a specific program type (i.e. ACE non-prod) must be rounded up to the nearest whole number of VPCs.

The Custom Resource (Operand) will define whether a container is Production or Non-Production

·      Other key fields include the program name (such as App Connect Enterprise) which is essential for the License Service to know what is running in the container, and therefore how much to assign from a license cost.

·      The YAML in the Operand might also specify if the container is FREE, such as might be the case when some products are deployed for development use, according to their License Information.

What does this licensing example mean in practice?

Your licensing costs for container deployments are determined by the deployment choices you make.

Put yourself in control:

·      You set your pod ‘cpu.limits’ intentionally (don’t just accept defaults). But do make a note of the minimum amounts according to the documentation.

·      You set the replica counts (and autoscaling limits) to match your expected workload.

·      You can check the reports from the License Service to ensure no surprises.

By planning deployment size before you implement, you are now able to understand and manage your costs in advance of any licensing costs being counted.

Congratulations. You now are on your way to being a licensing superhero. The next step in our journey will be more about designing for resilience and cost, where we will look at strategies for HA/DR as well as more about scaling and exploring some of the choices you can make.

As your pilot on this journey, I will be here to help.

If you think this has been helpful, let me know. And if you want a 1-1 session, reach out to me directly or through your IBM or BP representative. I am always happy to help you gain your licensing superpowers and to help you make the most of Cloud Pak for Integration.

In the meantime, maybe you might be interested in attending a webinar: ‘Designing secure hybrid integration with IBM DataPower and Cloud Pak for Integration’ – register here.

https://ibm.webcasts.com/starthere.jsp?ei=1756211&tp_key=085340f727

Or if interested in events in-person we have the IBM Integration Platform Conference 2026 in Belgium in May https://www.ibm.com/events/reg/flow/ibm/1kdjfxmb/landing/page/landing

Another event would be the IBM EMEA Hursley Summit in June: https://www.ibm.com/events/reg/flow/ibm/0fzokemb/landing/page/landing

I would love to see you there.