Running IBM Maximo Application Suite on AWS SNO with Cloudflare and a Docker-hosted DB2 Database
A practical hybrid-lab architecture for secure MAS proof-of-concepts, demonstrations and repeatable testing
Why this architecture?
Installing IBM Maximo Application Suite (MAS) in a lab is rarely just an OpenShift exercise. The platform depends on DNS, certificates, persistent storage, identity, database connectivity and several MAS foundation services. In many real-world proof-of-concepts, those components do not live in a single network. This lab intentionally reflects that reality: MAS runs on a Single Node OpenShift (SNO) cluster in AWS, while DB2 remains on an existing private lab network in a Docker container. This is a hands-on lab/POC architecture, not a recommended production topology.
Cloudflare becomes the connectivity layer between those two worlds. It provides a controlled path to the private database without opening the DB2 listener directly to the internet. The result is a compact architecture that keeps the AWS footprint small, reuses an existing database host, and still demonstrates the networking and security considerations that matter in a hybrid MAS deployment.
|
AWS SNO One OpenShift node hosts the control plane and MAS workloads. |
Cloudflare Secure access and TCP transport bridge the public cloud and private lab. |
Docker DB2 Database stays on the existing lab network and is reached through a proxy path. |
Architecture in plain language
The design separates platform hosting from database hosting. AWS is responsible for the OpenShift SNO node and MAS runtime, while the private lab continues to host DB2. Cloudflare supplies the secure bridge between them. This separation was chosen for a short-lived lab so an existing database server could be reused rather than duplicated in AWS.
1. AWS and Single Node OpenShift
The AWS side uses a single EC2 instance as the OpenShift control-plane, master and worker node. SNO is well suited to a lab because it provides the full OpenShift API and operator model without requiring a multi-node control plane. Persistent OpenShift storage is backed by AWS EBS gp3 volumes, and the cluster exposes the standard API and application ingress endpoints through the delegated OpenShift DNS zone.
2. MAS foundation services
Before Manage can be activated, the MAS foundation layer must be healthy. In this build, the sequence included IBM operator catalogs, cert-manager, trusted API and ingress certificates, MongoDB Community Edition, Suite License Service (SLS), Data Reporter Operator (DRO), workspace configuration and MAS Core. Treating each layer as a separate validation point made troubleshooting significantly easier than attempting a single monolithic installation.
3. The hybrid DB2 path
The database is not addressed by its private 192.168.x.x address from AWS because that address is not routable from the OpenShift VPC. Instead, OpenShift contains a small cloudflared client Deployment. MAS connects to an internal Kubernetes ClusterIP service, which forwards the JDBC TCP stream into cloudflared. Cloudflare Access authenticates that connection and sends it through the existing PrivateLab tunnel to the DB2 Docker host.
|
MAS / Manage |
Uses an internal JDBC hostname, not the home-network IP. |
|
OpenShift Service |
Stable ClusterIP DNS name for the database proxy. |
|
cloudflared Deployment |
Translates the local TCP connection into the Cloudflare Access/Tunnel path. |
|
Cloudflare Access + Tunnel |
Authenticates the machine connection and transports it to the private lab. |
|
Docker DB2 |
Listens on the private host and serves the MAS database. |
Why Cloudflare matters here
Cloudflare is doing more than DNS. It is the boundary and transport layer for the hybrid lab. The database port does not need to be opened on the home router, the AWS VPC does not need a direct site-to-site route to the private lab network, and the client connection can be protected with a service token intended for non-interactive workloads. For this lab, that avoided deploying an additional AWS gateway instance solely for private-network connectivity.
Latency and production considerations
The database and MAS application tiers are in different locations in this POC, so every database round trip traverses the hybrid path. Maximo is database-intensive and additional network latency can accumulate across transactions that execute many SQL statements. The configuration proved secure connectivity and functional JDBC access; production deployments should place the database close to the application tier or use a designed low-latency private network and validate performance under representative load.
A staged deployment journey
The most valuable lesson from this build was to treat the environment as a chain of dependencies. DNS and certificates come before MAS. Storage comes before stateful services. MAS Core comes before Manage. Database connectivity must be proven before Maxinst and application activation. This staged approach turns a complex installation into a series of smaller, observable milestones.
Deployment sequence used in the lab
Troubleshooting that shaped the final design
Two problems were especially useful in refining the architecture. First, the initial JDBC test reached DB2 but returned SQL30061N because the database name in the connection string did not match the actual DB2 database alias. That error was important: it proved that the Cloudflare TCP path was already working and shifted the investigation from networking to database configuration.
Second, the automation originally waited for a Maxinst pod every time the JDBC configuration was applied. That logic could wait indefinitely when Manage had not yet created Maxinst. The workflow was corrected so JDBC configuration ends after the resource is generated and applied; Maxinst-specific operations remain part of the Manage lifecycle. Separating those responsibilities made the automation safer and easier to reason about.
Infrastructure requirements and cost awareness
The OpenShift/MAS portion is not a standard-laptop workload. This POC used an AWS SNO system with 16 vCPU and 64 GB RAM, AWS EBS gp3 persistent storage, a separate private lab server running Docker-hosted DB2, Cloudflare connectivity, and a Linux administration host with AWS and OpenShift tooling. Equivalent cloud or on-premises infrastructure can be used, but adequate CPU, memory and persistent storage are required. Cost Explorer also showed that compute was only part of the expense: the short-lived lab accumulated about $124 USD, with material charges from EC2 support resources, load balancing, VPC networking, public connectivity and storage.
What this architecture demonstrates
This environment is intentionally a lab, but it demonstrates several patterns that translate well to enterprise architecture discussions: workload placement can be independent of database placement; secure access can be introduced without making the database directly public; and OpenShift-native services can provide stable application endpoints even when the real database is reached through an external connectivity layer. The Cloudflare TCP path demonstrated functional hybrid connectivity; it should not be interpreted as a production database-networking recommendation.
|
Benefits for a lab / POC
|
Important boundaries
|
Operational pattern: start, validate, stop
Because the lab runs on an on-demand EC2 instance, operational discipline directly affects cost. The cluster can be stopped after a successful test cycle and restarted when needed. On restart, the SNO node, OpenShift operators, MAS services, MongoDB and the cloudflared Deployment reconcile automatically. A conservative shutdown watchdog can wait until Manage reports a stable ready state, perform a graceful SNO shutdown, and then allow the EC2 instance to transition to stopped.
Where this pattern fits
This architecture is a strong fit for technical enablement, proof-of-concept work, upgrade rehearsals, integration testing and solution demonstrations. It gives teams a realistic MAS environment without requiring every component to be relocated into one cloud account. For production, database latency, high availability, storage, backup, disaster recovery and private-network design must be evaluated independently.
Closing perspective
The project started as a straightforward goal - run MAS on AWS SNO - but the most valuable outcome was the hybrid architecture and the operational lessons around it. By combining OpenShift, AWS storage and networking, Cloudflare Access/Tunnel, and a Docker-hosted DB2 database, the lab demonstrates how MAS can be assembled from well-defined building blocks, tested in stages, troubleshot systematically and dismantled when no longer needed.
Lab architecture summary: AWS SNO for MAS + Cloudflare for secure hybrid connectivity + Docker DB2 for reusable database services.