Apache Kafka is an open-source stream processing platform developed by the Apache Software Foundation written in Scala and Java. The Kafka event streaming platform is used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.
N/A
IBM MQ
Score 9.6 out of 10
N/A
IBM MQ (formerly WebSphere MQ and MQSeries) is messaging middleware.
N/A
Pricing
Apache Kafka
IBM MQ
Editions & Modules
No answers on this topic
No answers on this topic
Offerings
Pricing Offerings
Apache Kafka
IBM MQ
Free Trial
No
Yes
Free/Freemium Version
No
Yes
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
—
—
More Pricing Information
Community Pulse
Apache Kafka
IBM MQ
TrustRadius Insights
Apache Kafka
IBM MQ
Highlights
Research Team Insight
Published
Apache Kafka and IBM MQ are both messaging queue tools built to help IT systems communicate with each other in an asynchronous manner. Apache Kafka is designed to enable the streaming of real time data feeds and is an open source tool that users can access for free. IBM MQ is a traditional message queue system that allows multiple subscribers to pull messages from the end of the queue. Both tools are most popular with mid-sized businesses and large enterprises that are more likely to have complex IT infrastructures that need to communicate with each other.
Features
Both Apache Kafka and IBM MQ allow systems to send messages to each other asynchronously, but they also have a few standout features that set them apart from each other.
Apache Kafka utilized pull based communication, meaning that the receiving system requests a message from the producing system. This method of communication makes Apache Kafka faster than most traditional message queue systems. As businesses add more nodes to Apache Kafka, they will also find that it scales well, and notice few performance dips. Lastly, messages in Apache Kafka are not deleted upon the receiving system reading them, so it is easier to log events using Apache Kafka compared to other options.
IBM MQ is a more traditional message queue system that uses push based communication, in which a message producing system pushes its message into the queue and any receiver can consume it. This type of communication allows multiple systems to pull the same message from the queue at once. IBM MQ also includes several advanced features for security and message simplification.
Limitations
Though Apache Kafka and IBM MQ can both act as effective message borokers, they also have some limitations that are important to consider.
Apache Kafka can get a message from one system to it’s receiver quickly compared to traditional message queue tools, but each receiver must make a request for the message, rather than the producing system placing the message into an accessible queue. Additionally, while Apache Kafka can be used to log events and scales well, it doesn’t include as many granular features for security and message simplification. Apache Kafka is ideal for teams that value speed and performance highly.
IBM MQ is a robust traditional message queue system, but it doesn’t match the speed of Apache Kafka. Users should expect messages to take longer to complete in IBM MQ and will have a harder time using it to log events. As a result, IBM MQ is an ideal choice for businesses with complex IT infrastructures that often send messages from one system to many other systems, and who can benefit from granular customization features.
Pricing
Apache Kafka is an open source tool, so its pricing depends on the hosting service. Businesses should expect to pay at least $0.42 per hour, with that rate increasing as messaging needs increase.
IBM MQ is provided through IBM’s cloud service, pricing is dependent on the amount of client connections needed and users can reach out to the vendor for a detailed quote.
For brokering messages, Confluent Kafka is well suited since it offers a managed solution ready to use. Scenarios where the solution is not very well suited are for example, where pricing is an issue. The solution costs quite a lot for basic usage (for example: for 3 clusters, pricing is above 100k$ a year).
As we have critical data such as payments which needs to be managed across a number of platforms.
MQ ensures guaranteed delivery of this data.
Setting up a new application to use MQ is a relatively simple process.
To track data both internally and externally you can set MQ up to send back acknowledgement . Very useful if one party say they have not received some data.
Not suited.
If an application has a requirement to get information from a database without any concerns of losing data . Using JDBC connecting directly to the database can reduces the number of jumps the application needs to make to get to the database.
If an application wants to store information and then send as a large batch file it is not recommended to use MQ. MQ applications should be used for data which needs to be sent immediately. MFT (MQ file transfer) however can utilise MQ for file transfers
Apache Kafka is able to handle a large number of I/Os (writes) using 3-4 cheap servers.
It scales very well over large workloads and can handle extreme-scale deployments (eg. Linkedin with 300 billion user events each day).
The same Kafka setup can be used as a messaging bus, storage system or a log aggregator making it easy to maintain as one system feeding multiple applications.
The documentation is very clear,It is understandable and the support helps to configure it in the best way.
Server guidelines make it possible to get the most out of work management. It's broad, we can work with different operating systems, I really recommend using linux.
It is highly compatible with systems, brockers, applications, and data accumulation programs, it is possible to configure everything so that after the installation of programs, they can communicate with each other and then throw data to an external program that accumulates it and represents in clear details of steps to follow and make business decisions.
The Kafka Tool is a community-made Java application that looks and feels from the past century.
Logging can be confusing. This certainly shows when we have to do troubleshooting.
Hybrid scenarios - pub/sub, but there are services in and outside a Kubernetes cluster. Then there are a ~3 options, but only 2 (the harder ones) are production-safe.
I can only speak wonders about the program; I think it is a program with enough serious track record to meet the company's expectations. However, it should be noted that I could suggest that promotional packages be made from time to time for those of us who are already clients of more than one year.
In every sense, the program fulfills what it promises, which is to generate a good connection and cohesion of programs to be able to make commitments between them.
Kafka has suited our use case very well so far. Going forward we are planning to expand our platform manifold so the load on Kafka and our reliance on Kafka is going to increase only.
Apache Kafka is highly recommended to develop loosely coupled, real-time processing applications. Also, Apache Kafka provides property based configuration. Producer, Consumer and broker contain their own separate property file
I give it a nine because it has significantly improved my team's data reliability and operational efficiency. Its great security features give us peace of mind, knowing our sensitive data is well protected. While the setup might initially be complex, I believe the long-term benefits far outweigh this hurdle.
As I have said before, the program is stable; I think that is the great reason why it has been maintained for years and days in the company; despite the hard use that we have given it, it has behaved well during both day and night shifts.
Support for Apache Kafka (if willing to pay) is available from Confluent that includes the same time that created Kafka at Linkedin so they know this software in and out. Moreover, Apache Kafka is well known and best practices documents and deployment scenarios are easily available for download. For example, from eBay, Linkedin, Uber, and NYTimes.
The IBM Support team has offered unmatched insight. Their personnel helped us actualize several things that seemed impossible before. You see, previously we would develop a software solution, but it would take months before rolling it out mostly because we had further build additional specific interfaces. The support team suggested we procure App Connect alongside MQ. Right now, we just hop into the IBM MQ platform, connect the software with AppConnect, and a few modifications are done, then it's ready within a few days.
Apache Kafka is built for scale. From high throughput and real-time data streaming, it has a strong advantage over RabbitMQ with its low latency. This put Apache Kafka at the forefront as the platform of choice for large datasets messaging and ensuring scalability when data scale up tremendously. RabbitMQ however has its strengths in traditional messaging. Routing and message delivery reliability are the bedrock of RabbitMQ and this is where RabbitMQ excels. In my previous workplace, RabbitMQ was of choice as reliability matters more than scale. In two words. Apache Kafka for scale, RabbitMQ for reliability. And for cloud deployment and large dataset messaging in what I am doing now, Apache Kafka is the default choice.
Kafka is renowned for its impressive throughput, fault tolerance, and real-time data streaming capabilities. Nonetheless, IBM MQ remains the preferred choice due to its unwavering commitment to guaranteed delivery and exceptional reliability. Fault-Tolerant Architectures of IBM MQ which allows active-standby queue managers, to build fault-tolerant architectures that ensure continuity of service in the event of hardware or software failures.
Positive: bursts of traffic on special holidays are easy to handle because Kafka can absorb and buffer all the messages we need to process long enough to let an understaffed set of back-end services catch up on processing. Hard to put a number to it but we probably save $5k a month having fewer machines running.
Positive: makes decoupling the web and API services from the deeper back-end services easier by providing topics as an interface. This allowed us to split up our teams and have them develop independently of each other, speeding up software development.
Negative: our engineers have made mistakes such as accidentally dropping a few thousand messages due to the CLI being confusing to use, and as a result a customer lost some of their precious data. I'd say that was more our fault than Kafka's though.
