Apache Kafka Reviews

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. 

• Message Retention: Unlike regular message queues, messages stay in Kafka after clients consume them. A message can be consumed over and over again by the same or a different client until topic retention (by max data size or oldest message timestamp) kicks in and the oldest messages get deleted. This can be very handy in many scenarios: handling bugs in software, testing code, simple distribution of message processing, and routing messages to many different consumers simultaneously.
• Horizontal Scalability: To add more capacity, both in terms of storage and performance to a Kafka cluster, you just need to add more servers. Regular message queues usually work in a master-slave configuration and do not scale very well horizontally.
• Simplicity in operations.

It has become dead simple to connect different application and services, saving a lot of development hours.

The standard Kafka Java library, which is shipped with the product, is too complex for inexperienced users. At my company, engineering teams ended up writing wrapper libraries to solve complex issues. Kafka client libraries in general are complex, regardless of language. This is the price Kafka users have to pay for having simple, yet robust, server-side code.

What could be improved is the hard dependency on ZooKeeper. The work in this direction has already been started, though. Overall, the project is moving forward at a very good pace

I have used Kafka for three years.

Sometimes we have stability issues, but not often.

We have not had any scalability issues.

There is no official technical support as the product is 100% open source.

We used RabbitMQ before. It does not scale well.

The setup was pretty straightforward.

There is no pricing and licensing.

We didn't evaluate any other options.

Go ahead. It's a great product.

Kafka was at the base of our system architecture. The system was designed as an event based architecture. Almost all the interactions among micro-services and the same data are used as input to our analytics infrastructure.

• Scalability
• Reliability
• Ease of use

Stability of the API and the technical support could be improved.

The Kafka API is changing quite radically with the different releases. There are many new improvements and that's good. But the inherent cost of adapting to a new version of the platform was worrying me at the time.

The documentation was sometimes misleading, since it was describing some feature in the new version of the API rather than the one we were using.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

We were not completely satisfied with the technical support. We subscribed to the Confluent professional platform to receive guidance and support on development and deployment. Whilst the development side is quite well covered by their consultants, the deployment and administration is not at the same level.

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.

The initial setup was straightforward.

I would not subscribe to the Confluent platform, but rather stay on the free open source version. The extra cost wasn't justified.

We didn't evaluate other options, as we already had a positive experience across the team with Kafka. Everybody agreed to work with it.

We were considering Kinesis too, since we were running on AWS. We preferred to opt for a tool with which people were more familiar.

The product is easy to use. However, to leverage its power, there is a need for good knowledge of event based processing. I suggest using the massive amount of material shared by the Confluent team, or what is available online.

One of the best features which I have worked with is replay.

Real-time log aggregation which was earlier done with rsync has been moved to Kafka infrastructure along with other real-time streams.

• GUI for Kafka infrastructure monitoring and deployment

I have used it for two years.

Documentation is quite comprehensive.

I found it very stable.

No issues with scalability.

We used the open-source version.

We used the open-source version.

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

Initial setup was mostly intuitive (based on rsync).

Implementation was in-house based on the open-source version.

Target was to achieve real-time service.

Before choosing this product, we did not evaluate other options.

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 deployed this solution in a project for one of our customers to synchronize the different applications; to transport information from one application to another. I'm a program manager and we are customers of Apache.

This solution is robust and delivers messages quickly. It's a simple but good product.

The management tool could be improved.

I've been using this solution for the past few months. 

In this project, we used Kafka to synchronize 28 nodes spread out nationally and it seems scalable. We plan to consolidate the 28 nodes for national integration of nodes and schemas.

We didn't need to contact technical support. We just allotted the software, installed it and started working with it. We carried out a lot of testing pre-development. Development was done with a company that previously used Kafka so we were able to exchange technical information. 

We previously used ActiveMQ for another project.

The initial setup was a little complex. We carried out the development ourselves. 

Our clients purchased the license and they think it's an affordable solution. 

I recommend this solution, we're probably going to use it again in another project.

I rate this solution eight out of 10. 

We use Kafka for event monitoring.

Everything in Kafka is amazing.

The most valuable feature for us is the event monitoring.

It is easy to configure.

This solution could be made easier to manage.

Compatibility with other solutions and integration with other tools can be improved.

We cannot apply all of our security requirements because it is hard to upload them.

We have not experienced any bugs or glitches.

It is easy to scale. This is a new project so we only have about five users right now.

I have not been in contact with technical support.

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

The initial setup was straightforward.

We deployed this solution ourselves.

Apache Kafka is a good solution with many good features but for large deployments, I would choose IBM MQ over Kafka.

I would rate this solution a seven out of ten.

We get amazing throughput. We don't get any delay. 

The manageability should be improved. There are lots of things we need to manage and it should have a function that enables us to manage them all cohesively. There should be a default property. It's really hard to manage all these things.

I have been using Apache Kafka for around six months. 

It is really stable. The stability is really good. I just installed it on my local machine. 

It is scalable. 

I use it 24/7. We have to change both packets to Kafka and from Kafka it receives data. We retain the packet for only six seconds.

I haven't needed to contact their customer support. It's quite simple. I didn't need to contact them to manage my application. 

It's wasn't so easy for me to deploy. 

My advice would be to go through the documents and understand the topics. Learn what its effects are and take care of partitioning. 

Based on my experience, I would rate it an eight out of ten. It's quite complicated and the configuration requires a lot of effort. As a developer it is quite hard to go into all these things.