My company started off with Apache Kafka, so they did not use any other solutions previously.

We previously used IBM MQ, Tipco, and AMQ.

We used MSMQ on Windows, but we decided to migrate our system to Docker and we wanted to use base Linux, so we move them from Amazon Queue to Kafka.

Apache Kafka has one advantage that sets it apart from other providers. We need to iterate on the messages, but others don't have this feature. Kafka has partitioning, which is useful, so we decided to go with Kafka. 

I previously used RabbitMQ. We switched because Apache Kafka was more stable and had better performance.

I have previously worked with Confluent and Anypoint MQ. Confluent is completely an event-driven architecture. Anypoint MQ is a typical messaging software and cannot be used for an event-driven architecture.

Prior to implementing this solution, we were not using another solution. We have been using, Kafka from the beginning with regard to these use cases. However, we are using other queuing solutions, such as MQ, ActiveMQ, IBM IQ, and Q, but the use cases are different. This is primarily due to the large volume, faster processing, and other benefits of using Kafka.

We have tried different MQs, but the subscription and charting available on this solution are better. We have used Queues previously, but this solution is more stable, so we chose it.

We used to use a different solution, but our increased throughput meant we needed a product that would allow for a larger queue.

We used Linksys for visualization along with Confluence, but there needed to be more value. For us, Apache Kafka is the best solution based on the support and third-party systems as it builds our subsystems around because we have a lot of development teams.

We switched from a previous solution mainly to reduce costs and to have a more scalable solution.

Since we are supporting various different messaging applications, we tend to use and support all the messaging applications that are popular. Like SQS, Google pops up, Active MQ, Rapid MQ, MQTT, and IBM MQ.

Four years ago we were using Rabbit MQ but we switched to Kafka because Rabbit was designed for a very narrow use case. It became difficult for us to run and maintain that server and our client libraries. We had a huge outage, so we shifted to Kafka because of the simplicity in the architecture.

We have been experimenting with other solutions such as VMware RabbitMQ and Pulsar.

We are going to replace the Apache Kafka solution using Pulsar.

Pulsar gives more scalability to an even grouping, but Apache Kafka is used more if you want to send something in a time series-based. If this does not matter to you then Pulsar could be more customizable. Apache Kafka is nothing but a streaming system with local storage. Apache Kafka fits into many use cases, it's very direct, but if you want more specific use cases and you use Apache Kafka, Pulsar could be considered.

Prior to working with Apache Kafka, there was no messaging queue system. For many projects, they were using the Azure Event Hub, but it was not serving the purpose. So, we started moving towards Kafka, and that's why we have procured Confluent Kafka.

Several months ago, I stopped working on Apache Kafka. I am now working on Confluent Kafka. It was not my decision to switch solutions.

My current organization has chosen Confluent Kafka for various reasons. One is that we have a large number of streaming requirements, and Confluent Kafka has one more layer on top of Apache Kafka to do this transformation and connecting with other multiple lane systems.

There are out-of-the-box features along with the KSQL features. For example, things like fetching the events are kind of query-based. So, that seems to be a good feature for our requirements. That is why we ultimately procured Confluent Kafka.

For some time, I have also worked with Solace and it has an advantage. Given that my core strength is integration, I work with integration platforms such as MuleSoft, Azure functions, then TIBCO. Based on our requirements, I found that the event-driven APA implementation with Solace was easier.

Solace also has a top-notch solution for portal management and you register your producers, consumers, and preprocessing logic. All of these things are pretty easy to do. This is an area where Kafka could use some enhancement.

We did use other solutions previously but this solution makes things a lot easier.

I have only used Apache Kafka.

I have customers who were using IBM MQ but they have been switching to open-source.

We also use Flink and other streaming tools. We use Apache Kafka in addition to other technologies because of the requirement and the business use cases.

We used Rabbit and we switched to Kafka because it seemed like an upgrade in ability, reliability, and in the consuming process of broker messages.

We used traditional message queues and file semaphores. There was a lot of overhead with asynchronous messages being put into an order and making sure nothing got dropped. It required a lot of code and maintenance.

Before Kafka, I sent feeds directly to Hadoop.

We previously used Mosquitto and Rabbit solutions, but we currently use Apache Kafka.

We started to use Apache Kafka with our application from scratch.

I think performance-wise, the product is very good and fits in our use case. We used other distributed message queues, but all products have their own use case

We did not have any other previous solutions. Our project was green field and a new type of project development.

This is the first product we have used. We didn't have anything prior to that.

I used RabbitMQ and ActiveMQ. Kafka is the standard, so there is no question what to use (unless you need better performance, like in ZeroMQ).

No, we did you use a previous messaging system.

Kafka rendered itself suitable for our product offering. It supports all the necessary requirements for a real-time pipeline.

I also have experience with IBM MQ.

We used RabbitMQ before. It does not scale well.

The previous solution was not really an equivalent one. I have been using several messaging systems, but Kafka fits us better for a more scalable system.

We previously used rsync, which was not real-time.

We previously used ActiveMQ for another project.

I have also used IBM MQ and Kafka is much easier to use. However, IBM MQ is better for large deployments.

We were using ActiveMQ, which is just a messaging system. We are changing because of Kafka’s added value of scalability, retention, and high payload support.

Apache MQ is different. It is a message bus (log rotate) than can manage more than 10,000 events/sec.

We didn't previously use a different solution. We did some applications with Java for the consumer content but not the application function within that. We did objects instead.

For big data, we did not have a previous solution. I have used Microsoft MQ for building traditional systems.

We didn’t have a previous solution. We started with Kafka and then switched to Amazon Kinesis (PaaS for Kafka). I think Microsoft Azure also released a competing service.

Some of our clients are using Apache, while others are using other solutions. It depends on the company and its unique requirements.

Previously, I worked with IBM MQ, a different type of messaging platform.

I previously used IBM MQ. 

I have used IBM MQ and it is better in terms of the adapters that are available. However, the price of IBM MQ is very high.

We also use IBM MQ. It is also a stable product.

IBM MQ is probably easier to deploy than Kafka.

In addition to these, I have also worked with RabbitMQ.