Switch from IBM MQ to Confluent Kafka

Presently, we have this architecture in IBM MQ .

On sender we have Queue Manager, Remote Queue, Sender Channel & Transmission Local Queue
On receiver, we have Queue Manager, Receiver Channel and a Local Queue

My new boss asked me, why do we have this distributed architecture? I am not sure why is this like, as this was setup before my time. Any ideas any one?

Second, he wants to replace this with Confluent Kafka. After some research I came up with this solution:

Sender & Receiver each having: 3 Zookeepers, 5 Brokers and 3 Kafka Connect Servers. Total 22 servers!

Is this illogical, any comments from Kafka/MQ experienced guys?

Thanks in advance.

Addressing your two questions separately as I understand them:

Q: Why use IBM MQ instead of Apache Kafka?
A: Why not? :smiley: If IBM MQ is working for you, then use IBM MQ. If you are hitting certain constraints around performance, or you want additional functionality that Apache Kafka would offer then that would be a good reason to use it.

This whitepaper might be of interest to you.

Q: Sender & Receiver each having: 3 Zookeepers, 5 Brokers and 3 Kafka Connect Servers. Total 22 servers! Is this illogical, any comments from Kafka/MQ experienced guys?

It hugely depends on what you’re building, the kind of throughput you need, availability requirements, and so on. This Enterprise Reference Architecture is a great place to start.

1 Like

That is an amazing answer. Could not have been answered any better.
Thank you and god bless you.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.