Confluent Reviews

We use the solution for wiki to share information with the spaces. For example, we have an idea that supports the developer team, so we create spaces to share the documentation. We have access to some data.

We're using the basic Confluent setup. The troubleshooting access control is an important feature. You can determine user access and the Jira integration.

More instructions should be included. It should guide the people to build the site in an easy way because when you ramp up conference spaces, people start making an effort with, domain providers. Easy project management tools could be added.

I have been using Confluent for three years.

The product is stable.

I rate the solution’s stability a ten out of ten.

30 users are using this solution. We might increase the usage, but it depends on the cost.

I rate the solution’s scalability a six out of ten.

Deployment is instant. When you have to do it on the cloud, you just buy the license and it is ready to go.

I rate the initial setup a seven out of ten, where one is difficult and ten is easy.

The product is expensive.

I rate the product’s pricing a six out of ten, where one is cheap, and ten is expensive.

Be careful while using Confluent. It's easy to get into a messy state in the IRR space if you try to do too much without thinking.

Overall, I rate the solution an eight out of ten.

Our primary use case for this solution is processing vast chunks of data in real-time. We deploy the solution on cloud.

The processing is better, and the connectors feel better than other solutions we have used. Additionally, the solution can handle a high volume of data because it works and scales well.

This solution is different from other products we have used. It could be improved by including a feature that automatically creates a new topic and puts failed messages. When we moved to this solution, we noticed that failed messages do not automatically go into Dead Letter Queue (DLQ), which we had when we used Azure. We want something similar to be included in Confluent Kafka.

The Azure Service Bus background should be improved where the message processing and messages fail and automatically go into a DLQ. In Confluent Kafka, there is no concept of DLQ, so if any messages fail, you have to handle it on your end and push it to another topic. But in Azure Service Bus, it happens automatically if any message delivery fails. It puts it in a DLQ. We didn't bother about anything on the code front, but with Confluent Kafka, there is no concept of DLQ, and you have to manage when a message fails to deliver. We have to push it to another topic manually. This should have been on the Confluent Kafka, and if anything fails, it should automatically move the message to another topic that has been created. Still, we have to do this using our code explicitly.

We have been using the solution for approximately six months.

The solution is stable. In our limited experience, we haven't found anything that would highlight that it's not stable.

I wasn't part of the initial setup.

We need visibility on the licensing costs.

When evaluating the use case compared to the Service Bus architecture we previously used, the performance is better and more tolerant than a competitive system. Hence, because of our data volume, it can handle high-volume data, and its performance is better than other systems.

I rate the solution nine out of ten. The solution is good, but it can be improved by including a feature that stores failed messages. I recommend this solution to new users because we went through different tech analyses and then adopted this solution. To date, we have seen improvements in performance and scalability, so we recommend this solution.

We're currently working on one of our largest implementations with 500 billion-plus records in real-time and 100 billion on a daily basis. The client aggregates the reports. I'm a solution architect and we are customers of Confluent. 

As an enterprise organization, data availability is critical and Confluent provides that SLA support. It's very important for us to have this.

KSQL is a valuable feature as is the Kafka Connect framework for connecting to the various source systems where you need not write the code. We get great support from Confluent because we're using the enterprise version and whenever there's a problem, they support us with fine-tuning and finding the root cause.

From the control center perspective, there is a lot of room for improvement in the visualization. They're now aggressively pushing the Cloud version which is good, but there are still a lot of features missing there.

I've been using this solution for three years. 

If you take the version prior to the latest one, then it will be stable. We have a team of around 10 people working on the solution. Maintenance needs an operations team and admin availability in the event of performance degradation. It needs to be monitored 24/7.

This solution is highly scalable. 

Customer support is very good - we can raise a ticket through the portal and they get us on a video-sharing app to help solve the problem. 

We previously used the open-source version of Apache which doesn't have automated deployment using Ansible or even through Confluent Operator for Kubernetes. It required a lot of installation maintenance which can be tricky sometimes.

If you go for Confluent Cloud, then the deployment is just a plug-and-play. If it's on-prem and you're looking to deploy on a non-containerized platform, then there are very good Ansible scripts, which can be completely deployed. If you're going with Kubernetes, then they have something called Confluent Operator. Deployment requires an online admin and a minimum of three people for on-prem deployment. Implementation time depends on the cluster size. For eight nodes, deployment takes around 20 minutes but for a larger cluster with around 30 nodes, it can take an hour and a half. 

I think this is a very good solution and if there's no need to specifically take the on-prem version then in terms of maintenance and scalability, the cloud version would be the preferred option. If the organization has a very high volume of data then on-prem is preferable. In terms of performance, I believe Confluent is the market leader in streaming platforms.

I rate the solution seven out of 10. 

We collect service log data with Confluent and use it for fraud detection in game services.

We are a game service company, and Confluent has helped us improve our quality of service.

The Schema Registry service could be improved.

I would like a bigger knowledge base of other use cases and more technical forums. It would be good to have more flexible monitoring features added to the next release as well.

I've been using Confluent for about two years.

For stability, I would give this solution a rating of seven out of ten.

I would rate the scalability of the solution at eight out of ten. We have 20 people who use Confluent in our organization now, and we hope to increase usage in the future.

I would rate the solution's technical support at seven out of ten.

Neutral

On a scale from to ten, where one is difficult to set up and ten is easy to set up, I would rate this solution's initial setup at six. It was quite difficult.

The deployment took about a week. We had a team of four people for the deployment. A team of two handle the maintenance.

On a scale from one to ten, where one is low pricing and ten is high pricing, I would rate Confluent's pricing at five. I have not encountered any additional costs.

We evaluated Kinesis and MSK, but chose Confluent because we wanted to use its RBAC feature. Also, the other solutions did not have a feature to clear storage.

I would recommend Confluent as an alternative to those who are unfamiliar with Kafka. Overall, I would rate Confluent at eight out of ten.

I work in the insurance domain. We stream data in and out Confluent. If financial data is being used most organizations prefer to stay on-premise with their data, but there is a cloud version available. These are the features that Confluent provides.

Confluent has benefited our company because it provides granular access, enterprise support, self-balancing cluster. If there is any data skewness or one server is busy doing some processing, it shifts to the other processor and balances the data between them. There are auto data balances, self-balancing clusters, replication, and role-based access controls.

The most valuable feature that we are using is the data replication between the data centers allowing us to configure a disaster recovery or software. However, is it's not mandatory to use and because most of the features that we use are from Apache Kafka, such as end-to-end encryption. Internally, we can develop our own kind of product or service from Apache Kafka.

They should remove Zookeeper because of security issues.

I have used Confluent within the last 12 months.

The latest version of 6.2.0, has almost everything and it's stable.

The solution is scalable. If you have good hardware, especially for Kafka then it will perform very well. It's easy to scale up, but there are issues scaling down, which may result in losing data.

I don't know exactly how business is doing. We currently are supporting, and we are running up to the threshold of the solution. I'm not sure about the future if we will increase usage.

We have approximately 250 applications running.

We have contacted technical support. We create support tickets, in case of emergencies or when any support is required.

I've been working with the support team for four years. They are good. The level one team will go around the issue by gathering information, but the next level, and the third level development team, are very good.

The installation is straightforward and we use our own ansible-playbook, which was designed similar to CP ansible which is supported by Confluent.

We have two people that do the implementation. We manage four clusters which include integration tests, reproduction, and production. We did the installation with some simple scripts and designing the script takes a couple of weeks.

Confluent requires maintenance because we might see issues with the applications and need to support them. We need to keep checking the performance and we should keep on monitoring them because high critical data will be passing through. There is a need for regular OS patching and any upgrades that Confluent provides. 

Not everybody will be aware of Kafka's technology which means we educate the developers. For example, the properties to be used and what makes optimum performance from the solution.

I have had a return on investment by using Confluent. It's faster than any other technology in real-time. You don't have to wait for your transactions to happen overnight.

The license Confluent is server-based. It depends on the number of services that you are running in the cluster. 

Confluent is expensive, I would prefer, Apache Kafka over Confluent because of the high cost of maintenance. 

Large organizations, prefer to use open-sourced solutions because they provide a cost reduction. Apache Kafka is open source and there are many other open-source security tools, which can be used that provide features that Confluent offers.

I have evaluated Apache Kafka.

Confluent has improved a lot and they're currently working on version 7.0 where they're removing Zookeeper, which is highly vulnerable to security attacks.

My advice to others wanting to use this solution is for them to use automation wherever it is required and it is a very stable product, not many issues arise If you know how to manage them. Overall, it's a great company and they have excellent software.

I rate Confluent a nine out of ten.

I use the tool to create documentation that needs particular specifications.

The documentation process is fast with the tool.

The product should integrate tools for incorporating diagrams like Lucidchart. It also needs to improve its formatting features. We also faced issues while granting permissions.

I have been working with the tool for three years.

The tool is stable.

The solution is scalable. My company has more than 25,000 users of the tool.

The tool’s initial setup is complicated.

I would rate the overall solution a nine out of ten. Confluent is a great tool for business analysts and project managers.

We use Apache Kafka and Confluent Cloud to stream event data from APIs and work with CDC log data from databases for data integration.

Our main goal is to validate whether we can build a scalable and cost-efficient way to replicate data from these various sources.

One area we've identified that could be improved is the governance and access control to the Kafka topics. We've found some limitations, like a threshold of 10,000 rules per cluster, that make it challenging to manage access at scale if we have many different data sources.

I have been using the product for three months. 

I haven't encountered any major stability or performance problems so far.

The platform seems very scalable in handling high volumes of data and throughput. 

The tool's support could have provided more guidance and best practices, especially when designing our solution. Instead, we discovered and solved many of the challenges ourselves. The support has been responsive, but I think it could be better.

Neutral

I've also worked a bit with AWS MSK, a competing product for Confluent Cloud. From a maintenance standpoint, I think Confluent requires less effort than something like MSK or running Kafka on Kubernetes ourselves.

The general setup and deployment of Confluent are very easy.

Regarding pricing, I think Confluent is a premium product, but it's hard for me to say definitively if it's overly expensive. We're still trying to understand if the features and reduced maintenance complexity justify the cost, especially as we scale our platform use.

I rate the overall solution an eight out of ten. 

We are providing the solution for real-time data for the banking sector.

We mostly use the solution's message queues and event-driven architecture. Since Confluent has integrated with Kafka, we can utilize its fault tolerance and matrices.

Confluent is expensive, and we face certain limitations while using the tool. Confluent has a good monitoring tool, but it's not customizable. We can only use the existing dashboards. On the other hand, we can utilize maximum customization while using Grafana with Prometheus. Confluent also supports JMX metrics, but using Grafana with Prometheus is very effective.

I have been using Confluent for two months.

I rate the solution’s stability a nine out of ten.

Confluent is a very scalable solution. Since we provide solutions for the banking sector, we need a high throughput of massive data per day.

I rate the solution a seven out of ten for scalability.

Confluent provides really good technical support for its partners.

Positive

I have previously worked with other solutions like MuleSoft Anypoint, Dell Boomi, and Redpanda.

We are currently doing some POCs, which take two to three days based on availability. Sometimes, if the technical people are unavailable, I have to wait for their response and get into meetings.

Confluent is an expensive solution.

On a scale from one to ten, where one is cheap and ten is expensive, I rate the solution's pricing an eight out of ten.

Confluent can be easily integrated with other systems. Most clients don't know the actual use cases of Confluent or Kafka. We explain the real use cases to the clients, like fault tolerance, high throughput, low latencies, and monitoring tools.

I joined my company just one month ago. Working with Confluent for the first time was a bit hard for me because it has a lot of documentation for everything. I need some technical experts to utilize the solution's functionalities. Maintaining the solution is easy because we are part of Confluent, and they are available.

Overall, I rate the solution an eight out of ten.