Apache Kafka Reviews

Currently, I work for an observability company. We stream customer data into our cloud, digest the information, enrich it, transform it, save it, and use on-the-fly aggregation with Kafka. Previously, I worked for a security company doing normal detection using streaming with Kafka. 

I also worked for a company with a data platform based on Kafka, where we ingested clickstream data and enriched it before streaming.

The most valuable feature of Kafka is the Kafka Streams client. Unlike other systems like Flink or Spark Streaming, you don't need a separate engine to do real-time transformations and analytics. The amount of data that can be streamed into the platform and the scalability are also significant benefits.

Kafka requires fine-tuning to find the best architecture, number of nodes, and partitions for your use case. It’s a trial-and-error process with no one-size-fits-all solution. Issues may arise until it’s appropriately tuned. 

While it can scale out efficiently, scaling down is more challenging, making deleting data or reducing activity harder.

I have been working with the Kafka product for more than ten years.

Since Kafka is written in Java, it's not as stable as it should be on the JVM. The stability depends on fine-tuning the system to find the best architecture for your use case. However, the replication factor helps avoid data loss despite the stability issues.

Kafka's architecture allows for scalability by adding nodes and partitions to topics. However, it's not as effective in scaling in, making reducing activity and deleting data harder. 

Scalability can be managed both manually and automatically to meet demands.

I used to work with Spark Streaming and Flink, however, not in the past year.

If you are unfamiliar with Kafka, setting up the cluster can be quite difficult. You need to understand the architecture and components and compute the data volume upfront. For experienced individuals, the setup is less difficult yet still requires preparation.

From a time-saving perspective, onboarding new customers is straightforward, requiring them merely to stream their data into our platform.

We use Apache Kafka, which is open-source, so we don't have fees. I can't comment on ownership costs as I am not responsible for that domain.

Apart from Kafka, I have experience working with Spark Streaming and Flink.

When implementing Kafka, it's important to plan the cluster size upfront to ensure easy scalability. Adding or removing nodes can disrupt the clusters, so proper sizing and planning are key. 

I would rate Kafka as a solution as a nine.

We use Kafka daily for our messaging queue to reduce costs because we have a lot of consumers, producers, and repeat messages. Our company has only one system built on Apache Kafka because it's based on microservices, so all of the applications can communicate using it.

Kafka is an open-source tool that's easy to use in our country, and the command line interface is powerful. 

The user interface is one weakness. Sometimes, our data isn't as accessible as we'd like. It takes a lot of work to retrieve the data and the index.

I've used Kafka for about 10 months.

Kafka is stable.

We can't access support because we are in Iran, and many countries prohibit business with Iran. 

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 rate Kafka 10 out of 10 for ease of setup. It's easy for us because we use Docker, but if you want to use another system like Linux it may be a little challenging

Kafka is free. 

Redis has an open-source solution, but I'm not sure about IBM. I haven't researched it. 

I rate Apache Kafka seven out of 10. It's a good solution. They're constantly fixing bugs and adding new features. 

Our primary use cases allow software developers, and application developers, the option to not have to code in their own logic for the retry mechanism. A lot of software, and applications, have this feature of retry built in some way or the other, but they all have some kind of a pre-alpha version of Kafka, up to a certain extent.

So it is a good backbone for microservices. So basically you want to write microservices, which you can shut down and bring it up whenever you want. You want to be able to shut it down to actually replace it with a newer version and bring it up. The bottom line is you can kill the microservice and bring it back up and do all the things that you want to do with it. But whenever it comes back up, it should pick up and run from where it had left off. That is what everybody tries to do. And in order to build such a system, they have to write several logical pieces of code, and most of that code has already been built for in Kafka so that you don't have to do it yourself.

One of the most valuable features I have found is Kafka Connect.

Basically, the bootup time, if you have large messages, sometimes takes up more time than I would really like it to. So that is the area that Kafka can actually improve upon. But that is okay, the way we get around it is to make sure that Kafka has started up first and warmed up before anything else starts up. I would also like to see monitoring service tools.

I have been using Apache Kafka for the past three years.

The stability is good as long as you have a short retention period.

Confluent is the cloud version of Apache Kafka and it is scalable.

We do the implementation in-house.

If you are managing your own implementation the return on investment is pretty good. What you need is good developers.

Apache Kafka has open-source pricing.

Apache Kafka is a good choice, so I would recommend people not have a real-time application if they do not have to. It is better to have a very fast batch operation than a real-time operation. I would rate Apache Kafka a nine on a scale of one to ten.

We are always using Apache Kafka for our real-time scenarios. It helps us detect anomalies and attacks on our website through machine learning models.

We are managing our data by topics. Splitting topics is more effective for us. Apache Kafka is very fast and stable. It offers scalability with ease and also integrates well with our tools. Fault tolerance is a good feature, and it also has high throughput rates.

Config management can be better. We are always trying to find the best configs, which is a challenge.

I have been working with Apache Kafka for more than four years. It has been used since the beginning of our department, maybe six years.

It is very stable and meets our needs consistently.

If there is latency, our Kubernetes admin includes our Kafka nodes to increase scalability. Kafka provides flexibility and integrates easily with Kubernetes.

Before Apache Airflow, I used Cron Tab. However, Apache Airflow makes it easy to follow and manage tasks, and data science departments can easily build their models or pipelines using it.

I would rate Apache Kafka nine out of ten.

We have multiple use cases for our Kafka system. One is Kafka Connect, which is used to facilitate communication between different regions with Grid Deal. Another is to distribute events and projects to multiple downstream. We publish all the messages to Kafka and other listeners subscribe and write them to different MQs. Lastly, Kafka Connect is used especially for inter-application communication.

We had been using a lot of expensive licenses earlier, such as SOLEIL, as well as some legacy versions, which were not only costly but also caused memory issues and required highly technical personnel to manage. This posed a huge challenge in terms of resourcing and cost, and it simply wasn't worth investing more in. However, Kafka was comparatively free as it was open source, and we were able to build our own monitoring system on top of it. Kafka is an open-source platform that allows us to develop modern solutions with relative ease. Additionally, there are many resources available in the market to quickly train personnel to work with this platform. Kafka is user-friendly and does not require an extensive learning curve, unlike other tools. Furthermore, the configuration is straightforward. All in all, Kafka provides us with a great platform to build upon with minimal effort.

The use of Kafka's logging mechanism has been extremely beneficial for us, as it allows us to sequence messages, track pointers, and manage memory without having to create multiple copies. We are currently on a legacy version and have found that the latest version of Kafka has solved many of the issues we were facing, such as sequencing, memory management, and more. Additionally, the fact that it is open source is a major benefit.

Multiple people have constructed conflict resolution with successful solutions on top of open-source platforms. Unfortunately, open source does not have the monitoring and capabilities these solutions offer, so organizations must create their own. Investing in these solutions may be beneficial for many companies, who prefer to use open-source options. 

There is a lot of information available for the solution and it can be overwhelming to sort through. The solution can improve by including user-friendly documentation.

I have been using the solution for four years.

We have not experienced any issues with the stability of the solution. We had some issues with Grid Gain and Kafka Connect, but we believe it was more of an issue on Grid Gain's side since they informed us of a bug. Our result has been that we have not encountered many issues on the Kafka side.

We use the solution in the distributed mode in multiple regions – the US, London, and Hong Kong. We have increased the number of nodes to ensure it is available to us at all times.

I give the scalability an eight out of ten.

We have around 600 people within my team using the solution.

The initial setup was relatively easy for us since we already had Zookeeper and the necessary setup in place. We also had good knowledge of Kafka. Therefore, it was not a difficult challenge. In general, I believe that it is manageable. There are benefits and the setup is not overly complex.

Our company has implemented Ship, making our lives easier when it comes to changes or version updates. We can package everything in one place and deploy it with Ship, then implement the virtual number with a minimum of 50 changes.

Deployment time depends on our location and the task at hand. Initially, there is a lot of setup and configuration that must be done, but this can become easier with experience. Nowadays, the process is not too difficult, as all the version numbers and conflict files are already in place. However, if this is a new task for us, it may take some time to figure out all the configurations.

One person was dedicated to deploying Kafka. This person got help from our release team, who had already set up Zookeeper and other necessary components.

The implementation was completed in-house.

I give the solution an eight out of ten.

Maintaining Kafka, the open source, can be difficult without the proper version purchased or the right infrastructure in place. However, once the initial setup is complete, it is relatively simple to maintain. The open-source version of Kafka is not a complete package, so additional maintenance may be required.

I strongly recommend reading the documentation for any issues because it is likely to contain the answer we are looking for. There is a lot of information provided that may not be immediately obvious, so take the time to explore thoroughly.

Apache Kafka is a messaging solution where you have topics to pass on your information. You can send messages to multiple topics.

We need to manage limited resources. Additionally, we can send or push messages through a specified port. This is a significant feature because, unlike traditional queues, Kafka uses a cluster of nodes, making it easy to integrate with various algorithms. This clustering is an advantage and a key feature of Kafka, providing good interaction and scalability.

For example, when you want to send a message to inform all your clients about a new feature, you can publish that message to a single topic in Apache Kafka. This allows all clients subscribed to that topic to receive the message. On the other hand, if you need to send billing information to a specific customer, you can publish that message on a topic dedicated to that customer. This message can then be sent as an SMS to the customer, allowing them to view it on their mobile device.

Apache Kafka is different in its design. If you have topics around the front end of clusters in the facility, it is scalable. The software is scalable to handle and process data. However, it might not be suitable for handling specific types of images or media files. Other than that, it should handle the rest of the data processing needs.

There are no multiple versions, which simplifies the process of granting access with Kaspersky. Every message is accurately delivered. However, Kafka does not support sending messages directly. You need to publish messages finalization. If you want to resend a message, you must resend it manually. Kafka does not automatically handle this. Another thing is the need for a redo option if an issue occurs. If a message is not sent properly, it can be retransmitted within the core system. You should enable the gateway in your program for it to function correctly. Messages will not be delivered or refreshed unless you enable the direct replay option in the product settings.

I have been using Apache Kafka since 2020-21

The initial setup of Apache Kafka is challenging and requires experience. Each message should always receive a response, so prioritizing traffic is essential. Furthermore, the client or consumer must always be in sync, or the message will not be processed.

One pair of nodes is sufficient for the system. If our other system requires more than five nodes, it might not be feasible. Currently, other components are functioning as expected. The Kafka setup won't take much time.

When using Apache Kafka, it’s important to manage different environments carefully to avoid confusion. For instance, you can configure different client applications for producing and consuming messages. Ensure that the configurations for each environment (development, testing, production, etc.) are separated. This includes managing source code and data appropriately to maintain security and efficiency. Proper management of Kafka assets and operations phases is crucial for a smooth workflow.

I recommend Apache Kafka since it is extremely fast, stable and has been used for a very long time. We haven't encountered any major issues or concerns regarding its performance and customer service.

Overall, I rate the solution a nine out of ten.

I have previous professional experience using Kafka to implement a system related to gathering software events in one centralized location. 

One example of how Kafka has been beneficial is in the context of financial trading. When a trade is executed, it generates an event. I used Kafka to create an application that captures these events and stores them in a topic, allowing for efficient processing in real time.

Regarding the most valuable feature in Kafka, I would say it's scalability. The publisher-subscriber pattern and low latency are also essential features that greatly piqued my interest.

Maintaining and configuring Apache Kafka can be challenging, especially when you want to fine-tune its behavior. It involves configuring traffic partitioning, understanding retention times, and dealing with various variables. Monitoring and optimizing its behavior can also be difficult.

Perhaps a more straightforward approach could be using messaging queues instead of the publish-subscribe pattern. Some solutions may not require the complex features of Apache Kafka, and a messaging queue with Kafka's capabilities might provide a more complete messaging solution for events and messages.

I have been using Apache Kafka for the past 10 years. 

The stability may improve if the configuration and management aspects become less challenging.

It depends on the configuration., but scalability is one of the best features of Kafka. I would rate it nine out of ten.

Support can vary depending on whether you're using the open source version or a paid one. Our version, the paid console version, offers highly available support, and you can find a wealth of information and assistance from various providers online. However, when I used MSA on AWS, I encountered limited support for it.

Neutral

Despite the challenges we faced with configuration and management, I believe the return on investment is safeguarded.

The cost can vary depending on the provider and the specific flavor or version you use. I'm not very knowledgeable about the pricing details.

I believe that when working with Kafka Apache, it's essential to have a specialist who thoroughly understands and can optimize all the available variables within the solution to achieve the desired behavior.

I would rate it an eight out of ten.

We used Kafka as a central message bus, transporting data from SNMP through to a database. Some of the processing in between was handled by other components.

We built a solution for a client and the client was happy with the solution.

The message bus capabilities, basically sending messages to it, and the way it handles events or messages is pretty good. The throughput was good. Generally, it was a good component.

We struggled a bit with the built-in data transformations because it was a challenge to get them up and running the way we wanted. There was a bit of a learning curve. It may be that we didn't fully grasp the information.

Also, the documentation covering certain aspects was a bit poor. We had to trawl around different locations to try to find what we needed. When we were able to find documentation on transformation, for example, there wasn't a good set of documentation examples we could use, and the examples we had weren't quite meeting the need. Better examples would've helped us.

I used this solution for about a year and a half. 

It seemed pretty stable and didn't have any issues at all.

I don't know how many people were using it on the client's side, but we had a four-person team doing the development work. 

Our team handled the deployment in-house.

Kafka is an open-source solution, so there are no licensing costs. There are third-party companies who support and provide add-ons to Kafka, but we didn't need to use any of those. Confluence, for example, provides plug-ins for Kafka. 

There were other solutions, like Apache MQ, but there were a number of components we looked at that were based around being a message bus, and Kafka was the winner from that review work.

The documentation can be a challenge. There are quite advanced capabilities of Kafka, like the transformations that you can build to modify the data as needed. We found that the biggest challenge was documentation and being able to gain the knowledge of exactly how to do stuff. We also struggled on the transformation, but other components were fine, so some parts are good, and some parts are bad.

I would rate this solution as an eight out of ten.