Apache Kafka Reviews

This is a system for email and other small devices. There has been a relay of transactions continuously over the last two years it has been in production.

Besides better stability and scalability, there are no additional functionalities I'd like to see. Kafka is good at what it does.

The management overhead is more compared to the messaging system. There are challenges here and there. Like for long usage, it requires restarts and nodes from time to time.

We started using this solution two years ago.

There are issues with stability. It's not 100% stable like ActiveMQ, but it's maybe 98% stable.

With the containerized version we have used, we have faced challenges with the scalability.

Initial setup was not easy. It requires intermediate skills.

This is an open-source version.

I would rate this solution 8 out of 10.

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.

One of our clients needed to take events out of SAP to stream them through Apache Kafka while applying data enrichment before reaching the consumers.

The solution can handle more speed and has horizontal scalability for both messaging, but more specifically stream processing and data enrichment. By using this solution it can reduce the number of components required in the tech stack. For example, we were taking data events out of SAP and sending them to consumers without having to go through multiple processors that were outside of the KAFKA space. Additionally, we are using Kafka from GoldenGate to propagate database updates in real-time.

The most valuable features are the stream API, consumer groups, and the way that the scaling takes place. 

I would like to see real-time event-based consumption of messages rather than the traditional way through a loop. The traditional messaging system works by listing and looping with a small wait to check to see what the messages are. A push system is where you have something that is ready to receive a message and when the message comes in and hits the partition, it goes straight to the consumer versus the consumer having to pull. I believe this consumer approach is something they are working on and may come in an upcoming release. However, that is message consumption versus message listening.

Confluent created the KSQL language, but they gave it to the open-source community. I would like to see KSQL be able to be used on raw data versus structured and semi-structured data.

I have been using this solution for approximately one year.

The solution is stable.

I have found the Apache Kafka to be highly scalable

The project we were working on was open-source, we were using Confluent as support and they were great.

Apache Kafka on AWS is a bit complex. There is a third-party company called Confluent and they have the support that makes their installation much easier, especially for the on-premise deployment. You install Apache Kafka alone it can be a little complex compared to other queuing messaging solutions.

The on-premise deployment takes approximately a few days. The cloud or hybrid deployments including all the permissions, typologies, firewalls, and networking configuration can take weeks for all the accessibility issues to be resolved. However, the delay could have been client-related and not necessarily the solution.

We provide the implementation service.

Apache Kafka is free. My clients were using Confluent which provides high-quality support and services, and it was relatively expensive for our client. There was a lot of back and forth on negotiating the price.

Confluent has an offering that has Cloud-Based pricing. There are different packages, prices, and capabilities. The highest level being the most expensive. AWS provides services to their market, for example, to have Kafka running. I do not know what the pricing is and I am fairly confident, Azure and GCP provide similar services.

My advice to others wanting to implement this solution is to start with data streaming projects, not simple messaging projects because while it is very good at general-purpose messaging, it is more suited and geared for when you are using it as a streaming solution.

I rate Apache Kafka an eight out of ten.

I'm a software architect. The use case will depend my customers. They usually use it for data transfer from static files to a legacy system.

In the next release, I would like for there to be some authorization features and HTL security. 

We also need bigger software and better monitoring. 

I have been using Apache Kafka for the last ten years. 

The stability is good. We've never had any issues. 

Scalability is very good. 

I have never needed to contact technical support. My colleagues get support from here, in Morrocco. 

The setup is not a big deal for us. We can handle it. After the system is set up, the person who administers it has to do so with Apache Kafka.

Depending on the setup, it will usually take two weeks.

I would rate it a nine out of ten. Not a ten because of the monitoring and admin improvement I'd like for them to make. 

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

I used Kafka with a client to decouple applications with different availability profiles. Before using a messaging-based architecture with Kafka as the messaging system, the client used a coordinator application to fire off various posts to as many as eight other applications. With an application that's impacting at least a customer a second in airports, where the customers demand that the system always works, there were issues with ensuring high availability.

A typical way to calculate system availability is: Availability = Uptime/(Uptime + Downtime). Hence, where there are two applications involved with a 99% availability, the total system availability degrades quickly: 99% * 99% = 98.01%.

With eight applications, total availability caused issues. However, only two systems needed to provide real-time responses, while other systems were for payment processing, CRM, promotions, etc. It was OK if those systems were not up to date in real time.

Kafka allowed the client to have temporal decoupling for writes, i.e., the flaky third-party CRM system did not need to be available at the moment for us to respond to a user with a successful response. The availability concerns shifted to Kafka, which is a better trade off because it's built for this.

Another benefit, though not required, was the addition of logical decoupling between applications. Additional consumers could be built to overlay concerns of analytics, but the systems responsible for creating the entities on a given topic did not need to be aware of the analytics applications. This simplifies the interaction between applications and concerns of an organization.

Another benefit of this architecture is that testing is simplified. A given application needs to be tested to obey a contract of reading a message and producing another message. A Kafka topic acts as the boundary for an integration test.

Kafka, as compared with other messaging system options, is great for large scale message processing applications. It offers high throughput with built-in fault-tolerance and replication.

Messaging systems in general allow for logical and temporal decoupling between applications. Given Kafka's high availability, it's a great option to use if applications require availability, but not real-time processing.

If a downstream system is offline, messages can queue up and process when possible, but the user may not necessarily need to be aware of any issues.

A messaging-based architecture becomes important as a set of micro-services need to scale with high availability. Kafka is a great choice for messaging with such architecture.

Kafka requires non-trivial expertise with DevOps to deploy in production at scale. The organization needs to understand ZooKeeper and Kafka and should consider using additional tools, such as MirrorMaker, so that the organization can survive an availability zone or a region going down.

Shifting availability concerns to Kafka means that it cannot go down. It's important to understand the partitioning model and replication needs before relying on it for critical business functions. I'd suggest using it with a feature toggle for a non-critical path in production and learning from failure before relying on it.

While Kafka is built to scale, that does not mean that applications can start as many consumers or producers without consideration for how Kafka brokers will perform. Considerations about scaling out brokers need to occur before publishing millions of messages.

Generally, there were no stability issues. However, there was one scare in production when a consumer rebalance took 30 minutes and messages were not being processed during that time.

We have not yet had scalability issues!

There are specialized consulting companies in this space and there are online resources to read. That may help companies get past hurdles.

No, we did you use a previous messaging system.

The setup was complex. One must consider setting up ZooKeeper, Kafka, multi-zone/region availability, as well as typical associated functions for running it all in production. This includes monitoring, message schema changes (consider Avro), encrypting messages if it's a concern, potentially authorization for different topics depending up on the sensitivity of data.

If an organization uses Kafka as the first messaging system, then the approach for application design must also shift significantly.

It is open source software.

The client evaluated alternatives before I arrived, but I was not there during the evaluation so I cannot comment.

Consider using a managed Kafka service, such as from Heroku.

If messaging is not a central component of the business and vendor lock-in is less of a concern, consider using something like Amazon's Kinesis. This can more rapidly provide the benefits of a messaging service without the pain of understanding it deeply, setting it up, and managing it.

It's important to use a lean approach to understand how it will break in production.

Implement a non-critical transaction with it.

Perhaps use a feature toggle within a facade and implement the behavior with the old approach and with Kafka to reduce risk.

Add it to one or two applications and monitor how it goes.

Figure out security, monitoring, scaling, schema migration, etc., before using it as a critical component in an application.

Real-time streaming and persistence into distributed nodes. It provides a simple mechanism to create, publish, and subscribe.

We are using Kafka as part of our product. It is one of the messaging layers used to interact between various layers of software modules. This provides a clear separation of modules and leverages it for development and testing of different modules.

The management tools are getting mature. When we have thousands of topics, it is hard to visualize.

I’ve been using Kafka for two years.

We have not encountered any stability issues.

We have to balance the nodes when topics partition across cluster nodes. As it assumes they are of equal sizes, sometimes some nodes may not be allocated similar resources. Reassignment moves all the partitions of specified topics which may be an issue when not planned for.

We have the source code to make changes if necessary.

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

Setting up was easy with ZooKeeper.

With paid support from Confluent, you get the additional benefit of Kafka Connect.

We used Akka Streams for faster communication, but it would require additional configuration and setup for persistence. Kafka provides those by default.

Kafka provides distributed persistence and streaming layers. The user has flexibility in managing as a consumer on how to consume messages if they have to handle resilience in their code. It requires ZooKeeper.

We are a service implementer and we supply this solution to our customers. I'm a company co-founder and we are customers of Apache. 

The solution has improved our functionality, it's one of the best streaming platforms I've used. 

I'd like to see improvement in terms of observability.

I've been using this product for the last five years on and off. 

The solution is stable. 

The solution is scalable.

The initial setup is straightforward, it's not complicated.

This is an open-source product.

I rate this solution nine out of 10.