MAS 9 Architecture Deep Dive: Microservices, Containers, Operators, and OpenShift
Series: Modern Maximo - Transforming from Legacy 7.x to MAS 9, Cloud-Native, and AI-Driven EAM | Part 2 of 12
Read Time: 18-22 minutes
Who this is for: Maximo architects, system administrators, infrastructure engineers, and senior developers who need to understand the technical underpinnings of MAS 9 -- especially those planning or evaluating a migration from 7.6.x.
What this blog covers: The technical infrastructure layer of MAS 9 -- how OpenShift, containers, operators, and microservices work together to run Maximo. This is for architects, admins, and developers who need to understand what's happening "under the hood."
Introduction: From "Maximo on a Server" to "Maximo on a Platform"
In Blog 1, we discussed the developer mindset shift. Now let's dive into the technical reality: how MAS 9 is actually built, deployed, and operated.
If you're used to Maximo 7.6.x, the MAS architecture might feel alien at first:
- No more EAR files deployed to WebSphere
- No more database connection pools tuned in an XML file
- No more SSH access to tail logs
Instead, you're looking at:
- Dozens of containerized microservices
- Kubernetes operators managing lifecycle
- Declarative configuration in YAML files
- Horizontal pod autoscaling
- Service meshes and API gateways
This isn't just "Maximo in the cloud." It's a ground-up reimagining of how enterprise asset management software is architected.
The Legacy Architecture: How Maximo 7.6.x Worked
Before diving into MAS, let's acknowledge what we're leaving behind:
Classic 3-Tier Architecture
+-----------------------------------------------+
| PRESENTATION TIER |
| (Browser -> Single URL) |
+------------------------+----------------------+
|
v
+-----------------------------------------------+
| APPLICATION TIER |
| (The Monolith) |
| +-------------------------------+ |
| | WebSphere / JVM | |
| | [ Maximo.EAR File ] | |
| | (All Logic + State) | |
| +-------------------------------+ |
+------------------------+----------------------+
|
v
+-----------------------------------------------+
| DATA TIER |
| (The Vault) |
| ( DATABASE ) |
+-----------------------------------------------+Characteristics of 7.6.x
| Attribute | Description |
|---|---|
| Monolithic | One massive EAR file containing everything |
| Stateful | Session data stored in JVM memory |
| Vertically scaled | Need more performance? Add CPU/RAM to the server |
| Manually managed | Installs, patches, and restarts by administrators |
| Tightly coupled | Database schema, business logic, and UI deployed together |
| Long upgrade cycles | Major versions every 2-3 years with extensive testing |
Why This Worked (For Two Decades)
This architecture was proven, well-documented, and supported by deep expertise. Most importantly, it was predictable. You knew exactly where everything ran, how to troubleshoot it, and how to scale it.
But it had limits:
- Scaling required downtime
- Updates were risky and infrequent
- Resource utilization was inefficient
- Geographic distribution was complex
- Multi-tenancy was difficult
- Modern DevOps practices didn't fit
Key insight: The 7.6.x architecture was predictable and well-understood, but its monolithic design meant scaling required downtime, updates were risky, and modern DevOps practices simply did not fit. Understanding these limitations is essential to appreciating why MAS 9 was re-architected from the ground up.
The MAS 9 Architecture: Cloud-Native from the Ground Up
MAS 9 represents a fundamental redesign. Let's break it down layer by layer.
Layer 1: The Foundation -- Red Hat OpenShift
MAS runs on Red Hat OpenShift, which is enterprise Kubernetes with additional capabilities.
What OpenShift Provides:
| Capability | Description |
|---|---|
| Container orchestration | Schedules and manages containers across a cluster |
| Self-healing | Automatically restarts failed containers, replaces dying nodes |
| Load balancing | Distributes traffic across healthy pods |
| Service discovery | Applications find each other automatically |
| Storage orchestration | Dynamically provisions and attaches storage |
| Security | RBAC, security contexts, network policies |
| Monitoring and logging | Built-in observability stack |
Why This Matters for Maximo:
OpenShift handles all the infrastructure complexity that you used to manage manually:
- Server crashes? OpenShift recovers.
- Need more capacity? OpenShift scales.
- Security patch? OpenShift applies it across all nodes.
Layer 2: The Abstraction -- Containers and Pods
In Maximo 7.6.x, you deployed an EAR file to WebSphere. In MAS, you deploy containerized microservices.
Containers Explained (For Maximo People):
Think of a container as a lightweight, standalone package that includes:
- The Maximo component code
- All dependencies (Java runtime, libraries)
- Configuration
- Everything needed to run independently
Key Differences from Traditional VMs:
| VMs | Containers |
|---|---|
| Start in minutes | Start in seconds |
| Gigabytes in size | Megabytes in size |
| Full OS per instance | Share host OS kernel |
| Mutable (modify in place) | Immutable (replace, don't modify) |
Pods: The Atomic Unit
A pod is one or more containers that run together:
- Share network namespace (can talk via localhost)
- Share storage volumes
- Scheduled together on the same node
- Scale together
Example: The Maximo Manage UI pod includes:
- Main Maximo container
- Sidecar logging container
- Init container for database migration checks
Layer 3: The Intelligence -- Kubernetes Operators
This is where MAS gets powerful. Operators are like autonomous administrators that continuously manage MAS for you.
What Operators Do:
- Installation
- Read declarative configuration ("I want MAS Manage 9.0")
- Pull required container images
- Create pods, services, and storage
- Configure networking and security
- Verify health checks and report status
- Upgrades
- Orchestrate rolling updates
- Maintain availability during upgrade
- Roll back automatically if health checks fail
- Update configuration and secrets
- Scaling
- Monitor resource utilization
- Add or remove pods based on demand
- Rebalance workloads across nodes
- Healing
- Detect failed pods and restart them
- Detect unhealthy nodes and reschedule pods
- Maintain desired state continuously
- Day-2 Operations
- Backup and restore
- Certificate rotation
- Secret management
- Configuration updates
MAS-Specific Operators:
| Operator | Responsibility |
|---|---|
| Core operator | Manages the overall MAS platform |
| Manage operator | Handles Maximo Manage application |
| IoT operator | Manages Monitor, Health, and Predict |
| Additional operators | For Assist, Visual Inspection, etc. |
Time savings: Remember manually installing Maximo 7.6.x? Database schemas, middleware configuration, EAR deployment, integration framework setup? That 3-day process becomes a 90-minute operator-driven deployment in MAS.
Key insight: Operators are the game-changer in MAS. They transform what used to be a 3-day manual installation into a 90-minute automated deployment, and they continuously manage upgrades, scaling, and healing without human intervention. This is the single biggest operational improvement over 7.6.x.
Layer 4: The Architecture -- Microservices Decomposition
MAS decomposes the monolithic Maximo application into many specialized services.
Core MAS Services (Platform Level):
| Service | Function |
|---|---|
| Authentication service | User login, SSO, LDAP integration |
| User interface service | Admin console, workspace management |
| API gateway | Routes and secures API traffic |
| Event bus (Kafka) | Message backbone for async communication |
| Data lake (MongoDB) | Unstructured data storage |
| Licensing service | Entitlement and feature management |
| Certificate manager | TLS certificate lifecycle |
| Backup service | Automated backup orchestration |
Maximo Manage Services (Application Level):
| Service | Function |
|---|---|
| UI services | React-based modern interface |
| Integration services | API endpoints, webhooks |
| Application logic services | Business rules engine |
| Workflow engine | Automated process orchestration |
| Reporting services | Report generation and scheduling |
| Mobile services | Maximo Mobile backend |
| Search services | Elasticsearch-powered search |
| Cron services | Scheduled tasks and escalations |
| JMS services | Message queue processing |
Additional Applications (When Licensed):
- Maximo Health: Asset health scoring and analytics
- Maximo Predict: Predictive maintenance ML models
- Maximo Assist: AI-powered technician guidance
- Maximo Monitor: IoT sensor data processing
- Maximo Visual Inspection: Computer vision for inspections
Why Microservices Matter:
| Benefit | Description |
|---|---|
| Independent scaling | UI heavily used? Scale just the UI pods. |
| Independent updates | Update mobile service without touching core Manage. |
| Fault isolation | UI crashes don't bring down workflows. |
| Technology flexibility | Services use Java, Node.js, Python, or Go as needed. |
| Team alignment | Different teams can own different services. |
Layer 5: The Organization -- Tenants and Workspaces
MAS introduces multi-tenancy concepts that didn't exist in 7.6.x:
Tenant (Instance Level):
- Highest level of isolation
- Separate database schemas
- Independent authentication
- Dedicated resources
- Used in SaaS environments
Workspace (Organizational Unit):
- Logical grouping within a tenant
- Shared database
- Can have different applications enabled
- Common use: Development, Test, Production workspaces
Example Structure:
MAS Instance (Tenant: ACME Corp)
|
+-- Development Workspace
| +-- Maximo Manage
| +-- Maximo Mobile
|
+-- Test Workspace
| +-- Maximo Manage
| +-- Maximo Health
| +-- Maximo Predict
|
+-- Production Workspace
+-- Maximo Manage
+-- Maximo Health
+-- Maximo Predict
+-- Maximo Assist
+-- Maximo MobileComparing 7.6.x and MAS 9 Architectures
| Aspect | Maximo 7.6.x | MAS 9 |
|---|---|---|
| Deployment | Manual EAR deployment, config editing | Operator-driven, declarative YAML |
| Time to deploy | 3 days | 90 minutes |
| Scaling | Vertical (bigger server) or manual clustering | Horizontal pod autoscaling |
| Scaling downtime | Hours | Zero |
| Updates | Download fix packs, manual testing, scheduled downtime | Rolling updates, automatic rollback |
| Update frequency | Yearly | Quarterly |
| Recovery | Page the admin, diagnose, manually restart | Automatic pod restart, self-healing |
| MTTR | Hours | Minutes |
| Troubleshooting | SSH to server, tail SystemOut.log | Grafana dashboards, aggregated logs |
| Access needed | Root/admin | Read-only monitoring |
| Integration | Direct database, JDBC, triggers | REST APIs, GraphQL, event streams |
| Coupling | Tight | Loose |
Performance and Scaling in MAS 9
Horizontal Scaling (MAS 9)
Need more capacity? Add more pods.
Example:
- Baseline: 3 Maximo UI pods handling normal load
- Peak demand: Auto-scale to 10 pods
- Off-peak: Scale down to 2 pods
- No downtime, automatic load balancing
Vertical Scaling (7.6.x)
Need more capacity? Add CPU/RAM to the server.
Example:
- Baseline: 1 server with 32GB RAM
- Peak demand: Manual upgrade to 64GB RAM
- Requires: Downtime, hardware procurement, risk
Resource Efficiency
| Approach | Behavior |
|---|---|
| 7.6.x | One monolithic JVM uses all allocated resources whether needed or not |
| MAS 9 | Pods sized appropriately for their function. UI pods small, reporting pods larger. |
Typical improvement: 30-40% better resource utilization.
Key insight: Horizontal scaling in MAS 9 is not just about handling more load -- it fundamentally changes the economics of running Maximo. You pay for what you use, scale without downtime, and automatically shed capacity during off-peak hours. This alone can justify the migration for organizations with variable workloads.
Talking with Infrastructure Teams: Common Questions
Compute and Sizing
Q: "What's the compute footprint for MAS?"
A: Depends on applications and workload. Baseline MAS Manage requires ~96GB RAM and 32 vCPUs for small deployment. IBM provides sizing calculators.
Q: "How do we handle database connection pooling?"
A: Each microservice manages its own connection pool. The platform handles this automatically based on pod scaling.
Sessions and State
Q: "What about session persistence?"
A: MAS uses token-based authentication. Session state is externalized to Redis, not stored in-memory.
Backup and Recovery
Q: "How do we back up MAS?"
A: The MAS backup operator orchestrates backup of configuration, databases, and persistent volumes. It integrates with your existing backup infrastructure.
Q: "What about disaster recovery?"
A: MAS supports multi-site deployments with database replication. The operators manage application-level recovery.
Network and Security
Q: "What's the network topology?"
A: North-south traffic (users to MAS) goes through OpenShift ingress. East-west traffic (service-to-service) uses the internal service mesh. External integrations go through the API gateway.
Q: "How do we handle security scanning?"
A: Container images should be scanned in your registry. OpenShift includes security context constraints (SCCs) and pod security policies.
Common Architectural Misconceptions
Misconception 1: "MAS is just containerized 7.6.x"
>
Reality: MAS is a re-architected, microservices-based platform. The UI, business logic, and data layer have been redesigned.
Misconception 2: "We can still use our database integrations"
>
Reality: The database is sealed. All integrations must use APIs or event streams.
Misconception 3: "OpenShift is just fancy Kubernetes--we can use any Kubernetes"
>
Reality: While MAS technically runs on Kubernetes, IBM only supports Red Hat OpenShift. The operators rely on OpenShift-specific features.
Misconception 4: "We don't need OpenShift experts--our Maximo team can handle it"
>
Reality: You need both Maximo expertise AND OpenShift/Kubernetes skills. Plan for training or augment your team.
Misconception 5: "SaaS and on-premises MAS are identical"
>
Reality: SaaS is multi-tenant and managed by IBM. On-premises gives you control but requires OpenShift management. Architecture is similar, but operational model differs significantly.
Decision Framework: On-Premises vs SaaS
Choose On-Premises If:
- Data sovereignty requirements prohibit cloud storage
- Air-gapped or highly restricted network environments
- Significant customizations requiring deep platform control
- Existing OpenShift investment and expertise
- Integration with on-premises legacy systems
- Regulatory requirements for infrastructure control
You'll need:
- OpenShift cluster (minimum 3 masters, 3+ workers)
- Storage infrastructure (NFS, Ceph, or enterprise SAN)
- Skilled OpenShift administrators
- Disaster recovery and backup infrastructure
Choose SaaS If:
- Want to minimize operational overhead
- Prefer predictable OpEx over CapEx
- Standard configurations without deep customizations
- Don't have OpenShift expertise (and don't want to build it)
- Need rapid deployment (weeks, not months)
- Want IBM to handle platform updates and security
You'll get:
- Fully managed platform
- Automatic updates and patches
- 99.9% availability SLA
- IBM handles infrastructure, security, backups
- Focus on configuring Maximo, not managing Kubernetes
Key Takeaways
- MAS runs as containerized microservices on OpenShift, replacing the monolithic WebSphere architecture of 7.6.x
- Operators automate installation, upgrades, scaling, and healing, eliminating manual administrative tasks
- Multi-application platform shares common services for authentication, event bus, data lake, and API gateway
- Horizontal scaling replaces vertical scaling, enabling elastic capacity and better resource utilization
- On-premises requires OpenShift expertise; SaaS eliminates infrastructure management but reduces control
Resources for Your Journey
IBM Official
OpenShift & Kubernetes
Community
Training
- IBM MAS Administration (MAX0150G)
- Red Hat OpenShift Administration (DO280)
- Kubernetes Fundamentals (LFS258)
Previous: The Mindset Shift: Why Legacy Maximo Thinking Doesn't Work in MAS 9
Next: The 7.6 to MAS Migration Playbook
Series: THINK MAS -- Modern Maximo | Part 2 of 12
About TheMaximoGuys: We help Maximo developers and teams make the transition from 7.6.x thinking to MAS mastery. We've been through the journey ourselves--and we're here to make yours smoother.
Part of the "THINK MAS" Series | Published by TheMaximoGuys | [Subscribe for Updates](#)
The Maximo Guys
Posam Lakshminarayana