A Maximo Manage estate that runs everything in a single, default workload will run for a while, then start to behave badly under load. Slow logins coincide with the nightly integration window. A long-running report drags the user interface to a crawl. An escalation thread pins a pod and the next user who clicks Save waits twelve seconds. The fix is rarely a bigger pod. The fix, on MAS Manage, is to use server bundles the way IBM intended and to put each workload in its own pod with its own resource profile.
This piece sets out the practical pattern for splitting MAS Manage workloads across server bundles on OpenShift. It is aimed at architects and Manage administrators standing up new environments or hardening one that is already in production. It is opinionated about defaults that need to change.
What server bundles actually are
A server bundle in MAS Manage is a deployable workload type. The application can be deployed in one or more bundles, and each bundle is realised as a set of pods running WebSphere Liberty inside the Manage namespace on OpenShift. A bundle isolates a category of work, so that work does not contend for CPU, memory, or threads with other categories in the same JVM. Supported types include all, ui, mea, cron, report, and standalonejms, configured under serverBundles in the ManageWorkspace custom resource.
This is the architectural successor to the cluster pattern that classic Maximo administrators have used for over a decade on WebSphere: separate JVMs for UI, integration, cron, and reporting. The shape is the same, the mechanism is different.
The default deployment is a starting point, not a target
By default, MAS Manage deploys with a single all bundle. Everything runs there: user sessions, the integration framework, scheduled cron tasks, BIRT report generation, mobile traffic, and user sync from MAS Core. For a small estate with light integration and few reports, that is fine. For anything else it is a temporary configuration that should be replaced before the platform takes meaningful production load.
The reason is contention. Manage workloads have very different latency profiles. UI traffic needs short, predictable response times. Integration traffic is bursty and CPU-heavy. Cron tasks include long-running jobs that hold MBOs for minutes at a time. Report generation can pin a thread for the duration of a large run. Put them in the same JVM and one of them will eventually push the others into a degraded state.
A working bundle layout for production
The layout that holds up in production for most mid-to-large estates is broadly:
ui: interactive user sessions and Start Centers. Two or more replicas behind the OpenShift route, sized for peak concurrent users plus headroom. This is the bundle the load balancer points humans at.mea: the Maximo Integration Framework workload. Object structures, publish channels, enterprise services, REST and OData traffic. Sized for integration burst, not steady-state user load. Often set as theisUserSyncTargetso that user sync from MAS Core runs here, not on the UI bundle.cron: scheduled cron tasks. Single replica is the safe default unless a specific cron task supports parallel instances and you have configureddonotrunproperties accordingly. Sized for the worst-offending overnight job, not the average.report: BIRT report execution. Isolated so that a long ad hoc report never touches the UI experience.standalonejms: JMS queues, hosted in a dedicated bundle on MAS rather than co-located with the application server as they were in 7.6.1. Required when continuous queue-based integration is part of the design.allretained, if at all, only as an administrative fallback, with no traffic routed to it from the user load balancer.
Each bundle becomes a service and a route in the namespace, which means the load balancer in front of MAS can target them independently. That is what makes it possible to send users to ui and inbound integrations to mea, with no shared queue-of-doom in between.
Cron tasks deserve their own conversation
The single most common cause of “Manage feels slow” tickets, in our experience running managed MAS hosting, is cron tasks running in the same JVM as the user load. The pattern that works:
- Move every cron task to the
cronbundle by default. The supported way is to disable cron tasks on every bundle exceptcron, using thedonotrunproperty at the cron task instance level. - For cron tasks that genuinely scale horizontally (some integration consumers, some bulk processors), keep them isolated to the
cronormeabundle but allow more than one replica only after testing. Most cron tasks are not safe to run on multiple instances simultaneously. - Treat cron task definitions as configuration under change control, and promote them through Migration Manager like any other configuration.
A cron bundle that is doing its job is boring. It runs the schedule, the logs are clean, and nobody notices it exists.
Sizing each bundle to its workload
Server bundles only earn their keep if they are sized to their workload. The mistake is to set identical CPU and memory limits across all bundles because it is easier to manage. UI pods need fast warm-up and predictable response, which usually means more replicas at moderate size. The cron bundle is the opposite: a single replica with generous memory and a high CPU ceiling, because one heavy job at 02:00 is the workload it must handle. The MEA bundle sits between the two, sized for integration burst.
IBM’s MAS performance guidance is explicit: adjust CPU, memory and replica counts per bundle in the ManageWorkspace CR, do not rely on a single global resource block.
Two practical defaults that survive contact with production:
- Set CPU and memory requests equal to limits on the cron and MEA bundles, so the OpenShift scheduler places them on nodes that can actually carry the burst. Bursting into limit on a cron pod usually means a job that finished is now blocking the next one.
- Keep the UI bundle’s request well below its limit, so additional replicas pack onto worker nodes during the day, and scale the replica count rather than the per-pod size when concurrent users grow.
What goes wrong, and the patterns that prevent it
Three failure modes show up repeatedly on estates that have skipped this work.
Reports take down the UI. A user runs an unconstrained report on the work order table. The thread it occupies in the all bundle pins a CPU and memory grows. UI sessions on the same pod start to time out. The fix is not to limit reports, it is to put reports in their own bundle so the failure mode is contained.
Integration backs up behind users. A vendor integration sends a batch of three thousand work order updates at 17:00. The MEA traffic queues behind UI traffic on the same JVM. Office users who are still logged in see latency spike, integration completes hours late, and the next morning the planners blame Maximo. Isolating MEA into its own bundle, sized for burst, removes the contention. The same logic applies to mobile traffic: the isMobileTarget setting on a bundle decides where mobile clients go, and a busy field workforce is its own integration profile.
Cron tasks running on every bundle. Cron tasks running in parallel on the UI and MEA bundles can corrupt their own outputs, lock MBOs against each other, and produce intermittent failures that are very hard to debug. Disabling cron task execution on every bundle except cron removes the entire failure class.
Closing position
Server bundles are not an advanced topic. They are the default architectural pattern for a MAS Manage deployment that needs to behave predictably under realistic load, and the configuration is a few hundred lines of YAML in the ManageWorkspace CR. The discipline is to design the bundles up front, size them for their actual workload, route traffic to them deliberately, and treat the layout as part of the platform under change control. Estates that do this run quietly. Estates that leave everything in all and tune their way out of every incident keep paying for the same lesson.