Apache Kafka Reviews

We use the solution for analytics for streaming. We also use it for fraud detection.

The Kafka Streams library gives quite a bit of functionality. The connectors provided by the solution are valuable.

The ability to connect the producers and consumers must be improved. It's still a pain point because a lot of development goes into it.

I have been using the solution for seven to eight years.

For what it does, the tool is very stable. It is a message broker. It receives the messages and holds them for producers and consumers. It's usually everything around Kafka that has stability problems because Kafka does exactly what it's supposed to do.

Scalability is one of the main selling points of the tool. The additional nodes we add give us the additional storage capacity we need. I rate the scalability a ten out of ten. The solution is used across multiple domains in our organization. I use the product daily. It’s a continuously growing platform.

Apache doesn't provide support. There are sites we can go to for information, but there's no support team for Apache. There are companies like Confluent and HPE that provide support for the solution.

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.

It is super easy to set up. I rate the ease of setup a ten out of ten. However, building and administration get quite difficult. It takes three months to make things production-ready.

The deployment was done in-house. We used the tools that we have in our CI/CD pipeline. We needed three people for the deployment. The infrastructure team maintains the tool. The infrastructure team has three to ten members.

We see an ROI on the product. If we don't have a tool to buffer the amount of traffic coming in from high-traffic sites, we cannot use the data. Apache Kafka gives us a resting area where we can push as much information as we want to. It’s picked up by consumers when they need it.

It’s a huge return on investment. Otherwise, we must have a system tied to the producer waiting for the consumer to consume before we can do anything with the rest of the messages. A solution like Kafka provides us with a buffer to consume the data as we choose to.

The price depends on who we are getting the product from. If we buy it from Confluent, we always have to try to negotiate the price. The price is always negotiable.

Overall, I rate the product a six out of ten.

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 are using Kafka consumer and producer.

We are using Kafka as MQ; our servers generate events which are being sent to Kafka. From Kafka, we have several consumers like Secor (https://github.com/pinterest/secor) that upload raw data to S3; Spark stream that is doing aggregations and saving the result in Cassandra; and Druid for OLAP.

• Maintenance: Sometimes brokers disconnect and there are repartitions issues.
• Built-in monitoring application for Kafka infrastructure.
• UI for Kafka would also be great (similar to http://www.kafkatool.com/).

I have used this product for two years.

We used to have problems in Kafka every three weeks and our dev ops team fixed a few issues. For the last six months, there have been no production problems, but during the time Kafka was not stable, it was not easy to understand what was wrong and how to fix it.

We have not encountered any scalability issues yet. We are growing and currently, we manage 1M events per second in Kafka.

We need more documentation regarding maintenance issues.

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).

We did not evaluate other options as Apache Kafka is the standard.

Read the documentation and understand the offset issues (where to save them, read from start to end).

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.

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. 

We are currently using this solution on our cloud-based clusters.

We use Kafka as part of our services. Our product (cloud clusters) has many components and Kafka is one of them.

For example, we use Kafka as a data integration tool. If you take Oracle GoldenGate as a typical use case, what happens is GoldenGate collects the data for the replication and sends this data to the Kafka servers. We collect the data on the Kafka servers, and we create some transformations, some operations, from that data. We then copy the data to the HTTP or hub site.

Previously, when I worked at Nokia, we were collected data using Kafka and then we stored the data on the Kafka servers. We did all transformations through Kafka streaming. Later, Kafka moved data over to the HP site. 

Kafka has a good storage layer on its side. I can store this data if it's streaming, and, if we do encounter any error, for example, on the network or server, we can later use the data to do some analytics on it using the Kafka server.

Kafka provides us with a way to store the data used for analytics. That's the big selling point. There's very good log management. 

Kafka provides many APIs that can be flexible and can be placed or expanded using the development life cycle. For example, using Java, I can customize the API according to our customers' demands. I can expand the functionality according to our customer demands as well. It's also possible to create some models. It allows for more flexibility than much of the competition.

If the graphical user interface was easier for the Kafka administration it would be much better. Right now, you need to use the program with a command-line interface. If the graphical user interface was easier, it could be a better product.

I've been using the solution for more than three years.

The solution can be quite stable. We haven't encountered any issues on the Kafka side. However, Creating custom stabilizations would be good for dealing with stabilizing issues.

The scalability of the solution is very good. You can analyze system events horizontally and the cluster can be brought over to the cloud side with the Kafka user's server.

We use the solution for both small and medium-sized organizations, but also larger enterprises. Some of our clients are in the banking and financial sector.

Officially, I did not create any Kafka support tasks on the configuration support that is offered. I have created some questions on the stack overflow, however. Technical support is very good and I've found their response is very quick, giving you an answer within a day.

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.

The initial setup isn't too complex. I know Kafka very well and don't find it to be overly difficult. There's also very good documentation which users can take advantage of.

Deployment, including security integration, only took about one day.

Two people handled the deployment. One person created the authentification group and after creating groups and users, another handled topic authentification and user definition for the customer.

I handled the implementation for cloud-based clusters. I defined the broker nodes and other nodes for Kafka. We are a cloud integrator, so we handled it ourselves.

I'm unaware of the costs surrounding licensing and setup.

We're using the 2.1.30 version of the solution for our cloud-based clusters. We use the on-premises deployment model. Most customers use the on-premise solution for cloud-based clusters.

Kafka is a very good solution for log management. If you need anything done related to log management, Kafka can do it. Kafka can also store the data in the brokers. This prevents data loss as well as the duplication of data. It's quite comprehensive.

I'd rate the solution seven out of ten. If the solution could provide a user interface I'd rate it higher. This is important for managing Kafka's clusters on the administration side. It would also be helpful if two to three files could be minimized to one configuration file.

• Supports more than 10,000 events/second.
• Scalability
• Replication

It is a good product for event-driven architecture.

We use Kafka for reactive architecture, track and trace, mail and parcel.

A good free monitor tool would be great for Apache Kafka (from Apache foundation).

We used Kafka 0.8 for 2 years and Kafka 0.10 for 3 months.

We have not encountered any stability issues.

We have not encountered any scalability issues.

We haven’t used technical support.

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

The basic configuration is quite good. We have built a Hadoop cluster and the Kafka service was included.

We use a community version.

Kafka processes asynchronous exchanges, so there are no transactional interactions.

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.