Originally reported by itp.net (August 2020). Additional context added by the editors.
What Red Hat Integration Is
Red Hat launched Red Hat Integration as a consolidated suite of integration and event-processing technologies designed for container-based environments. The suite targets organizations that need to create, extend, and deploy integration services across hybrid and multi-cloud infrastructures without being locked into a single platform or deployment model.
The solution is positioned as agile, distributed, and API-centric, giving development and operations teams a consistent way to connect applications and share data regardless of where those workloads run—on-premises, in a public cloud, or across multiple clouds simultaneously.
Why Enterprise Integration Has Had to Evolve
Enterprise IT integration is not a new problem, but the dominant architectural patterns have shifted dramatically over the past decade. Monolithic middleware platforms and point-to-point ESB (Enterprise Service Bus) topologies have given way to a landscape defined by three core primitives:
- Microservices – independent, loosely coupled services that can be developed, deployed, and scaled separately.
- APIs – the contracts that allow those services (and external systems) to communicate in a standardized way.
- Containers – the packaging model that makes microservices portable and environment-agnostic.
Kubernetes has become the de facto orchestration standard for managing containerized workloads at scale. As organizations migrate to or build on Kubernetes, their integration layer must follow—moving from centralized, server-based middleware to distributed, cloud-native integration patterns.
Key Capabilities of Red Hat Integration
Red Hat Integration bundles several upstream open-source projects and Red Hat-productized components into a single subscription. Core capabilities include:
- Apache Camel / Camel K – A lightweight, Kubernetes-native runtime for Camel integration routes. Camel K allows developers to run integration code directly on Kubernetes without writing boilerplate Deployment manifests.
- AMQ Streams (Apache Kafka on Kubernetes) – Red Hat’s productized distribution of the Strimzi project, which provides Kubernetes Operators for deploying and managing Apache Kafka clusters natively.
- AMQ Broker – An enterprise-grade messaging broker based on Apache ActiveMQ Artemis, supporting AMQP, MQTT, STOMP, and other protocols.
- 3scale API Management – Tools for publishing, securing, and analyzing APIs at scale.
- Debezium – An open-source change data capture (CDC) platform that streams database changes as events to downstream consumers.
- Service Registry – A schema and API artifact registry (based on Apicurio) that enforces data contracts between producers and consumers in event-driven systems.
Strimzi: Running Apache Kafka on Kubernetes
One of the most technically significant components highlighted in the launch is the Strimzi project, which underpins AMQ Streams. Strimzi provides a set of Kubernetes Operators that automate the deployment, configuration, and lifecycle management of Apache Kafka clusters on Kubernetes.
Running Kafka on Kubernetes introduces real operational complexity—stateful workloads, persistent storage, inter-broker networking, and rolling upgrades all require careful handling. Strimzi encodes that operational knowledge into Kubernetes Custom Resource Definitions (CRDs) and Operators, allowing teams to manage Kafka clusters declaratively using the same kubectl or GitOps workflows they use for the rest of their platform.
Red Hat is a contributor to the upstream Strimzi project, which is hosted under the Cloud Native Computing Foundation (CNCF) sandbox. AMQ Streams is the supported, enterprise-ready productization of that upstream work.
Integration as a Competitive Differentiator
Beyond the technology stack, the business driver is speed. The ability to rapidly respond to changing market conditions—shipping new features, incorporating user feedback, or connecting a newly acquired system—depends on how quickly integration work can be done. Tightly coupled, centralized integration layers become bottlenecks; distributed, API-driven integration patterns remove them.
Cloud-native integration aligns the integration layer with the same principles that govern modern application architecture:
- Decentralized ownership – individual product teams own and operate their integration routes, reducing dependency on a central middleware team.
- Event-driven architecture – systems react to events in near real-time rather than polling or relying on scheduled batch jobs.
- Self-service API exposure – API management tooling lets teams publish and consume APIs without going through a central gateway bottleneck.
- Observability built in – metrics, tracing, and logging can be emitted from integration components and scraped by the same tools (Prometheus, Jaeger, etc.) used across the rest of the Kubernetes platform.
Deployment Model
Red Hat Integration is designed to run on Red Hat OpenShift, Red Hat’s Kubernetes distribution, but many of the underlying components—Camel K, Strimzi, Debezium—are standard Kubernetes-compatible projects that can run on any conformant cluster. The full productized suite with enterprise support is available as part of a Red Hat subscription.
Organizations evaluating the suite should assess which components they actually need. A team that already runs Apache Kafka may only need Camel K for lightweight integration routing; a team starting from scratch may want the full stack including API management and a service registry for schema governance.
Summary
Red Hat Integration consolidates Apache Camel, Apache Kafka (via Strimzi), change data capture (via Debezium), API management, and schema registry capabilities into a single, Kubernetes-native integration platform. For DevOps and platform engineering teams building or migrating to cloud-native architectures, it represents a shift from centralized middleware toward distributed, operator-managed, event-driven integration—one that aligns more naturally with how modern containerized applications are built and operated.