Apache Kafka Reviews

We are a solution provider and Apache Kafka is being used in our client's company.

The most valuable feature is the support for a high volume of data.

The initial setup and deployment could be less complex.

Integration is one of the main concerns that we have.

We have been using Apache Kafka for two years.

Kafka is a stable product.

This is a scalable solution.

The technical support is quite good, and we have no problem with it.

We also use IBM MQ. It is also a stable product.

IBM MQ is probably easier to deploy than Kafka.

In addition to these, I have also worked with RabbitMQ.

Deploying Kafka is more complex than IBM MQ.

My customer has asked me to choose between IBM MQ and Apache Kafka. I will be comparing these two solutions in the near future. My impression is that Kafka is going to better suit my customer, but I have to consider their specific needs before I can be sure.

This is a solution that I may recommend, but its suitability depends on the needs and requirements.

I would rate this solution an eight out of ten.

I am a user, as well as an integrator for our clients. This is one of the products that we implement for others.

The most valuable features of this solution is the architectural style of messaging or event streaming. First is important to understand that anything can be represented as an event=message e.g new order, status change, confirmation, information from IoT or from monitoring system. Each message can be transport very quickly from the source (producer) into consumer(s). Messages can be changed in the fly - streaming messaging.

Messages can be process exactly at once or at least once. Ordering of messages depends on just configuration setup. 

When comparing it with other messaging and integration platforms, this is one of the best rated. Message store is out of the box functionality. Messages are automatically stored based on parameter setup of retention policy. Messages can remain for longer, which can be configured from a few milliseconds up to years. Scalability and availability of messages can be changed with zero maintenance window.

You don't need extra clusters to achieve high availability for the messaging system like Veritas, PowerHA or other.

One platform for classical messaging, real time messaging, ETL, message streaming. 

ETL can be realised with connectors into external systems which also could run in more instances. Exists a lot of ready to use connectors and new ones can be developed.

The model where you create the integration or the integration scenario needs improvement. It contains fewer developer words or maintaining words where someone prepared the topics, the connectors, or the streaming platforms. You would first need to have a control center from a third party for managing. 

If you would like to prepare something that is a more sophisticated integration scenario, where you use one microservice to provide the event or a second to several that consumed these microservices, then this needs to be modeled elsewhere. 

Also, when comparing to the traditional ESD for data mixing, you can create a scenario that could be deployed with inputs and some outputs.

Most business like the topics, but for me, I think that it is a problem that messaging platforms have, there is no design tool with IDE for creating.

It would be helpful to create a more complex solution for several types of styles, and not just for one provider or for one customer. That would be easier, but if you have more than one consumer then it could be a more complex scenario. It would be like events that go to several microservers to create orders, validate orders, and creating words. This would be helpful.

In the next release, adding some IDE or developing tools, for creating better integration scenarios, even though it already a developer-oriented solution, would be helpful. It would also be helpful for the auto-deployment.

Having a governance style would also be helpful to understand. 

It would be beneficial to have a repository of all of the topics, data types that exist, or data structures.

I have been working with this solution for one year.

It's a stable solution.

Kafka is very scalable, which is an important feature of it.

Our clients have approximately ten applications in their companies that communicate with Kafka.

I have not contacted technical support through Kafka, I communicate directly with Confluence. Confluence is the company that developed the open-source platform and they provide support.

The communication is very good and they are very capable of assisting you with all technical inquiries.

There are direct contacts that make it easy.

Previously, I worked with IBM MQ, a different type of messaging platform.

For the most part, the initial setup is easy, but if you need a more sophisticated infrastructure or if you have to set up the topics, then you have to be careful and you have to be more knowledgable in Kafka. You will have to know the parameters for the rotations, the size of the message, and the timeouts, as an example.

For a developer it is easy, but for an administrator and production, it requires more.

Apache Kafka is an open-source solution and there are no fees, but there are fees associated with confluence, which are based on subscription.

I would recommend trying this solution. 

Take the time to understand it because it is a different style when it comes to working with data.

I would rate this solution a nine out of ten.

Apache Kafka is used for stream processing, metric and log aggregations, and as a message queue for connecting different microservices.

The stream processing is a very valuable aspect of the solution for us.

Due to the fact that the solution is open source, it has a zookeeper dependency. If I could change anything about the solution, it would be that.

The solution could always add a few more features to enhance its usage.

I've been with the company for at least one year, which is for how long I've been using the solution.

The stability of the solution is very good, even for large enterprise-level organizations. It's quite reliable. There aren't bugs or glitches that affect it. The solution doesn't crash.

The solution is scalable, however, it's a 50/50 endeavor. It may require some management to build it out.

The solution is open source, so there isn't technical support per se. The open-source community that surrounds the technology, however, is very good.

That said, our company provides technical support to our clients if they need it. It's 24/7 support and we try to reply within 20 minutes of receiving a request.

Some of our clients are using Apache, while others are using other solutions. It depends on the company and its unique requirements.

The difficulty or simplicity of the initial setup varies. It really depends on the organization and its requirements and infrastructure.

Deployment times vary. It can be up to a week in production, however, with some products online, some services can be deployed within minutes.

When you have already deployed the solution, and it's installed, it doesn't require very much maintenance. If it needs any, my company handles it for our clients. We have an entire team that can work on it.

The solution is open source; it's free to use.

What happens in our company is a little different. We basically provide services to other companies through Kafka, like our management services. It doesn't necessarily mean we're using the solution ourselves, however, we will be going and deploying Kafka for companies, like a systems integrator.

The version of the solution is normally 2.4, however, it depends on the requirements. Our cloud providers are always different due to the fact that the countries that we work with are all different. For example, in the US it could Amazon, Azure, or Google. It varies.

I'd advise other organizations considering using the solution to make sure they understand what the use case is. They need to know what their services will be and if they will be directed to Apache Kafka.

From a customer perspective, potential companies need to make sure they have an idea of how big it's going to be due to the fact that it's a cluster environment. It needs to be taken care of. Customers will need to know things like what is the message rate is which is coming into Kafka and how they will connect all those different microservices or any services together to Kafka.

From an infrastructure perspective, it's more of how big of a cluster a company needs. Who would be the producers to produce it, and who's the consumer who's consuming the data are a few questions that need to be asked.

I'd rate the solution eight 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 get amazing throughput. We don't get any delay. 

The manageability should be improved. There are lots of things we need to manage and it should have a function that enables us to manage them all cohesively. There should be a default property. It's really hard to manage all these things.

I have been using Apache Kafka for around six months. 

It is really stable. The stability is really good. I just installed it on my local machine. 

It is scalable. 

I use it 24/7. We have to change both packets to Kafka and from Kafka it receives data. We retain the packet for only six seconds.

I haven't needed to contact their customer support. It's quite simple. I didn't need to contact them to manage my application. 

It's wasn't so easy for me to deploy. 

My advice would be to go through the documents and understand the topics. Learn what its effects are and take care of partitioning. 

Based on my experience, I would rate it an eight out of ten. It's quite complicated and the configuration requires a lot of effort. As a developer it is quite hard to go into all these things.

I am an enterprise architect involved in Big Data and integration projects using Apache Kafa. We use it for integrating our different management systems.

The most important feature for me is the guaranteed delivery of messages from producers to consumers.

More adapters for connecting to different systems need to be available.

I have been using Kafka for about six months.

This is a stable solution and we haven't had any complexities.

This solution is scalable.

I have used IBM MQ and it is better in terms of the adapters that are available. However, the price of IBM MQ is very high.

The initial setup is easy.

Kafka is more reasonably priced than IBM MQ.

Although we are deployed on-premises at the moment, we are looking to have a cloud-based deployment in a year or two.

This is a solution that I can recommend but it will take a lot of time to develop the adapters.

I would rate this solution a seven out of ten.

I am a solution architect and this is one of the products that I implement for my customers.

Kafka works well when subscribes want to stream data for specific topics.

The most valuable feature is the performance.

Kafka is complex and there is a little bit of a learning curve.

I have been using Apache Kafka for between one and two years.

Resilience-wise, Kafka is very good.

Kafka is a very scalable system. You can have multiple, scalable architectures.

I have not seen any problems with technical support. There is licensed support available, which is not the case with all open-source solutions. Open-source products often have issues when it comes to getting support.

I have customers who were using IBM MQ but they have been switching to open-source.

The initial setup was straightforward for me. However, it is not straightforward for everyone because there are some tricky things to implement. In single-mode it is a little bit easier, but when it is set up as a distributed system then it is more complex because there are a lot of things to be considered.

Kafka is open-source and it is cheaper than any other product.

There is a competing open-source solution called NATS but I see that Apache Kafka is widely used in many places.

Performance-wise, Kafka is better than any of the other products.

This is currently the product that I am recommending to customers. Some customers want an open-source solution.

There are some newer products that are coming on to the market that are even faster than Kafka but this solution is very resilient.

In the long run, I think that open-source will dominate the pace.

I would rate this solution a seven out of ten.

We primarily use the solution for big data. We often get a million messages per second, and with such a high output we use Kafka to help us handle it. 

When we're working with big data, we need a throughput computing panel, which is something that Kafka provides, and something we find extremely valuable. It helps us support computing and ensures there's no loss of data. It can even do replication with some data.

The delivery of data is it's most valuable aspect.

It's an easy to use product overall.

The solution is quite mature.

It's an open-source product, which means it doesn't cost us anything to use it.

We're still going through the solution. Right now, I can't suggest any features that might be missing. I don't see where there can be an improvement in that regard.

The speed isn't as fast as RabbitMQ, even though the solution touts itself as very quick. It could be faster. They should work to make it at least as fast as RabbitMQ.

The UI is based on command line. It would be helpful if they could come up with a simpler user interface.

They should make it easier to configure items on the solution.

The solution would benefit from the addition of better monitoring tools.

I've been using the solution for six months.

The solution is a bit slow in comparison to RabbitMQ. It's supposed to be a very fast solution, and it has okay performance, but speed-wise, it's quite slow.

The scaling of the solution is quite good.

In terms of technical support, we don't get that directly from Apache Kafka. We have certain cloud data distribution so we get assistance from our cloud data support.

We're continuously deploying the product. We're still in the process of deployment.

It's an open-source product, so the pricing isn't an issue. It's free to use. We don't have costs associated with it.

I'm not the product owner, so I didn't have a say in what should be chosen. We were seeing a high throughput with Kafka which is why we ultimately chose it.

 I'd rate the solution eight out of ten. It's good at scaling, and, performance-wise, it's excellent. If they could add upon the UI and allow for easier configuration, I'd rate them higher.