This article is based on Red Hat’s October 2019 announcement of OpenShift 4.2, originally reported by FierceTelecom.
Red Hat OpenShift 4.2: What’s New
Red Hat announced OpenShift 4.2 in October 2019, bringing a significant set of developer-focused capabilities and automation improvements to its enterprise Kubernetes platform. The release was aimed at making cloud-native application development faster, more accessible, and easier to manage at scale — across both public and private clouds.
The launch also came amid an intensifying Kubernetes ecosystem rivalry. VMware had made headlines that year by acquiring Pivotal Software to strengthen its own container and Kubernetes portfolio, and Red Hat’s updates were partly a response to that competitive pressure. Meanwhile, IBM — which had closed its $34 billion acquisition of Red Hat in July 2019 — was actively integrating OpenShift into its cloud migration and hybrid cloud offerings.
Key Features in OpenShift 4.2
Red Hat OpenShift Service Mesh
OpenShift 4.2 introduced Red Hat OpenShift Service Mesh, built on the upstream Istio project. It is designed to simplify the development, deployment, and operational management of microservices-based applications running on OpenShift. Service Mesh handles concerns such as traffic management, mutual TLS authentication, observability, and policy enforcement — removing that complexity from individual application code.
The inclusion of Istio was considered particularly significant for enterprises running mixed workloads — containers alongside virtual machines — across on-premises infrastructure and multiple public clouds.
Red Hat OpenShift Serverless (Knative-Based)
OpenShift 4.2 introduced Red Hat OpenShift Serverless, built on the open-source Knative framework. Serverless in this context means that applications can scale down to zero when idle, reducing infrastructure costs, and then scale back up automatically in response to incoming requests. This model suits event-driven workloads, APIs with variable traffic patterns, and batch processing tasks.
Red Hat OpenShift Pipelines (Cloud-Native CI/CD)
The release added Red Hat OpenShift Pipelines, a Kubernetes-native CI/CD solution based on the Tekton project. Each step in a pipeline runs inside its own container, providing strong isolation and allowing individual steps to scale independently based on workload demand. This approach avoids the bottlenecks of traditional CI/CD systems where a shared agent or executor becomes a constraint.
Developer Experience Improvements
A core goal of OpenShift 4.2 was reducing friction for developers. The release allowed developers to install a pre-built, lightweight OpenShift environment on a laptop for local development. Applications and configurations built locally could then be promoted and deployed to a full OpenShift environment, providing a consistent path from inner-loop development to production.
The release also included a framework for tying container development tools together with a local cluster, addressing a common pain point where local environments diverged significantly from production Kubernetes clusters.
Multi-Cloud and Private Cloud Installation
OpenShift 4.2 improved the speed and automation of OpenShift Container Platform installation across major public clouds, including:
- Amazon Web Services (AWS)
- Microsoft Azure
- Google Cloud Platform (GCP)
- Private clouds running OpenStack
The installer enhancements also extended to support for disconnected installs — environments that do not have direct internet access — which is a critical requirement for air-gapped government, financial, and industrial deployments handling sensitive data.
Migration Tools from Older OpenShift Versions
Red Hat included tooling in OpenShift 4.2 to help existing customers migrate from earlier versions of OpenShift to the 4.x platform. The OpenShift 4.x architecture is substantially different from 3.x — using the Operator Framework for lifecycle management and a more automated control plane — so migration tooling was a practical necessity for Red Hat’s installed base.
Industry Context: CNFs and the Kubernetes Race
The OpenShift 4.2 release landed against a backdrop of rapid Kubernetes adoption in the telecommunications and enterprise sectors. Service providers were beginning to migrate network workloads from Virtual Network Functions (VNFs) running on virtual machines to Container Network Functions (CNFs) running on Kubernetes. This shift increased demand for robust, production-grade Kubernetes platforms — a space where both Red Hat and VMware were competing aggressively.
IBM Integration with OpenShift
Following the close of IBM’s acquisition of Red Hat in mid-2019, IBM announced a range of pre-integrated solutions on OpenShift in August 2019, accelerating its hybrid cloud strategy. OpenShift became the foundation of IBM’s cloud platform across its own public cloud and customer on-premises deployments. The inclusion of Istio-based service mesh capabilities was specifically noted by industry analysts as particularly relevant for enterprise customers running heterogeneous, multi-cloud environments.
Red Hat’s Position on OpenShift 4.2
“More and more organizations across industries and around the world trust Red Hat OpenShift to run their most critical business applications. We continue to prioritize making the next generation of enterprise open source technologies like Kubernetes even more accessible to developers while also keeping administrator priorities in balance. With these goals in mind, OpenShift 4.2 delivers on features to help customers accelerate application development and delivery.”
— Ashesh Badani, Senior Vice President, Cloud Platforms, Red Hat
Summary
OpenShift 4.2 represented a meaningful step forward in Red Hat’s enterprise Kubernetes platform, with three significant additions — Service Mesh, Serverless, and cloud-native Pipelines — alongside practical improvements to installation, local development, migration, and disconnected deployments. For teams building microservices on Kubernetes, it reduced the amount of infrastructure scaffolding that had previously required manual setup or third-party tooling.