Dramatically reduce cost while improving availability and reliability of your private message queueing infrastructure: Retire it.

It's no secret to those who do it that running 24/7 commercially supported, highly available message or event broker infrastructure in your own datacenter can be VERY expensive; licenses and platform investments can run into hundreds of thousands of dollars, ops cost excluded.

For many companies, there's a Microsoft Azure datacenter region within ~20ms roundtrip latency from your sites. Here's a thought:

Azure Service Bus, a fully managed platform-as-a-service messaging service costs less than $1000/month at one "messaging unit" capacity (~2000 msg/sec) with an assumed 1000 msg/sec (at 1kByte/msg for this example) sustained usage averaged over 24h. You don't pay for hardware, for operating systems, for virtualization infra, for storage, or for broker software licenses and the ops team is included. You just pay for the broker capacity and for half of the data transfer (ingress is free). Service Bus is available in all of the 60+ global regions.

With that you get no-downtime operations (unlike others, we don't exclude the famous weekend servicing period conveniently from the uptime stats), high-availability zone-redundant deployments, and full product support including for all SDKs. And it's AMQP 1.0 open-standards based, unlike the proprietary thing you might run now.

If you need that broker as part of your private network as if it were running in a cluster inside your datacenter, you can use Service Bus "private link" support in combination either with Azure VPN Gateway or even with Azure Express Route.

Existing enterprise applications that lean on the Java Message Service (JMS) API and mostly use queues work well today, and if you need expanded JMS 2.0 compatibility also for topics or support for very large messages, we may have some private preview options for you if you reach out to me ;)

All of the same is also true for the Azure Event Hubs event stream engine, which is also wire-compatible with a very large number of frameworks and applications that are part of the Apache Kafka® ecosystem, which is vastly less expensive than running your own clusters.

"Cloud" does not always mean "all in". Just like you might be expanding your on-premises storage capacity with cloud-backed storage, you can also throw out on-premises messaging infrastructure and replace that with a cloud-based service rather than paying the "maintenance rent".

For enterprises that need messaging and eventing infrastructure as communication bridges between different sites or between head and branch offices/stores/clinics, there's really no good argument to keep paying that on-premises platform vendor and yet shouldering all ops cost.

Get started here.