An enterprise service bus (ESB) is the layer that routes, transforms and orchestrates messages between an organization's systems. An open-source ESB is that same layer with its source code public and nothing metered. This article explains what the layer does, what changes when it is open source and written in Python, and how a migration from a proprietary platform works.
What does an ESB actually do?
A retailer runs four systems that need to exchange data: an online shop, an ERP, a warehouse system and a CRM. The shop emits orders as JSON over REST. The ERP accepts flat files over SFTP. The warehouse listens on an AMQP queue and the CRM has a REST API with its own field names for the same customer data.
Without an integration layer, each pair of systems that needs to talk becomes a separate project - shop-to-ERP, shop-to-warehouse, warehouse-to-CRM - each with its own format conversion, error handling and retry logic, each maintained forever by whoever built it. The number of such connections grows quadratically with the number of systems.
An ESB replaces the pairs with a hub. Each system connects to the bus once, using its own protocol and format, and the bus does three jobs:
- Routing - deciding which systems receive which message
- Transformation - reshaping each message into what its recipient expects
- Orchestration - coordinating multi-step flows, such as confirming stock in the warehouse before an order reaches the ERP
When the retailer adds a fifth system, it connects to the bus once and subscribes to the flows it needs. Nothing changes in the four systems already connected.
What changes when the ESB is open source?
Two things change: the licensing model and access to the source code. Both are practical rather than philosophical.
The licensing model is simple to describe because there is nothing to meter. There are no per-core licenses, no per-connector tiers, no capacity-based subscriptions, and no forced migrations tied to renewal dates. An integration that processes ten times more messages next year than this year is an engineering fact, not a contract event. The budget conversation happens once, when the scope of commercial support is decided, not at every renewal and not after every traffic increase.
Source code access matters most on the worst day of the year. When a proprietary platform starts refusing connections at 2 AM during peak season, the team's options are a critical support ticket and workarounds guessed from documentation. With the source code available, the engineer on call reads the connector's implementation, sees the exact conditions under which it recycles connections, and matches that against the logs. The difference is between diagnosing the issue in one sitting and waiting for a vendor's business hours.
Modifying the platform is rarely the point. The point is that behavior can be verified against the implementation instead of inferred from documentation. The same applies to security reviews - a security team audits the authentication and encryption code directly rather than accepting a vendor's assurances, and security updates are applied when needed, without a license renewal or a professional services engagement in between.
What ESB work looks like in Zato
The core job of an ESB is to accept a message from one system, transform it, and deliver it to others. In Zato, that job is a Python service. Here is one that receives a payment notification, reshapes it for a legacy settlement system reachable over AMQP, and forwards the original to a fraud detection REST API:
# -*- coding: utf-8 -*-
# Zato
from zato.server.service import Service
class RoutePayment(Service):
""" Routes incoming payment notifications to settlement and fraud detection.
"""
name = 'esb.payment.route'
def handle(self):
# Read the incoming payment notification
payment = self.request.payload
# The legacy settlement system expects a flat, uppercase format
settlement_msg = {
'ACC': payment['account'],
'AMT': payment['amount'],
'CCY': payment['currency'],
}
# Send the transformed message to the settlement system's queue
self.outgoing.amqp.send(settlement_msg, 'Settlement', '/settlement', 'payments')
# Fraud detection is a modern REST API - it receives the message as-is
conn = self.rest['Fraud Detection']
conn.post(self.cid, payment)
The routing and the transformation are plain Python - version-controlled, testable, and readable by any developer - while the connections themselves are defined once in the Dashboard. To build one yourself, follow the API integrations tutorial.
Why Python?
Universities now commonly teach Python as the first programming language where Java once was, and job-market interest in Python overtook Java around 2018. For an integration platform, this decides who will build and maintain the integrations: a Python-based ESB draws from the same talent pool as the organization's data, AI and automation teams. The full hiring argument, with the data behind it, is covered in the article on iPaaS in Python.
Python also means the integration layer uses the same ecosystem as the teams around it. A Zato service calls the same libraries that data science and AI teams already use - there is no bridge between two language worlds when an integration needs to invoke an LLM or process a dataset.
How does a migration from a proprietary ESB work?
A migration does not start with turning the old platform off. Zato connects to the same queues, databases and APIs as the existing ESB, so both run side by side for as long as needed. The usual sequence is:
- Pick one integration - typically a new project, or an existing one blocked by platform constraints or pending vendor tickets - and build it in Zato.
- For flows that already exist on the old platform, run both implementations in parallel and compare outputs before switching traffic over.
- Repeat, retiring integrations from the old platform one at a time, until the renewal date arrives with nothing left on it.
Deployment does not constrain the plan. Zato runs identically on-premises, in AWS, Azure, GCP or a private cloud, in containers or on virtual machines, with no separate cloud edition and no deployment-specific licenses. An acquired company on a different cloud, or a compliance requirement to keep some systems on-premises, changes where instances run, not how the platform is licensed or operated.
Frequently asked questions
What is an open-source ESB?
An enterprise service bus is the layer that routes, transforms, and orchestrates messages between an organization's systems. An open-source ESB additionally gives you the platform's full source code and runs wherever you decide - on-premises or in any cloud.
What is the difference between an ESB and an iPaaS?
The two terms describe the same integration layer from different angles - ESB emphasizes the messaging and orchestration middleware, while iPaaS emphasizes the platform and its connectors. Zato is both, and the article on the open-source iPaaS in Python covers the platform perspective in depth.
Is Zato open-source software that I can find on GitHub?
Yes, you have full access to the platform's source code on GitHub.
How do I migrate from a proprietary ESB?
Integration by integration, not all at once. Zato coexists with proprietary platforms, so you can move each workflow on its own schedule and reduce vendor dependency with every step.
To see the platform against your own integration backlog, request a demo.
- John Adams