VMware Tanzu Data Solutions Reviews

We use it as our main microservices connection queue.

The product's reliability is the most valuable feature.

• The product has to improve the crisis management, especially in memory issues.
• Its clustering feature also needs improvement.
• I would simplify the configuration. I would add default configuration that prevents the queue system from filling out the server storage.
• I would also decouple the queue from the RabbitMQ Management, so that the queues won't get stuck.
• Clustering and clustering crisis management: When the cluster falls, there needs to be a simple way to recover it. It currently suffers from a recover problem.

In the regular state, there were no stability issues. When the queues are full, only complicated pre-configuration can help you so that you don't lose all of your crisis messages.

There were some scalability issues. There is no scalable queue. The cluster only supports redirections.

The documentation needs to be improved. We don't use any human technical support.

We have used DBus and ZeroMQ. We wanted something more reliable and simple, so we switched over to this tool.

The setup was okay, but there are some configurations that one needs to do by oneself. There are many dependencies as well.

It is an open source solution.

Do many stress tests.

Complex message routing makes it very easy to replicate product data for user acceptance testing which was required in our user case.

Applying message queues in general has helped my company, BuzzNumber, to scale easily with the load.

The High Availability feature is not really reliable. It also took a really long time to restart the box when there were a lot of messages in the queue.

As mentioned on its document page, it cannot tolerate network partition well.
I suffered a network parturition with 3 nodes cluster and lost all data. So with our cloud provider, we can’t rely on pause_minority and seems like auto_heal is a better fit for us.

Apart from that, RabbitMQ doesn’t seem to be stable when it has high RAM usage. Especially when you have millions of queue items in a queue and a node crashes, adding a new node to such cluster will be a pain as the replication takes forever.

We have used the solution for two years.

We encountered an issue with stability. It didn't work very well with millions of messages in the queue when you add a new node to the cluster.

There were no specific issues with scalability except the issue of adding a new node to the cluster.

We used the open source version with community support, so we didn't contact technical support.

We previously used MSMQ. Apparently, it is not as good as RabbitMQ in terms of the features offered.

The setup is easy.

This is not applicable, as we were using the free version.

I am not aware of other evaluated options.

I would advise potential customers to make sure it works with your architecture, scale plan, and load. There are other alternatives.

One of our favorite features is the exchange. The queuing out-of-the-box is awesome. Also, due to the clustering, our system was highly available.

It made our system more scalable, resilient and easy to maintain.

Support for Windows systems needs to improve. This could move Microsoft shops away from it. We provisioned Linux servers specifically for our RabbitMQ servers.

RabbitMQ clusters run on two kinds of protocols: AMQP and HTTP. The one we were using was AMQP (this requires all your cluster nodes to be in the same network partition). With our Windows servers, every time we used to run Puppet, RabbitMQ used to think it got partitioned. This problem never occurred in our Linux cluster.

All this is subjective. Maybe we were doing something wrong. There are a few other things which they have listed here: https://www.rabbitmq.com/windows-quirks.html Overall, I don't think it's RabbitMQ's fault because Windows can be a problematic OS at times.

So, I would recommend using Linux servers instead of Windows servers for a RabbitMQ cluster.

We have used RabbitMQ for 1 year now.

Other than the fact that our Windows cluster would experience network partitions for no reason (could be due to Puppet), we had no other stability issues. We stress-tested the servers, as well, and they responded really well.

Its really easy to scale.

We never used technical support.

We had a monolith application. This was our solution to have more of a micro-service architecture

Initial setup was decently elaborate. The documentation is good but there are a few quirks in the case of Windows. The RabbitMQ processes would be running but the status would show that it is down. The solution was to stop and restart the process. This only happened on Windows.

We also evaluated ZeroMQ and EasyNetQ.

It is a really good solution if you require queuing with the competing consumer and multicast routing out of the box. It’s a bit too elaborate if you need just simple message queuing.

The security is great. The interface is nothing special. The support hasn't been that great. You need to go online yourself, to the developer community for support. But apart from that, I think it's fairly secured, quite robust, and stable so far.

Their implementation is quite tricky. It's not that easy to implement RabbitMQ as a cluster. It would be great if they could improve that. 

I have been using RabbitMQ for three years. 

It's quite stable.

It is very scalable. I have a team of 10 developers who are using it and I have some of our clients using it in our Cloud cluster. We have about 10 banks running on the platform now.

I would rate their support as a five out of ten. It has room for major improvement. 

The initial setup is quite straightforward. It can be done within a few hours. 

I would recommend it, but I think there should be a proof of concept for the developer team to get their hands around it and have full control of it before they go into production.

I would rate RabbitMQ a seven out of ten. 

In the next release, I would like for them to improve the UI.

It allows for asynchronous development and horizontal scalability.

The queuing system is the most valuable feature. It meets our requirements.

After creating a RabbitMQ service, they provide you with a sort of web management dashboard.

The dashboard allows you see things on your queues, purge/delete queues, etc. The dashboard is pseudo-real time, refreshing every N secs/mins, specified with a drop down.

I’d like this dashboard to use web sockets, so it would actually be in real time. It would slightly increase debugging, etc.

We have not had stability issues.

We have not had scalability issues.

We never used technical support.

We did not have a previous solution.

The setup was straightforward. We are implementing using Node.js and the module we are using was easy to use.

I am not the one in charge of licenses and pricing, so I do not know anything about this.

We didn’t have any alternatives. Our company has a contract with PCF, so it was our only option.

For Node.js development, use amqplib. It’s a really good library for RabbitMQ.

RabbitMQ is good in its real-time capability of delivering the sensor data in different topic abstractions. It is quite easy to setup in our sensor network system which involves data monitor agents across geographically distributed organizations.

This tool made our research process easier and allowed our administration (monitoring) process to happen at the same time. We created different queues for different use cases of the same streaming data.

The solution can be improved in terms of how to handle the rolled off data from the queue. Currently, if the consumer does not consume a queue, the data in the queue will eventually overflow and be discarded.

I have used this solution for about a year.

Stability-wise, the consumer needs to configure with caution to make sure the queues never overflow. I have experienced data loss in scenarios in which consumer cases were configured incorrectly.

It would be nice if it could produce automatic load balancing when the number of brokers scales up.

The technical support is generally good in terms of being a nice and active user forum that has good documentation.

The initial setup is not very complex. We just needed to set up several broker instances running on different physical nodes to prevent unavailability. When we needed to add more nodes for more data and queues at a later time, it created a bit of load imbalance issues.

I would suggest that the vendor keep it the same way that it is now.

We chose this solution around 2010, so there weren’t many options at the time. We evaluated the native JMS method and it didn't scale up well.

Keep in mind that the queue structure and the consumer configuration need to keep up with the queuing speed. I would suggest researching other options if you need bulk data publish/subscribe in persistent data storage, e.g., Apache Kafka.

We find authentication, performance, and durable messaging the most valuable features. Due to the nature of my use case, performance and security were of the highest priority and were the main reason I chose RabbitMQ messaging frameworks.

Over time, the most useful feature became the ability to create durable queues, which increased reliability and also boosted performance.

I would like to see improvements in fluent configuration. I'd also like to see more support for code-first environment configuration. We do a lot of this stuff as part of our deployment process via command line scripts, but I'd rather have a specific API to target rabbitmq.config and rabbitmq-env.config so that configuration could scale with my environments more easily. If more of that was baked into the RabbitMQ management HTTP API, it would help.

We have been using RabbitMQ for about 2 years.

We did not have any issues with stability.

We had no issues with stability. Exactly the opposite! It actually blew me away how flexible a framework it is. It’s a very elegant solution.

I never used technical support.

I've had the most success using NServiceBus over MassTransit. Look there for .NET Devs.

• Distributed data for performance
• File loaders to reduce dependency on Informatica

Batch processing times have dramatically decreased from over 12 hours to under three hours. Much of this is converting off of Informatica and using distributed processing. Reporting performance also improved greatly.

Since we are upgrading to a new version at this time, it’s hard to say. But we seem to be replacing a disk on the appliance every week.

I've used it for six years.

There's no issues, although we are currently in the middle of an upgrade to v4.3.5.

It seems like we are replacing a disk on the appliance every week. Not a noticeable issue for users and batch processing is not adversely impacted.

Very good. Response times are good for service calls.

I believe the set-up was straightforward. I don’t remember any issues.

We used a vendor team. My advice is that the planning is critical. When converting processing jobs, convert them to PostgreSQL for better performance. Yes they could work as written previously, but you benefit using the features of the product immediately if you adjust the processing to match appliance. Use the bulk processing to your advantage.

We evaluated other solutions. Not sure of the reasons why this product was chosen.

It’s a good product. We moved from Oracle and I don’t want to go back.