Originally reported by devops.com. Post date: May 12, 2018.
The Core Argument: PaaS as a Bridge, Not a Barrier
Red Hat has staked a strategic position on the idea that platform-as-a-service (PaaS) environments will become the primary mechanism through which IT operations teams expose a curated catalog of distributed services to developers—without losing governance or control.
Paul Cormier, then President of Products and Technologies at Red Hat, articulated the thesis: when developers lack access to sanctioned services, they route around IT operations entirely—downloading libraries and dependencies on their own. The result is a sprawling application estate of uncertain provenance, duplicated functionality, and hidden operational risk. A mature PaaS changes that dynamic by making approved services available through well-defined APIs, giving developers speed while giving operations teams visibility.
Why CIOs Are Paying Attention
According to Cormier, Red Hat was increasingly engaging CIOs and senior IT leaders—not just architects or platform engineers—in conversations about OpenShift. That shift in audience is significant. It signals that PaaS adoption is moving from a tactical, team-level decision to a strategic initiative aimed at resolving the historic tension between development velocity and operational stability.
The conversation is framed around a familiar DevOps pain point: developers throwing code “over the wall” to operations, followed by fire-fighting, blame, and slow delivery cycles. PaaS, in this framing, replaces the wall with an API.
OpenShift, Kubernetes, and the Blurring of PaaS vs. CaaS
One of the more consequential technical points Cormier made is that OpenShift’s adoption of Kubernetes as its orchestration layer effectively erases the traditional boundary between PaaS and container-as-a-service (CaaS). In practice, this means:
- Traditional 12-factor applications can run alongside newer, microservices-based workloads on the same platform.
- Deployment targets can span on-premises infrastructure and public cloud environments, with the choice driven by cost, data gravity, or regulatory requirements rather than platform limitations.
- Serverless computing frameworks can sit on top of this substrate, enabling event-driven workloads and cloud-bursting scenarios in heterogeneous hybrid cloud environments.
This convergence matters for teams evaluating platform strategy: rather than maintaining separate toolchains for PaaS and container workloads, a Kubernetes-native PaaS like OpenShift aims to consolidate them.
Mixing Internal and External Services in a Hybrid World
Cormier also pointed to a pattern already emerging in larger enterprises: selectively mixing internal platform capabilities with external cloud services based on performance characteristics. His example was AI/ML workloads—an organization might route a specific inference workload to a particular cloud provider because that provider’s AI service outperforms alternatives for that use case, while keeping other workloads on-premises.
This “best tool for the workload” posture requires a platform layer capable of brokering access to both internal and external services consistently—exactly the role Red Hat was positioning OpenShift to play.
The Goal Is Developer Focus, Not Operations Elimination
A common misreading of DevOps is that it aims to replace IT operations with developer self-service. Cormier pushed back on that interpretation. The goal, he argued, is to maximize the time developers spend building and testing applications—not to eliminate operations teams. PaaS enables this by abstracting infrastructure complexity, so developers are not blocked waiting for environments, and operations teams are not overwhelmed fielding ad-hoc infrastructure requests.
This distinction is important for organizations evaluating whether to invest in a PaaS: the platform does not make operations teams redundant; it reshapes their role from reactive ticket-handlers to curators of platform capabilities.
The Adoption Gap: Why PaaS Uptake Remained Uneven
Despite the strategic argument, Cormier acknowledged that most IT organizations in 2018 had only pockets of PaaS adoption. The majority of applications were still being built and deployed without any PaaS involvement. The most frequently cited reason: early PaaS platforms were perceived as too prescriptive—they imposed opinions on application structure, deployment workflow, and runtime choices that many teams were unwilling to accept.
Red Hat’s bet was that the rise of container-based, microservices architectures would change the calculation. Containers already impose a degree of standardization on how software is packaged and run. Given that foundation, organizations may find it easier to accept the additional conventions of a PaaS in exchange for significantly reduced infrastructure complexity.
Key Takeaways for DevOps Teams
- PaaS as governance layer: A mature PaaS can enforce approved service consumption without becoming a bottleneck, replacing informal workarounds with sanctioned APIs.
- Kubernetes convergence: The PaaS/CaaS distinction is increasingly academic on Kubernetes-native platforms. Evaluate platforms on workload breadth, not category label.
- Hybrid cloud brokering: Platform strategy should account for selectively routing workloads to internal or external services based on performance, cost, and compliance—not just lift-and-shift.
- Serverless integration: Event-driven serverless frameworks can extend a PaaS to cover burst and integration workloads without requiring separate infrastructure.
- Operations reshaping, not elimination: PaaS adoption changes the operations team’s mandate from infrastructure provisioning to platform product ownership.