This blog is the 4th in a series on Cloud Pak for Integration licensing. If you missed them, catch up with Part 1: How CP4I Licensing Gives You Integration Superpowers (link-to-part-1), Part 2: Container Licensing Deep Dive (link-to-part-2), and Part 3: Designing for Resilience and Cost (link-to-part-3).
As your licensing pilot in this blog series, I’ve taken you through some of the key steps to metaphorically get your plane off the ground by understanding some of the core pieces of information you need to know. Now let’s look at some of the other important aspects. In flight terms we would be talking about the route to cover, and whether to fly based on speed vs efficiency, and it is similar in Integration deployments: the elegant, textbook path (purist architecture) or the smart, fuel-efficient one (pragmatic architecture). Or, as most customers discover, a thoughtful mix of both.
In container-based CP4I, the License Service counts every active pod at its cpu-limit, as well as the number of replicas. This can turn architecture decisions into licensing decisions. Get the balance right and you unlock another superpower: elegant, maintainable integrations that are also cost-aware.
While these decisions apply to many components within Cloud Pak for Integration, we will mostly be focusing in this blog on App Connect Enterprise deployments, as we typically get more questions about this, and the choice of deployment style is perhaps most impacted by purist/pragmatic decisions.
Purist vs Pragmatic – what do we actually mean?
• Purist architecture = one integration flow per container/pod. Maximum isolation, independent scaling, clean topology. Changes to any deployed pod or integration flow should have zero impact on any other flow.
• Pragmatic architecture = grouping multiple integration flows (configured and saved as BAR files) into fewer pods. You trade some isolation for fewer running pods and lower license consumption. Remember that you are not charged per integration or per flow, but by the cpu-limit of the deployed and active pod, and the number of pod replicas (if those replicas are active and counted as active by the license service). And these should be chosen by the maximum expected workload at any one time.
Both approaches are valid. The art is knowing when to choose one, when to choose the other, and when to blend them.
Many of these same discussions about pure vs. pragmatic architecture/deployments can also apply to deploying of not just App Connect but also products such as IBM MQ.
· Traditional MQ approaches would have seen multiple applications and supporting queues connected to a single Queue Manager. Changes to the Queue Manager would therefore impact multiple applications. Additionally, if any of the connected applications started ‘behaving badly’, then other applications would be impacted.
· A pure approach might see no more than a single application connected to a single queue manager, or potentially multiple instances of a queue manager connected to multiple instances of the same application.
· A more pragmatic approach would be again to group related applications together and connect them to the same queue, or perhaps a cluster of queue managers to handle scaled workload but where changes or upgrades can be scheduled all with the same application team.
· You can find more details about these approaches for messaging and MQ in the IBM Agile Integration Redbook – go to chapter 9 for the section on MQ.
A quick side note about integration flows and BAR files: You can have 1-n integration flows in a BAR file. You can have 1-m BAR files in a pod. These are not necessarily licensing based decisions, but as we will see in this blog, they can have a licensing impact, as the greater the number of individual pods (minimum of 0.1 cores per pod) the greater the likely total license revenue, so a decision can be made about whether to reduce the total number of pods deployed by increasing flows per BAR file, or the number of BAR files per pod.
The Purist Approach – maximum isolation and independence
Many teams start here because it feels clean and safe. Each integration runs in its own pod with its own BAR file in its own instance of App Connect.
Pros:
• True isolation. A change to one flow doesn’t risk others.
• Independent scaling. Each pod can have its own replica count and cpu-limit, selected by the expected workload, and scales dynamically.
• Easier testing and troubleshooting for updates, changes or new additions.
• You can have different pods with different versions of App Connect to test new versions side-by-side or to exploit new features quickly.
Cons:
• You can end up with a large number of pods, many of which may be idle (not processing work) but still counted by the License Service at their cpu-limit.
• Higher concurrent CP4I VPC consumption.
This approach shines when you have unrelated integrations or very high change velocity.
The Pragmatic Approach: grouping for efficiency
Here you deliberately put multiple integration flows into the same container/pod. You can do this by:
1. Adding multiple flows to a single BAR file.
2. Adding multiple BAR files to a single container.
3. Using a mixed approach (e.g., a common BAR file in every pod + specific flows).
Pros:
• Fewer pods running → lower overall cpu-limit count → lower CP4I VPC usage.
• Better resource utilisation.
• Simpler operational footprint.
Cons:
• More testing complexity (a change affects everything in the pod).
• Less isolation if one flow causes issues.
This approach is especially powerful for related flows that form a complete business workflow.
How to balance between pure and pragmatic: select thoughtful and considered trade-offs
Most successful deployments are neither purely purist nor completely pragmatic. Here are a few ways to strike the right balance.
• If grouping flows into a pod, group only related flows that belong to the same business process.
• Set cpu-limits and replica counts based on measured peak workload, not guesswork. You can always go in and change this later once you have more data, or even define schedules based on time-of-day, day-of-the-week, or monthly-peak-workloads.
• Use node capping (a powerful License Service feature) on nodes dedicated to a single program to cap charges at the worker-node size (we’ll explore node-capping more in a later post).
• Leverage ‘in-place pod vertical scaling’ (now available in OpenShift 4.20+) to adjust cpu-limits without restarts.
The goal is simple: design for the workload you actually have, not the workload you fear you might have. Adjust later as you understand workload patterns. Remember pods only last as long as you need them to exist. And licensing only counts pods deployed and active, while they are deployed and active. Once they are gone, they are gone and the license service will no longer track them.
Quick checklist: Which approach is right for you?
• Are your integrations highly independent or part of the same end-to-end workflow?
• How often do you change or update individual flows?
• Is isolation more important than minimizing total pod count?
• Have you measured real peak workload to set realistic cpu-limits and replicas?
• Are you using node capping or maybe other cost-optimization features where appropriate?
• Do you regularly review License Service reports to validate your assumptions?
• Is minimizing cost the priority? Or minimizing blast-radius of changes?
What should you take away?
The License Service doesn’t penalise good architecture. It rewards thoughtful trade-offs. You can have elegant topology and licensing efficiency. By understanding the pragmatic-vs-purist spectrum you turn architecture decisions into deliberate superpowers rather than accidental cost drivers.
This architecture and deployment choice is more than just a licensing cost decision. While evaluating the costs of different approaches is valid, some decisions will not be driven by costs. Having common integration flows such as for logging in some or all of your pods is not a cost reduction decision but a business and technology decision. Grouping together multiple integrations to deploy together because they reflect an end-to-end integration flow can reflect a considered management and scaling/resiliency choice. The decision is always yours, and the goal of this blog is to ensure you are aware of the choices and make them deliberately and with awareness of the implications.
Next up in the series: Tactics to Minimize License Costs. This blog will cover capacity-planning patterns that eliminate silent over-allocation and help you exploit the rules we’ve covered so far, including node-capping which is a critical tool that needs to be used carefully to extract value without introducing downsides.
As your pilot on this licensing journey, I’m here to help. If this has been useful, drop a comment below or reach out to me directly (or through your IBM or business partner representative). I’m always happy to review your specific architecture or record a short walkthrough video to help you gain those licensing superpowers and make the most of Cloud Pak for Integration.
While you’re here…
Don’t miss this new integration event:
June 25th 2026: What’s New in Cloud Pak for Integration 16.2.0: Register here to access the replay
As Cloud Pak for Integration 16.2.0 is now generally available (as of June 30th 2026) you can read the official IBM “What’s new” blog here.