IntegrationHub: The Intelligent, AI-Ready Integration Platform

Most enterprises accumulate connectivity over years and across many tools. The result is powerful but fragmented: every system has its own console, its own credentials, its own operational model — and usually its own team. IntegrationHub sits above that estate and gives one self-service, governed experience, without a rip-and-replace of what already works.

When this post first went up, that was the intent. It is now the implementation, so here is the detail.

Three planes, one control surface

IntegrationHub provisions and operates three kinds of integration infrastructure on Kubernetes:

• API gateways — NGINX and Kong, for publishing and protecting APIs.
• Message brokers — RabbitMQ, reachable over both AMQP and MQTT, with virtual-host isolation per tenant.
• Event streaming — Apache Kafka: topics, partitions, consumer offsets.

These are normally three products owned by three teams. Here they share one provisioning path, one operations model and one audit trail. That matters because the cost of integration is rarely the software — it is the three teams, and the handoffs between them.

You request a tenant; you do not file a ticket

Provisioning runs as a governed workflow rather than a script somebody runs on your behalf.

A tenant needs a name Kubernetes will accept, and "the customer's name" is not it. Namespaces are generated deterministically into a form that is RFC 1123-valid and length-bounded, so a tenant called Acme Logistics & Co. becomes something the cluster will actually take — every time, without a human sanitising it by hand.

Ports are allocated inside a transaction. That sounds like a detail until two tenants are requested in the same second: allocate outside a transaction and both are told they own the same port, and the second one to deploy fails in a way that looks like a networking problem. Allocating under the database's own concurrency control means the collision cannot happen.

Concurrent provisions are bounded, and a request that cannot get a slot within the give-up window fails fast with a clear message rather than queueing invisibly. A system that silently accepts unlimited work is not resilient; it is just slower to tell you it is broken.

When provisioning fails, it says so

A failed provision lands in a failed state with the reason attached. It does not report success and leave you to discover otherwise.

This is the behaviour we would defend hardest, because the alternative is so common. A pipeline that dispatches a job and reports "submitted" as "done" will be right most of the time and catastrophic the rest. Provisioning here polls the real job to a terminal state and reports what actually happened — including matching the specific run it dispatched, so it cannot accidentally report on somebody else's job that happened to be in flight at the same moment.

Day-2 is where the week actually goes

Standing something up is the easy part:

• Lifecycle — start, stop, restart, scale, maintenance mode.
• Observability — live status, logs, Kubernetes events, and the history of every operation performed against the tenant.
• Message operations — peek at a queue, publish a message, purge, move to a dead-letter queue, reset consumer offsets. On the same screen, with the same audit trail.
• Federation — connect brokers by selecting a source and a target, instead of hand-writing federation configuration and hoping the two ends agree.

Publishing applies live

Publishing an API or a topic is applied to the running gateway or broker: Kong's configuration endpoint with per-subscription key and ACL plugins, RabbitMQ's definitions API applied as whole state, Kafka topics through the admin client. No pod restart, no pipeline run, no file for someone to deploy later.

"Whole state" is a deliberate choice with a consequence worth naming. Because the broker is reconciled against the full intended definition rather than patched, deleting something in the control plane actually removes it from the broker. Patch-only integrations tend to create things reliably and delete them never, and the orphans accumulate until someone audits the broker by hand.

Every subscription carries its own authorization and its own expiry, so access that should end does end — without a person remembering to revoke it.

Governance on the paths that lose data

Every destructive action previews exactly what it will destroy before you confirm it. Deleting a tenant tells you what goes with it. Decommissioning removes the tenant and its objects rather than orphaning them.

And a metric the platform has never measured is reported as exactly that — never as zero. A zero and an absence mean very different things to whoever is on call, and quietly conflating them is how a dashboard starts lying.

Where it is going

More of the same discipline: broader protocol coverage, and deeper operational reporting. We would rather ship one plane that genuinely works end to end than announce five.