We use IBM MQ at work and I wouldn't exactly call it simple.
There's sender channels, receiver channels, xmit queues, local queues, remote queues, dead letter queues, topics, subscriptions and all kinds of other things to learn about. Add that to the crappy IBM tools and their documentation that is full of dead links and you're in for a lot of learning through trial-and-error.
> We use IBM MQ at work and I wouldn't exactly call it simple.
2nd'd & 3rd'd ...
You hired a 50 man lumberjack crew to cut down a sapling.
I've been spending a some time to remove IBM MQ out and going to "simpler" queuing solutions. First of all, cost. Guess what, we're not getting anything out of licensing per year to justify the cost.
With improving the end points, we don't need all that complexity. With 5 9's uptime on the network and smarter end points, retrying messages isn't expensive.
IBM MQ is the granddaddy of queuing systems and predates most other queuing systems by decades (IIRC it is (ultimately) based on the iSeries/OS400 queuing system). Consequently, it carries a lot of baggage from that time which large ops teams like for tuning to their needs, but which modern systems have largely ignored or modern environments have made redundant.
I suffered under MQ for many years. I never understood what any of it was for, other than the actual queue part (which is what you can get for free from competing products like RabbitMQ, ActiveMQ, Kafka, etc.). And it wasn't because I didn't try to find some documentation...
There's sender channels, receiver channels, xmit queues, local queues, remote queues, dead letter queues, topics, subscriptions and all kinds of other things to learn about. Add that to the crappy IBM tools and their documentation that is full of dead links and you're in for a lot of learning through trial-and-error.