Apache Kafka Reviews

We use Kafka for Elastic Stack and Kafka SCRAM login.

I have many users of Apache Kafka. It's like a subject to study in enterprises. However, we have not decided if the systems should generalize Apache Kafka for every application and every IT system.

We use Kafka for mapping and ThoughtSpot data from one IT system source to the destination. We also prefer it to exchange data from our internal IT systems.

Kafka is a new method we opted to apply to our need for data exchange. Also, we use the solution's integration capabilities.

Irovement-wise, I would like the solution to have more integration capabilities. Also, the solution's setup, which is currently complex, should be made easier.

I have experience with Apache Kafka.

It is a stable solution.

A lot of my experience indicates that Apache Kafka is scalable. We can have ten or even fifty hundred users on the solution. So, it's possible because we are a big enterprise.

I have experience with Apache Kafka's technical support.

The solution's initial setup process was complex. The deployment process took three or four years.

Right now, I can't deliver the planning process required for deployment.

For deployment and maintenance, we have a manager and an operational person. However, I can't give an exact count of the people required for deployment and maintenance.

To be able to recommend Kafka to others, especially considering every context, we will have to set a benchmark and compare Kafka with other tools.

I rate the overall solution a seven out of ten.

We are using Apache Kafka to extract data from a Portuguese data source, utilizing an open-source project for data capture. The connector for this project is linked to both Kafka and Confluence platforms. We then transform the extracted data and store it in Elasticsearch.

We appreciate the ability to persistently and quickly write data, as well as the flexibility to customize it for multiple customers. Additionally, we like the ability to retain data within Apache Kafka and use features, such as time travel to access past customer data. The connection with other systems, such as Apache Kafka and IBM DB2. 

Apache Kafka can improve by adding a feature out of the box which allows it to deliver only one message.

I have used Apache Kafka within the last 12 months.

Apache Kafka is a stable solution.

The scalability of Apache Kafka is good. It can process many requests simultaneously.

We have approximately 600 people using this solution in my organization.

I have not contacted the support from Apache Kafka.

The initial setup is relatively easy as I am using Docker and the files provided by Confluent. However, setting up Apache Kafka in a production environment is not as straightforward. I prefer to use solutions, such as Confluence that already have everything preconfigured. As a developer, creating an environment for it is not a problem for me, but I think it can be challenging for those responsible for the production environment. There have been issues with data loss and other problems in the past. Configuring it for production is not easy.

My deployment was very quick because I am using it locally. We have someone else that does the cloud deployment.

I did our local implementation and we have someone else that does the cloud deployment.

The price of Apache Kafka is good.

I rate the price of Apache Kafka an eight out of ten.

I don't see any major issues with using Apache Kafka. Many companies use it and it's a good solution. My advice would be to use it as a software-as-a-service rather than setting up your own cluster. This way, you can benefit from a preconfigured and maintained platform. It's better to opt for a software-as-a-service solution.

I rate Apache Kafka an eight out of ten.

We have a scalable architecture where we need multiple workers to handle some processing. To make it possible, the backend catches the request and puts it in a common medium, which is the queue of Apache Kafka. The workers then can share and process it.

The most valuable feature of Apache Kafka is the clustering which is very easy to scale and we have multiple servers all over our platforms. It has been useful for stability and performance.

Apache Kafka can improve by providing a UI for monitoring. There are third-party tools that can do it, but it would be nice if it was already embedded within Apache Kafka.

I have been using Apache Kafka for approximately two years.

Apache Kafka is stable. We have not had any issues.

the scalability of Apache Kafka is good. We have parts of the information we use in different geographical sites and it doesn't pose any problem.

I have not used technical support.

I previously used RabbitMQ. We switched because Apache Kafka was more stable and had better performance.

The initial setup of Apache Kafka was easy because it is Dockerized. However, if you were to install it yourself it would be difficult. Having it Dockerized makes it worth it. 

The first deployment took approximately two hours. The updates of the solution can be done in a matter of minutes.

Our DevOps team in our IT department did the deployment of the solution. It was mostly virtual work. The maintenance of the solution does not take a lot of time.

We are using the free version of Apache Kafka.

We had a good experience with the solutions, the maintainability and scalability are good. I would recommend the solution to others.

I rate Apache Kafka a nine out of ten.

We use Apache Kafka to process messages, specifically payment type messages, and incorporate the data from those messages into our analytics and reporting. It utilizes data from additional sources in real-time for our analytics and reporting purposes.

The real-time nature and the ability to use multiple offsets are the most beneficial features of Apache Kafka for our data streaming needs. This allows us to replay the same messages using different offsets. Although I haven't set up Kafka's scalability and fault tolerance myself, I know it can be configured with redundancy and fallback options. We primarily consume the messages using different clients, so the setup for fault tolerance and redundancy is transparent to us.

It's quite flexible and comparable to other solutions like ActiveMQ in terms of features and guarantees, especially with offsets for message handling. While ActiveMQ may be preferred in some use cases requiring guaranteed message delivery, Kafka's offset management provides similar functionality. Overall, I would recommend Kafka for real-time data streaming without hesitation.

The main challenge we faced while integrating Apache Kafka with other tools was setting up SSL and securing connections. Managing certificate changes and ensuring all clients connect smoothly, especially outside Kubernetes environments, posed ongoing challenges. Once initially set up, maintaining and sharing these security configurations became more manageable, but ensuring compatibility across different environments remained a continuous effort.

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

I would rate the scalability nine out of ten.

The technical support, typical for open-source solutions, is also responsive and helpful.

Positive

We switched to Kafka from paid solutions like IBM's MQ due to cost considerations, finding Kafka's multiple offsets and popularity advantageous.

As for pricing, Kafka is open-source, so it's free to install and use.

I was planning to use the tool for real-time analysis in terms of data processing and real-time analytics workflows. The real-time IoT data comes through with a few challenges, and that is for one time, so it is more like a Kafka topic. I want to actually use multiple Kafka topics where one of them can be directly fed into the data pipeline, another one can be fed into the real-time alert system, and the next one can be fed into machine learning.

The most valuable features of the solution revolve around areas like the latency part, where the tool offers very little latency and the sequencing part. The sequencing part actually helps to aggregate things in a way that I don't need to write another function or kind of sequence it, and I write an aggregate function to figure out the maximum value in the last ten samples.

One complexity that I faced with the tool stems from the fact that since it is not kind of a stand-alone application, it won't integrate with native cloud, like AWS or Azure. Apache Kafka has another mask on it, so if users can have a direct service, like Grafana, that can actually be used as a stand-alone tool with Grafana cloud, or you can use a mix of AWS and Grafana, so there is not much difference with it. I expect Apache Kafka to have Grafana's same nature.

The product's support and the cloud integration capabilities are areas of concern where improvements are required.

I have been using Apache Kafka for a year.

Stability-wise, I rate the solution an eight out of ten.

Scalability-wise, I rate the solution an eight out of ten.

Around four people in my company use the product.

I did not interact much with the product technical support team. I did not have dedicated support that responded to all my queries since I was using the product's free version. I rate the support a seven out of ten.

Neutral

I have worked with Databricks. I use Databricks and Apache Kafka simultaneously.

The product's deployment phase is neither complex nor straightforward. As the software has evolved a lot, users can actually keep it even simpler by opting for a plug-and-play model.

The solution is deployed on an on-premises model.

The solution can be deployed in two or three days.

I was involved with the tool's installation process.

I cannot comment on the tool's ROI since I did not use it for production purposes.

I was using the product's free version.

I did not come across any scenarios involving fault tolerance because when it comes to the issue data consistency issues, like missing or incorrect value of data are actually part of the system where the data is being fed. Nevertheless here, when it comes to the missing values, I never tried the option, especially whenever a value is missing, that can allow one to impute the value with another parameter.

Speaking about if I incorporated any emerging data stream streaming trends in Apache Kafka workflows, for example, utilization of AI, I would say that I use it as a local system, so if I have an EC2 server where I kind of read the sample and then populate the regression and reintegration model on top of it, but that is done locally and not on the cloud.

I recommend the product to those who plan to use it. I like Kafka and Flink, and I want to actually create a system in AWS mainly for real-time streaming so that I don't need to worry about multiple data copies.

Considering the improvements needed in the product's support, and the cloud integration capabilities, while looking at the simplicity during the installation phase, I rate the tool a seven out of ten.

We use Apache Kafka for patching real-time data that we receive over a data transport layer and for putting the data into Apache Kafka. From Apache Kafka, we use several applications to subscribe to topics from different applications that we serve directly to browsers. Additionally, we use these applications inside our solution and have Apache Kafka Stream, which is connected to MongoDB.

Since we receive data in real-time consisting of IoT devices, running vehicles, their locations, their states, and their VNs, the solution is helpful.

The product could be improved with proper documentation. Proper documentation should be the SSE. We have a challenge with configuration, so it isn't easy to configure a standalone Apache Kafka on the premises. It needs to be set up on-premises and surveys being provided in the market want to be excluded. Hence, being a developer and configuring Apache Kafka is very hard. It is user-friendly, but initially, we found it challenging. Improving the documentation in this solution would be much better if documents were provided on GitHub for different things. As the market is growing, Spring solution is working hard to get products in the market so when Python, React JS, and Node.Js came, they were lacking. But today, Spring Boot has a solid framework. So the support on Apache Kafka could be improved, but finding some configurations with Spring Boot isn't easy.

We have been using this solution for over three years and are currently using the latest version.

The solution is stable, and the most fantastic thing about it is its throughput. For example, I have tried MQs, which also have Apache Kafka Streams. So the throughput of Apache Kafka Stream is impeccable and impressive.

The solution is very scalable, and its availability is brilliant. We have approximately 32,000 people on our customer base.

We do not have any experience with customer service and support.

We have tried different MQs, but the subscription and charting available on this solution are better. We have used Queues previously, but this solution is more stable, so we chose it.

The initial setup is dependent on the individual. For example, it would be straightforward if a person practices these things a lot and understands the documentation correctly. However, since most people prefer examples instead of reviewing documentation, it would be easy to set up if they find steps on the internet but difficult if they do not have examples.

I rate the pricing for this solution an eight out of ten. It could be a bit cheaper.

I rate this solution an eight out of ten. It is good, but the documentation could be improved.

Our primary use case of this solution is for data integration and for real-time data consumption. I'm a senior staff engineer for data and infrastructure and we are customers of Apache. 

I love the simplicity of the library and the design as well as the architectural concept which is like horizontal scaling.

When compared to other commercial competitors, Kafka doesn't have the ability to scale down, the elasticity is lacking in the product. The other issue for us is the delayed queue, which was available to us in the commercial software but not in Kafka. It's something we use in most of our applications for deferred processing and I know it's available in other solutions. I'd like to see some tooling support and language support in the open source version. 

I've been using this solution for four years.

The stability is good. 

The solution scales horizontally and scales better than its competitors. We have around 400 to 500 microservices consuming this cluster and the company has around 600 employees. We have four different verticals, each with around 100 engineers with 100 to 150 microservices. 90% of the microservices have a touchpoint with Kafka.

I think the community is very good and will respond if you raise a ticket. We also use external third-party libraries that were built in GitHub. It would be good to have some direct support from Apache.

Four years ago we were using Rabbit MQ but we switched to Kafka because Rabbit was designed for a very narrow use case. It became difficult for us to run and maintain that server and our client libraries. We had a huge outage, so we shifted to Kafka because of the simplicity in the architecture.

The initial setup was simple although we had a couple of hiccups. It took around a week but that was several years ago and we haven't had any problems since. Our team carried out the deployment and we currently have a few engineers who deal with maintenance. 

We are currently using the open-source version. 

There is room for improvement with this solution so I rate it eight out of 10. 

I have a lot of messages, and we need to process those messages from many clients. Each client takes those messages and processes them.

I'm using the brokerage partner. I'm not storing or maintaining the application on servers. I'm just a client for the Apache Kafka server.

The solution is deployed on-prem.

Apache Kafka has improved our organization because it's more reliable than Rabbit. That's the whole point for us.

The most valuable feature is the messaging function and reliability.

Something that could be improved is having an interface to monitor the consuming rate. We use something, but I'm not sure if it's from Apache Kafka, or if it's a borrowed third-party solution. So, the interface for monitoring the processes is an additional feature that could be added.

I have been using this solution for two years.

The solution is pretty stable compared to Rabbit or other brokers. 

The solution is scalable. We have about 10 departments that use Kafka in various forms. Each department might have 5 or 10 people.

We use the solution all the time. We have consumers that consume messages that come every day because we have clients and customers for the main website. All of those messages go to KAF clients. Our backend departments consume messages from the actions of the final customers.

We used Rabbit and we switched to Kafka because it seemed like an upgrade in ability, reliability, and in the consuming process of broker messages.

Implementations took half a year for everyone to learn the solution. It was quite lengthy.

I would rate this solution 9 out of 10.

My advice is to take some time in investigating how to implement the solution.

We used to require about half a year to implement in our organization. Someone who needs to implement Kafka has to be prepared for a quite lengthy process. Don't expect implementation to be completed in a week. It's a little bit longer because it's complex.