Apache Kafka Reviews

We use Apache Kafka for financial purposes. Every time one of our subscribed customers is due for an insurance payment, Apache Kafka sends an automated notification to the customer to let them know that their bill is due.

Resiliency is great and also the fact that it handles different data formats. There is one data format that's universal across multiple application domains — Avro. It's pretty universal compared to JSON, XML, SQI, and other formats.

Some vendors don't offer extra features for monitoring. Some come with Linux for default monitoring. Monitoring is very important. If something is not working properly, then our subscribers won't receive a notification. You then have to trace it back to Kafka and find the glitch or the messaging sequence that hasn't been racked up correctly.

It should support Avro — which handles different data formats — as a default data format. It would be much more flexible if it did.

I have been using Apache Kafka for three years.

It seems to be quite stable.

Apache Kafka is Scalable. You can actually launch a server node or a broker. Three nodes and Zookeeper (the Kafka server management system) is optimal. If one of them goes down you can automatically launch another one. You can go three servers or brokers back — there's a repetition on each Kafka broker.

Apache Kafka is open-source. They don't offer technical support.

On a scale from one to ten, I would give Apache Kafka a rating of eight.

I am a solution architect and I used Apache Kafka in this role.

The processing power of Apache Kafka is good when you have requirements for high throughput and a large number of consumers. 

They need to have a proper portal to do everything because, at this moment, Kafka is lagging in this regard. It could be used to do the preprocessing or the configurations, instead of directly doing it on the queues or the topics. If you look at Solace, for example, they have come up with a portal where you don't need to touch these activities. You don't need to access the platform beyond the portal.

I have used Apache Kafka for between one and one and a half years.

Apache Kafka is stable.

This is certainly a scalable product. There are currently 30 or more people using it but we expect to scale beyond this. It is going to be an enterprise tool within the company.

I am not directly interacting with the service people at this moment. It is limited for now because we are still exploring and effecting our architecture and design, and deciding how to align it with our existing strategy. There is not much progress in this regard and it will take more time.

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.

I don't think that the initial setup was a complex process.

MQ messaging systems are not my core strength but for any integration platform where we have a large number of APIs and events, to integrate with an IoT platform, for example, I found Kafka is better than ActiveMQ.

I'm not getting into in MQTT or other things but comparatively, when you compare ActiveMQ and Kafka, Kafka has done better.

I think that many people are using Apache Kafka just as a publishing and subscription model, but I feel that Kafka is better than that. Furthermore, Confluent Kafka is even more than that.

Confluent Kafka is offering features that are equal to those of a data lake. You can do lots with data, and huge data can be persisted. However, many people are not using that feature. Rather than make use of persistence logic, they are pushing the messages and consuming them. Maybe if people were using it for persistence, they would see the impact or real power of Kafka.

I would rate this solution a seven out of ten.

Our company provides services and we use Apache Kafka as part of the solution that we provide to clients.

One of the use cases is to collect all of the data from multiple endpoints and provide it to the users. Our application integrates with Kafka as a consumer using the API, and then sends information to the users who connect. 

The most valuable feature is that it can handle high volume.

Apache Kafa is open-source and some of our clients are interested in becoming more involved in that.

Kafka does not provide control over the message queue, so we do not know whether we are experiencing lost or duplicate messages. Better control over the message queue would be an improvement. Solutions such as ActiveMQ do afford better control. Because of this, there is sometimes a gap in the results where we have either lost messages, or there are duplicates.

We have had problems when there was an imbalance because all of the messages were being sent back.

I'm a beginner with Apache Kafka.

I cannot judge stability without having better control over the message queue, although I feel that it is not 100% stable. 

We have not been in contact with technical support. For our first implementation with it, Kafka was already set up and running. When we did our PoC, I was not part of the team who was facing issues and it was they who were in contact with support.

I also have experience with IBM MQ.

We had problems when we were setting up Kafka ourselves to conduct our PoC internally. Kafka would not start and it was related to parameters or property settings in Java. We were able to work around it, but we had problems like adding certificates.

In one case, we were using Kafka after it had already been set up, externally. It worked fine and we just had to configure some of the connectors that we wanted to try out.

Apache Kafka is open-source and can be used free of charge.

In this type of solution, you need to be able to accept a high volume of messages, but not lose any, and not have any duplicates. Because we are unable to control the queue in Kafka, I cannot say that this works 100%.

The suitability of this solution depends on the use cases. There are two or three things that we are worried about, and we will be very careful in choosing solutions. In cases where the messages are well organized, or there is no worry that there will be duplicate or dropped messages, then I recommend using Kafka. Also, I recommend this solution for those looking to get involved with open-source applications.

Other than the problems with having no control over the queue, Apache Kafka is wonderful.

I would rate this solution an eight out of ten.

We use an open-source version of this solution, and we have two deployments of it. One is on-prem, and the other is in the cloud. We use the on-prem version to aggregate our logs. We use the cloud version to manage queues for financial services. 

It just works and it's super fast. We were struggling with a Rabbit MQ cluster, so the Apache cluster is way easier.

I would like them to reduce the learning curve around the creation of brokers and topics. They also need to improve on the concept of the partitions. 

As for features, RabbitMQ has an instant response feature where you can send a queue and get an instant response, but Kafka only has one way to send queues. If that's something they could improve on, it would be great.

This is my second year working with this solution. 

I think it's very stable. I would rate the stability as a four or five out of five. 

The solution is very scalable. We started with a cluster of three and then scaled it to seven. I would give the solution a five out of five for scalability. Currently, we have 20+ employees on the technical team that are using the solution. 

We provide outsource services for other institutions. There is a whole set queue management form, and we have about five institutions, with three technical teams that use the same cluster.

There was a little learning curve, but we managed it. I think it took us around six weeks to complete the deployment. 

We have a team of three people who handled the deployment in-house. They also handle the maintenance for the solution. 

We do not use customer support, but there is a lot of documentation available.

I would definitely recommend this solution to other people. I would rate it as an eight out of ten. 

Our primary use case for this solution is streaming.

We have been using this solution for four years.

The solution is stable. However, it's not possible to substitute IBM MQ with Apache Kafka because the JMS part is not very stable. It is inadequate and doesn't have the support of the MQI interface of IBM MQ.

The solution is scalable. Deployment is speedy, but we don't have many installations. We have over a thousand users using this solution and will most likely increase the number of users because we have tested 100,000 messages per second. The solution is impressive.

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

We are licensed annually for this solution.

I rate this solution a nine out of ten for streaming. I recommend it to other people. The solution is good, but its performance can be improved.

We use Apache Kafka for our messaging. 

We publish a message and ask the subscriber to listen to it. We use it to save events generated by integration with external systems. There are external events, that are first published to our Kafka queue, and then to a topic, and then we save it to our own data storage system.

I believe that the speed, and especially the performance, are very good features.

Also included is a cluster with built-in failover. 

It is the performance that is really meaningful.

In terms of features, we are satisfied. I don't require any additional features. I don't believe we require any additional features at this time.

More Windows support, I believe, is one area where it can improve. We need to wrap it as a service, but there isn't one built into Windows. So that's something they could improve.

I believe Windows Server is primarily aimed at the Windows shop or those who use Windows.

I don't recall the specific version that we are using, it may be Kafka 2.11, but it is not the latest one.

It's stable. However, the Windows Service is not very stable because it is a wrapper.

We are a small team with a few people.

We might increase our usage in the future.

We don't get in touch with technical support. We rely on open-source software. We haven't used the help of technical support. We did not seek assistance. As a result, I have no opinion on the subject.

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

The initial setup is straightforward. It's easy to set up.

It took a few days to get it up and running.

We only need one or two engineers to keep this solution running. We basically let it run and monitor what's going on. We usually don't touch it unless something goes wrong.

We deployed it ourselves.

It's free. We use the free version.

VMware RabbitMQ and ActiveMQ are products that are not being used by us. I wanted to look into it. But we use different things.

We compared our findings to those of other researchers. We are primarily concerned with performance. Kafka is unquestionably the performance leader.

I would recommend trying this solution, but you should probably run it on Linux.

I like this product, I would rate Apache Kafka a nine out of ten.

I like Kafka's flexibility, stability, reliability, and robustness.

Kafka has a lot of monitors, but sometimes it's most important to just have a simple monitor. Improvements to Kafka's management would be nice, but it's not so necessary for me. There are a lot of consoles that offer a better view than Kafka. Some are free, and some are paid, but I'm thinking about streaming. For example, if you connect more streams to a component in the same queue, how will it integrate to recognize the flow and the message?

I've been using Kafka for more than two years.

Kafka is stable. Defining our user base is hard because Kafka influences the whole company, so you could say around 100 users. Kafka is a core system, so it affects all users we choose to link to the primary key.

I previously used IBM MQ. 

The first time we tried to deploy Kafka, it seemed a little complicated, but the second try went better. Sometimes it isn't easy to set up the necessary communication or estimate how many partitions we need. Some applications have a vast amount of data, so we have to consider how to improve the performance and not increase the transfer times.

I rate Apache Kafka nine out of 10. I think it's one of the best tools on the internet.

Our primary use case is based on the writing microservices, event architecture and using Kafka as an event bus. We work on distribution - enterprise-grade - and we design, develop and deploy in a confluent environment. We are customers of Kafka and I'm the chief technology officer.

In my view, valuable features relate to microservices architecture and working on KStream and KSQL DB as a microservices event bus. The solution integrates very well. 

The graphical user environment is currently lacking in Apache. It's not available within the solution and needs to be built from scratch. Some of the open source products of this solution have limitations. 

I've been using this solution for four years. 

The solution is stable. 

We are still in phase one so haven't yet tested scalability. That will come when we move to the second phase. We currently have around 15 users of this solution. 

Support is on a subscription-based model but we haven't had any contact with technical support. 

The licensing for this solution is pay-as-you-use.

I rate this solution an eight out of 10.