An iPaaS, or integration platform as a service, is a cloud service for building, running and managing integrations between applications and data, with the vendor operating the platform. An enterprise service bus (ESB) does similar work on infrastructure you run yourself. Event streaming moves facts between systems as a durable, replayable log. Most enterprises run all three, and the useful question is not which one wins but which workloads belong on each. This guide compares them, names the leading platforms in each category, and sets out how to decide. It is part of our API Management & Integration series.
The short answer:
- Use an iPaaS for SaaS-to-SaaS and cloud application integration, and wherever you want the vendor to run the platform.
- Keep or modernize an ESB-style runtime for high-volume, low-latency integration close to on-premises systems.
- Use event streaming when many systems need the same facts, or when you need replay and history.
What iPaaS is
An iPaaS gives integration teams a hosted environment with connectors to common applications, a visual or low-code designer, data mapping and transformation, scheduling, monitoring and API exposure. The vendor runs the infrastructure, patches it and scales it. You pay by subscription, usually tied to connections, flows, messages or compute.
The appeal is speed and less operational work. A team can connect a CRM to an ERP, or sync HR data to an identity system, in days instead of weeks, without provisioning servers.
The trade-offs are control and data location. Integration logic runs on the vendor's platform, and data passes through it unless you use a self-hosted runtime. Pricing can climb with volume. Connectors cover popular SaaS applications well and legacy or mainframe systems less well.
Most iPaaS vendors now split the platform in two. The control plane, where you design, deploy and monitor, stays in the vendor's cloud. The runtime, where data actually flows, can run in the vendor's cloud or on your own infrastructure. That hybrid model is what makes iPaaS usable for firms whose data cannot leave their perimeter.
What an ESB is, and why it is not dead
An enterprise service bus is integration middleware that you install and operate. It routes and transforms messages between systems, exposes services, and handles protocols that older systems speak: files, queues, SOAP, proprietary formats. ESBs became common in the 2000s as the backbone of service-oriented architecture.
The criticism of the ESB was never really about the technology. It was about the pattern: one central bus, one central team, and every change queued behind them. Integrations became a bottleneck, and the bus became a single large system that was hard to upgrade.
Modern integration runtimes keep what worked and drop what did not. They run as lightweight containers, deploy one integration at a time, scale independently and sit in normal CI/CD pipelines. Many products that once were ESBs now ship this way. WSO2 Integrator, for example, combines what were separate integration profiles, including the Micro Integrator runtime, into one product that can run self-hosted or as WSO2's managed iPaaS.
So the ESB is not dead. The monolithic, centrally owned ESB is. Self-managed integration runtimes remain the right choice for integration close to on-premises systems, for high-volume and low-latency flows, and for firms that must run everything inside their own infrastructure.
What event streaming adds
Event streaming is a different job. An integration flow moves and transforms data from A to B. An event stream records that something happened, such as an order placed or a payment cleared, and keeps it in an ordered log that any number of systems can read in their own time and replay later.
That makes event streaming the right place for facts many systems need: analytics, fraud detection, search indexes, AI agents and audit. It does not replace request and response integration or the transformation work an integration platform does. Our guide to event-driven architecture: queues, streams and APIs covers when to use a stream, a queue or an API call.
Apache Kafka is a widely used event streaming platform. It runs self-managed, as a managed cloud service, or as part of a data platform such as Kafka on Cloudera.
iPaaS vs ESB vs event streaming compared
| iPaaS | ESB or integration runtime | Event streaming | |
|---|---|---|---|
| Main job | Connect applications and data, mostly cloud and SaaS | Route and transform messages between systems you run | Record facts once and let many systems read them |
| Who runs it | The vendor (control plane), with optional self-hosted runtimes | You | You, or a managed service |
| Typical flow | Sync a CRM record to an ERP | Transform a mainframe file into an API call | Publish "order placed" to many consumers |
| Pattern | Request and response, scheduled jobs, simple events | Request and response, routing, mediation | Publish and subscribe, durable log |
| Replay | Limited, usually by re-running a job | Limited | Yes, from any retained position |
| Latency and volume | Moderate; can cost more at high volume | Low latency, high volume, close to the systems | High throughput, many consumers |
| Legacy and on-premises reach | Weaker; depends on connectors and runtimes | Strong | Needs connectors or change data capture |
| Skills | Low-code designers plus integration skills | Integration developers | Streaming and distributed systems skills |
| Cost model | Subscription by connections, flows or volume | License or open source, plus your infrastructure and staff | Infrastructure or managed service, plus staff |
| Main risk | Lock-in and volume pricing | Central bottleneck if run as one shared bus | Ungoverned topics and schema drift |
Read the table as a guide to fit, not a ranking. The three overlap at the edges. Most iPaaS products handle simple events, most integration runtimes can publish to Kafka, and Kafka Connect can do basic integration. The question is which one should own each kind of workload.
Leading platforms in each category
These are common choices, not a ranking. Duczer East is a WSO2 Partner and a Cloudera Premier Partner, and works across the other platforms named here.
iPaaS:
- Boomi
- Informatica Intelligent Data Management Cloud
- MuleSoft Anypoint Platform
- Microsoft Azure Integration Services, including Azure Logic Apps
- SAP Integration Suite
- Workato
- WSO2 Integrator as WSO2's managed iPaaS (Devant)
Self-managed integration runtimes and ESBs:
- IBM App Connect Enterprise
- TIBCO BusinessWorks
- Microsoft BizTalk Server
- Oracle SOA Suite
- MuleSoft runtimes on Anypoint Runtime Fabric, on Kubernetes you manage
- WSO2 Integrator, self-hosted, including the Micro Integrator runtime
- Apache Camel, an open-source integration framework
Event streaming:
- Apache Kafka, self-managed
- Kafka on Cloudera
- Amazon MSK
- Confluent
- Azure Event Hubs
- Google Cloud Pub/Sub
- Apache Pulsar
Several vendors span categories. MuleSoft, Boomi and WSO2 each offer a managed service and a way to run the runtime on your own infrastructure: MuleSoft through Runtime Fabric, Boomi through its basic runtimes and runtime clusters, and WSO2 through self-hosted and hybrid deployments of WSO2 Integrator. For firms already on WSO2, our integration on WSO2 page covers how the pieces fit.
Hybrid integration when data cannot leave
Many firms cannot send customer, patient or payment data through a vendor's shared cloud. That used to rule out iPaaS. The split between control plane and runtime changes that.
In a hybrid deployment, design, deployment and monitoring stay in the vendor's cloud, while the runtime runs in your data center or your own cloud account. Payloads stay inside your perimeter. Only metadata, such as deployment instructions and health metrics, crosses to the vendor.
If you work in a regulated industry, check four things before you accept a hybrid model:
- What crosses to the control plane: metadata only, or also logs and message samples that may hold personal data.
- Where logs and traces are stored, and for how long.
- Who can deploy to your runtime from the vendor's cloud, and how that access is authenticated and recorded.
- What happens to running integrations if the control plane is unavailable.
Banks, insurers and health systems also need integration changes to go through change management, with an audit trail of who deployed what and when. Both iPaaS and self-managed runtimes can do this, but it has to be designed in, not assumed.
How to decide: seven questions
Work through these for each group of integrations, not for the whole estate at once.
- Where do the systems live? Mostly SaaS points toward iPaaS. Mostly on-premises points toward a self-managed runtime.
- Can the data leave your infrastructure? If not, you need a self-managed runtime or a hybrid iPaaS with a runtime you host.
- How many systems need the same data? If many, publish it once to an event stream rather than building a flow to each.
- Do you need replay or history? If yes, that data belongs on a stream.
- What are the volume and latency needs? High volume and low latency favor a runtime close to the systems.
- Who will build and run it? A small team with low-code skills gets more from an iPaaS. A team with integration developers can run its own runtime.
- What does it cost at your volume in three years? Price the subscription at forecast volume, not today's, and compare it with infrastructure and staff for a self-managed option.
Most estates end up with a mix: an iPaaS for SaaS and departmental integration, self-managed runtimes for core systems, and an event stream underneath for shared facts. What matters is that each integration has a clear home and that APIs, flows and topics are governed the same way.
Moving off a legacy ESB
Many firms are on an ESB product that is reaching the end of its vendor support or that nobody wants to upgrade. A big-bang migration is rarely worth the risk.
A safer path moves one integration at a time. Put an API or event in front of each flow, so callers no longer depend on the bus directly. Rebuild the flow on the target platform, run old and new side by side, compare outputs, then switch traffic. Repeat until the old bus carries nothing and can be retired.
Vendors publish their own migration paths. Microsoft, for example, documents a move from BizTalk Server to Azure Logic Apps Standard. Treat those as one option to compare, not the default. The target should follow the seven questions above, not the incumbent vendor's roadmap.
Event streaming often helps a migration. Copy the old bus's messages into Kafka, and new consumers can start using the data before the flows that produce it are moved.
When to bring in a partner
The hard part is not choosing a product. It is deciding which integrations go where, moving them without an outage, and running a mixed estate with one set of controls. For a property and casualty insurer, a core team of two manages and develops a platform built on WSO2 API Manager, RabbitMQ and Kafka, and has grown to ten engineers as the work expanded. Duczer East provides system integration services across iPaaS, integration runtimes, APIs and event streaming, and supports what it builds.
