Apache Kafka Reviews

We are in the early stages of testing this solution in our lab as a demo. It is in development and we are not in production at this point.

We are using this solution to relay events when they happen to multiple receivers at once to allow better functionality.

Apache Kafka has helped our client's online restaurant company by allowing them to take any orders and send the notifications with some other details, such as logic commands, to the different microservices.

The valuable features are the group community and support.

The solution can improve by having automation for developers. We have done many manual calculations and it has been difficult but if it was automated it would be much better.

I have been using this solution for approximately three months.

The solution's scalability is important for our ability to have more throughput from multiple receivers. If we need more throughput it can deliver.

We did use other solutions previously but this solution makes things a lot easier.

The installation is fairly easy. Additionally, there is a cloud-based version available if a use case requires it.

We did the implementation ourselves.

The solution is free, it is open-source.

There is a lot of configuration involved in this solution. We have found many configurations that have helped us but it would be beneficial if there was automation. 

I rate Apache Kafka a five out of ten.

Our primary use case is based on the writing microservices, event architecture and using Kafka as an event bus. We work on distribution - enterprise-grade - and we design, develop and deploy in a confluent environment. We are customers of Kafka and I'm the chief technology officer.

In my view, valuable features relate to microservices architecture and working on KStream and KSQL DB as a microservices event bus. The solution integrates very well. 

The graphical user environment is currently lacking in Apache. It's not available within the solution and needs to be built from scratch. Some of the open source products of this solution have limitations. 

I've been using this solution for four years. 

The solution is stable. 

We are still in phase one so haven't yet tested scalability. That will come when we move to the second phase. We currently have around 15 users of this solution. 

Support is on a subscription-based model but we haven't had any contact with technical support. 

The licensing for this solution is pay-as-you-use.

I rate this solution an eight out of 10. 

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.