Healthcare applications demand near-zero downtime. Patient-facing tools, from inpatient video platforms to hospital feed management systems, must be available around the clock and respond instantly. For the platform engineering team at a large healthcare organization, that expectation was increasingly at odds with their infrastructure reality: a sprawling, bare-metal Docker environment without an orchestration layer.
To prevent service disruptions and scale their delivery, we executed a complete infrastructure modernization. By migrating their legacy Python and PHP applications to Red Hat OpenShift, we minimized downtime, automated security posture, and drastically reduced application onboarding time.
What’s in this article:
- How we replaced a fragile bare-metal Docker environment with Red Hat OpenShift without disrupting healthcare services
- The architecture we used to isolate application teams and enforce least-privilege RBAC
- How platform modernization reduced onboarding time from days to hours while enabling automated 24/7 recovery for patient-facing platforms
The High Cost of Bare-Metal Container Sprawl
The organization ran all application workloads as Docker containers on bare-metal RHEL 9 on-premises servers. As the number of applications grew, teams expanded, and deployment frequency increased, the cracks in this un-orchestrated model became impossible to ignore.
Multiple teams shared the same hosts with limited workload isolation, deployments varied across environments, and routing changes depended on external ticket-driven processes. As delivery frequency increased, these constraints directly slowed release velocity and drove up operational coordination costs.
Resilience and observability became critical vulnerabilities. Health visibility was limited, failover behavior was purely reactive to infrastructure health-check windows, and logging required separately maintained tooling. The security posture was also inconsistent, with root-running containers and uneven policy enforcement across teams.
Choosing Enterprise-Grade Orchestration
We evaluated lighter-weight alternatives for container orchestration, but each fell short of enterprise requirements:
- Plain Docker Swarm: Didn’t meet our compliance and multi-tenancy requirements.
- Manual Kubernetes on VMs: Required too much undifferentiated heavy lifting; the team would end up managing the platform instead of shipping products.
The organization finally chose Red Hat OpenShift as they needed an enterprise-grade, fully supported platform. This platform provides industry-standard Kubernetes wrapped with enterprise security, built-in operators, an integrated image registry, and native support for their existing RHEL infrastructure. Critically, it allowed them to move fast without compromising their on-premises security posture.
Strengthening Platform Security and Operational Governance
Isolating Workloads Through Namespace
One of the first architectural decisions we made was establishing one namespace per team. In the Docker-on-RHEL world, multiple teams shared the same servers with no boundaries. We architected a strict namespace-per-team multi-tenancy model to isolate workloads, enforce ownership boundaries, and contain blast radius across application domains.
1openshift-cluster/
2├── namespace: team-clinical-apps/
3│ ├── inpatient-video (deployment)
4│ ├── patient-portal (deployment)
5│ └── clinical-api (deployment)
6├── namespace: team-operations/
7│ ├── feed-management (deployment)
8│ ├── reporting-service (deployment)
9├── namespace: team-integrations/
10│ ├── hl7-gateway (deployment)
11│ └── fhir-adapter (deployment)Each namespace became the ownership boundary for a team. Resources, quotas, access, and networking policies were all scoped to the namespace.
Enforcing RBAC
To enforce least-privilege access across every team, we used OpenShift's built-in Role-Based Access Control (RBAC). No more shared SSH keys. No more "ask someone on the infra team to restart your container. Teams could now manage their own deployments while remaining isolated from other teams’ workloads.
Enforcing Network Policies
We introduced Kubernetes Network Policies to enforce which namespaces and services could communicate with each other. In the old shared-server model, any container could reach any other container on the same host. That was both a security risk and an operational one. With namespace-level network isolation in place, even if one team’s application is compromised or misconfigured, the blast radius remains contained to that team’s namespace.
Automating Least Privilege Compliance
To meet rigorous healthcare compliance standards, we engineered a hardened, least-privilege container runtime baseline. OpenShift also mandates a strict non-root policy, enforced through Security Context Constraints (SCCs) at the OS level.
Every Docker image (where the process ran as root) had to be rebuilt before it could run on OpenShift. We updated all Dockerfiles to explicitly create and switch to a non-root user. We also enforced this at the namespace level via Kustomize base manifests.
With this model, even if a developer accidentally pushed an image built as root, the pod would fail to schedule, making security enforcement automatic and non-negotiable rather than dependent on developer discipline.
Operational Standardization with the oc CLI
Along with the OpenShift web console, the oc command-line interface became the day-to-day operational tool. Unlike the old model of SSH-ing into multiple servers and running Docker commands host by host, oc gave teams a single, consistent control plane for all environments and teams. This reduced operational variance across teams, improved incident response speed, and removed the need for host-level Docker access in day-to-day support operations.
Accelerating Delivery with GitOps Pipelines
To avoid deployment bottlenecks, we standardized on GitHub Actions + Kustomize overlays for application delivery. This gave us a repeatable, Git-centric workflow with clear environment separation, auditable diffs, and deterministic rollback.
The deployment pipeline flow:
- Developer pushes code to the repository.
- GitHub Actions builds and pushes the image to the organization's container registry.
- GitHub Actions applies the Kustomize overlay for the target environment.
- OpenShift triggers a rolling deployment with health checks.
- OpenShift validates pod readiness and assumes self-healing duties.
Improving Agility with Automated Traffic Management
Under the old model, exposing a new application required a manual F5 load balancer ticket with 1–3-day lead time. Failover was manual, and TLS certificates were centrally managed bottlenecks.
By shifting to an application-owned, declarative routing model, we accelerated release velocity and standardized traffic exposure across environments. Every application now declares its own route in YAML, and the OpenShift HAProxy-based router handles the rest, including automatic TLS certificate provisioning via the cert-manager operator.
Automating Platform Operations
We leveraged OpenShift's operator framework to automate and standardize critical platform capabilities across the entire application lifecycle. This included automated TLS certificate management to eliminate outage risk from expired certificates, centralized logging, and built-in Prometheus-based monitoring to provide platform and workload observability across all namespaces. Together, these capabilities transformed platform operations from manual, error-prone processes into repeatable, auditable engineering practices.
Turning Observability into Platform Capability
Before OpenShift, logging and monitoring relied on separately managed ELK and Grafana stacks. Log ingestion and dashboards required per-application configuration, and there was no unified cross-team or cross-environment visibility.
With OpenShift, observability became a built-in platform capability instead of a separate system to maintain:
- Logs: Cluster Logging Operator auto-collects logs from all pods, with namespace-scoped access for team-level isolation.
- Metrics: OpenShift Monitoring (Prometheus/Alertmanager) provides default workload metrics and supports namespace-level custom alerts.
- Dashboards: The OpenShift console offers live metrics, events, and log views per namespace through RBAC-controlled access.
Outcomes at a Glance
Migrating to a fully orchestrated OpenShift-based architecture fundamentally transformed how the healthcare organization delivers software. By abstracting away the complexity of legacy bare-metal infrastructure, we achieved measurable outcomes for both IT operations and patient care delivery.
- Faster, Safer Releases: Deployments moved from SSH-based coordination to repeatable Git-driven pipelines with environment overlays and rollback by commit revert.
- Higher Runtime Resilience: Health probes, orchestration-based restarts, and policy-driven rollout controls reduced manual recovery effort and improved service stability.
- Stronger Multi-team Isolation: Namespace-per-team tenancy, RBAC, and default-deny network controls enforced clear ownership boundaries and reduced cross-team blast radius.
- Improved Security Baseline: Non-root execution, reduced Linux capabilities, and standardized pod security contexts made secure defaults enforceable across workloads.
- Lower Operational Overhead: Logging and monitoring became platform capabilities, reducing custom per-app instrumentation and separate tooling maintenance.
Don't let bare-metal sprawl dictate your time-to-market. Discover how our Cloud Transformation Services can help you deploy faster, scale securely, and eliminate downtime.