Apache Kafka Reviews

We use Apache Kafka for financial purposes. Every time one of our subscribed customers is due for an insurance payment, Apache Kafka sends an automated notification to the customer to let them know that their bill is due.

Resiliency is great and also the fact that it handles different data formats. There is one data format that's universal across multiple application domains — Avro. It's pretty universal compared to JSON, XML, SQI, and other formats.

Some vendors don't offer extra features for monitoring. Some come with Linux for default monitoring. Monitoring is very important. If something is not working properly, then our subscribers won't receive a notification. You then have to trace it back to Kafka and find the glitch or the messaging sequence that hasn't been racked up correctly.

It should support Avro — which handles different data formats — as a default data format. It would be much more flexible if it did.

I have been using Apache Kafka for three years.

It seems to be quite stable.

Apache Kafka is Scalable. You can actually launch a server node or a broker. Three nodes and Zookeeper (the Kafka server management system) is optimal. If one of them goes down you can automatically launch another one. You can go three servers or brokers back — there's a repetition on each Kafka broker.

Apache Kafka is open-source. They don't offer technical support.

On a scale from one to ten, I would give Apache Kafka a rating of eight.

Apache Kafka is an open-source solution that can be used for messaging or event processing.

Apache Kafka has performance issues that cause it to lag.

We did a couple of POCs on Apache Kafka for more than two years for messaging and event processing.

I rate Apache Kafka an eight out of ten for stability.

I rate Apache Kafka a seven out of ten for scalability.

Since it's an open-source solution, there is no technical support, and users often rely on the community edition.

I have previously worked with Confluent and Anypoint MQ. Confluent is completely an event-driven architecture. Anypoint MQ is a typical messaging software and cannot be used for an event-driven architecture.

The solution's initial setup is quite straightforward. You just have to upgrade a couple of configuration files.

Apache Kafka is an open-source solution.

A non-enterprise business with a low message load can use an open-source solution like Apache Kafka.

I would recommend the solution to enterprise businesses depending on their use cases. Suppose an enterprise business doesn't have any integration or a middleware platform and wants to do a greenfield implementation. I'll evaluate the use cases and refer Apache Kafka to them if messaging is needed only for exception handling or transferring the messages.

I have recommended Apache Kafka to some customers who wanted asynchronous messaging for logging purposes. Those messages were not business-critical messages as such.

I would recommend Apache Kafka to other users. Apache Kafka is more relevant when we use open-source integrations and when customers want to reduce the TCO. As an architect, I recommend the solution to customers based on their messaging needs. Apache Kafka and Anypoint MQ are the only two messaging products available today. The open-source Apache Kafka is always recommended if the customer really doesn't want to get into any of the license models.

Overall, I rate Apache Kafka an eight out of ten.

Lots of real-time processing and high-velocity data are the use cases.

I'm happy with the scalability and the ability to kind of replay the topics if you wish. So, it can give you that flexibility.

For the original Kafka, there is room for improvement in terms of latency spikes and resource consumption. It consumes a lot of memory.

Resource consumption. It consumes a lot of memory.

I have been using it since 2019. 

I would rate the stability a seven out of ten. There are issues due to latency spikes and resource consumption. It varies quite a bit. It's not very stable. It is a powerful tool; it can work, but it can be problematic sometimes. And that's why I switched to Redpanda.

I would rate the scalability a nine out of ten. One of our clients is an online casino; they have over two million end users. 

I used RabbitMQ. I switched to Kafka because it is just capable of handling a lot more messages.

And that was because the original Kafka had some performance issues, some latency spikes, and things like that.

The initial setup is easy because they provide documents. So, the documentation makes it easy to set up.

The deployment takes a few hours to set up a production environment and configure it in the cluster. It's pretty straightforward and pretty fast.

I figured it out on my own.

There is an ROI. 

If you use Confluent Cloud, it's expensive because it needs updates available in the platform, like AWS. But you only pay for what you use. So it's quite affordable considering the value it provides.

It is affordable for me. 

Overall, I would rate the solution an eight out of ten. I would advise integrating Kafka with Redpanda. It's easier to work with for most people.

We utilize Apache Kafka in several areas, including financials, logistics, and client management to name a few.

We used to lose some of our messages when we integrated them in bulk, this solution has stopped that happening.

It is a useful way to maintain messages and to manage offset from our consumers. 

I would like to see an improvement in authentication management.

We have been using the solution for around four years.

The stability is good; the solution operates on our clusters without a big impact.

It is easy to scale.

We used to use a different solution, but our increased throughput meant we needed a product that would allow for a larger queue.

The initial setup was complex for us because we built it internally. This meant that full deployment took around a month.

The implementation was carried out in-house.

I would recommend that other businesses do the deployment themselves, but manage the tool with the aid of a service provider, rather than in-house.

I would rate this product seven out of ten.

We deploy it for our customers. The main use case is related to log management and metrics because we are a partner of Elastic Stack, and we usually collect information through Kafka.

The high availability is valuable. It is robust, and we can rely on it for a huge amount of data. 

The Kafka Streams capability is also valuable. We get many options to build applications on top of Kafka.

The price for the enterprise version is quite high. It would be better to have a lower price.

I have been working with this solution for four or five years.

It is absolutely stable.

It is very scalable. It is easy to scale it. 

It doesn't matter how many users are using it. The licenses are calculated based on the number of nodes. It is not based on the number of users who are using it. We have between 10 to 20 nodes on average in an organization.

It is quite good, but they don't speak Italian. In Italy, we have to provide support in the Italian language. It is a problem for customers to have support in English. This is the reason why we provide direct support to customers.

I am into pre-sales and project management. I don't usually install Apache Kafka, but its basic installation seems quite simple.

Its deployment is usually quite short. Usually, we are able to deploy it in a few days, but data management and application development can take a few months.

We have our own team to deploy it. We also take care of its maintenance. We have a team of five or six employees to provide 24/7 support to our customers.

It depends on the project. For log management projects, the ROI is not very quick, but we have other projects where we used Kafka for high-value applications, and the ROI was very quick. We got an ROI in a few months.

The price for the enterprise version is quite high.

For on-premise, there is an annual fee, which starts at 60,000 euros, but it is usually higher than 100,000 euros. The cost for a project including the subscription is usually between 100,000 to 200,000 euros. The cost also depends on the level of support. There are two different levels of support.

Kafka is a really good product. To be able to keep it running in the long term, you need to know very well how it works. You should have good knowledge about it. It isn't about just knowing how to install it because it is quite simple to install it. It is important to have the right knowledge and experience to do a good installation and let it run for a long period. You can also go for someone who has the right experience and knowledge.

We are very satisfied with Kafka. I would rate it an eight out of 10. It is not perfect, but it is a really good product.

My primary use case for Apache Kafka is replacing ETL and doing data transformations.

Kafka allows you to handle huge amounts of data and classify it into different categories. If you have huge amounts of data, Kafka is a very good solution for data classification. When you need to route it in different directions, you have to take a look at the messages that you get, interfile them, and then send them to the correct place. Kafka is a good product to use in the backend.

The feature I find most valuable is the classification feature. Kafka enables you to tag content with a category.

Kafka contains two components. The component that does the synchronization between the rest of the components, that's an older version of the software and it causes all kinds of configuration problems. The Confluent, which is the company that sells a commercial version of Kafka is getting away from that component precisely because of that. Kafka is a nightmare to administer.

In the next release, I would like to see that one troublesome component that causes configuration issues removed.

I have been using Apache Kafka for a couple of years.

The stability of this solution depends on whether it is properly configured. Having said that, Kafka is incredibly complex to configure, set up, administer, and maintain.

My opinion is that Apache Kafka is a scalable solution. In our organization, there are hundreds of thousands of users using Kafka.

The initial setup was extremely complex. In our case, it took a team of 12 two months to deploy.

These systems were installed by somebody else, not me.

I would advise others to schedule a month or two to just set it up and have it up and running.

There are other options. For example, Databricks is a Kafka alternative. We decided to go with Kafka because one of our clients already chose Kafka.

While evaluating, we found out Databricks is more expensive, for the level of activity that Kafka handles (in this case, millions of requests per day). Databricks could do it, but it would be overly expensive.

I would rate Apache Kafka's pricing a seven out of ten, with one being cheap and 10 being very expensive.

Since it has become so popular, large enterprises especially want to do it. For smaller enterprises, Kafka would probably be too expensive because they would have to hire people to maintain it.

I would rate the Apache Kafka solution a seven out of ten.

We use Apache Kafka to ingest a lot of data in real time that Apache Spark processes, and the result is used for a tech decision in real time – in the IT environment, infrastructure environment, and IOT environment, like for a  manufacturing plant.

This is an open-source framework. We also sell professional services on this solution and specifically create a business application for customers. 

The application is called Sherlogic. We have two kinds of customers. We have end-user customers that use the Sherlogic solution, and maybe customers don't know that there is Spark and Kafka in Sherlogic. But we have another kind of customer that uses professional services by Xautomata to create tailor-made applications in analytics and the automation process.

We use Apache Kafka for our digital cloud.

To store a large set of analytical data we are using SQL repository. This type of repository works very well but we need specific and high maintenance. The user experience is friendly.

We are looking for alternative solutions, we tried with noSQL solutions and Confluent specific features but the results were not satisfactory both in terms of performance and usability.

We are working on automated SQL repository management and maintenance tools in order to increase the democratization of our platform.

We've been using this solution for a year and a half.

The stability is very nice. We currently manage 50 million events daily.

It's scalable.

Support is good. It's typical for an open source application. You can have all the information in a public portal. If you want specific consulting, there is a company that promotes this consulting worldwide called Conduent. Their consulting is quick and they have a lot of know-how.

It's very complex, like Spark. 

Deployment took 50 minutes for all the Kubernetes ports, Spark, Kafka, and other components based on Sherlogic. In 30 minutes, we created an environment using this program to make installation easier.

Deployment was done in-house, but we're starting a collaboration with another company and we introduced this company to running this solution. Specifically, we started a collaboration with AWS to promote our platform in a Western marketplace. In this way, it's very easy to use our solution because it is a part of an AWS service, certificated by an engineer.

The return on investment has been having people dedicated to this solution because it's open source so it hasn't been necessary to invest in licensing or pay a fee. So, internal know-how has been the ROI.

It's a bit cheaper compared to other Q applications.

I would rate this solution 7 out of 10.

I would recommend this solution because the queue manager is very fast and stable.

We use the product for high-scale distributed messaging. The processing capability of the product is enormous. Being a distributed platform, multiple consumers can sync with it and fetch messages.

Another great feature is the consumer offset log which tells you where the consumer left and where he needs to start again. Consumers aren’t required to code and put extra effort to maintain the offset.

We were using another commercial messaging engine, which was not scalable unless you paid more. Each hub that we provisioned was expensive. This solution is open source, which is much easier to use and doesn’t cost us anything.

This product guarantees at-least-once delivery. We have asked JIRA to provide features such as at-most-once delivery to remove duplicate message consumption.

We haven’t faced any issues so far. Some of the clusters churn millions of records per seconds with ease.

We have clustered environments and we haven’t seen any scalability issues. We can provision a new node in as little as 45 minutes.

It is open source, so support is in our own hands. The only option is to make a new feature request through JIRA. When multiple people in the community make a request for similar feature, it gets priority.

We switched from a previous solution mainly to reduce costs and to have a more scalable solution.

The initial setup was a bit complex in terms of how to manage it across data centers. But once it was setup, we never faced issues.

We evaluated multiple options, such as ActiveMQ and RabbitMQ. We leaned towards this solution.

I would advise others to start with non-SSL implementations and try to do PoCs. Afterwards, they should move towards more secure features.