VMware Tanzu Data Solutions Reviews

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.

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.

• Parallel Processing and Data Distribution based architecture.
• HA built-in with mirroring.
• Highly configurable and lots of tuning features.

• This has helped us bring down our end-to-end EDW load time to 1/3 the time.
• It has enabled faster and efficient data analysis.
• Scalable environment without adding too much cost.

• It needs a much more robust and user friendly monitoring and management front-end tool.
• More stability and auto-recovery with the segments.
• Report generations on system health and recommendations.

I've used it for two years.

Up to now, we've had no issues with deployment.

Up to now, we've had no issues with stability.

Up to now, we've had no issues with scalability.

The response is fairly good but would like more support from the R&D on more complex issues. Also, they need to ensure there are logs that can be used without causing any downtimes to the system for any case analysis.

It's a highly efficient and faster DB with lot of features at much less cost to that of other MPP DB’s evaluated.

It was complex as we have to code convert everything into GP functions so as to best be able to use the GP parallel. Pushdown feature was not available via Informatica. The initial parameter setup took quite some time to test to get the sweet spot for performance.

In-house with vendor support.

Make sure you have the designs, approaches and architecture in place before kicking of the implementation. Its best to have someone involved with prior migration experience.

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.

• AMQP protocol
• The simplicity to set up a cluster
• All patterns available (Topic, Routing, RPC, etc.)
• Enables you to provide a response to most problems encountered

I introduced RabbitMQ to my company to bring about more scalability and redirect asynchronous tasks outside of the frontal web servers.

• Scalability was provided by the possibility to add on workers behind RabbitMQ. Asynchronous is the keyword for the message broker.
• I started to split our monolith website and remove all the heavy processes from our web servers.
• Dispatching the workload correctly helped to increase the response time.
• The frontal web server must focus on replying and not on doing reports/PDFs. You must have a dedicated server for this.
• The solution is written in Erlang. Erlang was built for telecommunication systems. One of its assets is that it can upgrade a service in production without downtime. That’s a good point!

• Have more features such as being able to replay a sequence of what was received.
• Handle more messages per second.
• Consume fewer resources: NATS can handle millions of requests within a few minutes. RabbitMQ handles hundreds of requests with the same resources (RAM). Finding a way to be more efficient in this aspect would open them up to other markets, like IoT or embedded systems.

I have used this solution for around two years.

There were no stability issues.

There were no scalability issues.

The documentation from the internet is good.

The setup was pretty straightforward.

I have looked at Apache ActiveMQ and Kafka.

This product is fantastic. Before you use it, make sure you analyze your real needs. In the world of message brokers, there is no single solution. Today, you have solutions that are specialized for specific use cases.

For instance, you have the NATS solution which is another great message broker tool. It is focused on handling a tremendous number of topics and messages per second and it consumes few resources.

However, it’s not as resilient as Kafka. Kafka can replay all the messages received from a date range. However, this one can handle fewer topics.

NATS is written in Golang. Golang is the Go programming language, which I love.

It has solved issues such as queue processing, real-time data processing and decrease count of Cron jobs.

The management of Cron jobs is very hard for me. If you are using RabbitMQ, you may not need a Cron job since you can create a consumer for a queue and listen to the queue in real-time. For example, you need to send an email for your new members but you want to do this from your software. The reason being if you encounter an SMTP error, you should handle it or sending an email from your membership activity can take about 5-10 seconds. If you don't use RabbitMQ, you need to create a Cron job and check for new members to send an email to them. But, if you use RabbitMQ, you do not need a Cron job. You can send a message to your queue and consume it in real-time and then send the email.

I have used this solution for changing stock of products in an e-commerce project. We update the stock of products from RabbitMQ. Some of our clients can change the stock of a product, i.e., either increase or decrease it. They send the stock count to RabbitMQ as a message and our e-commerce platform changes the stock when it gets the message. Consequently, we update the database, cache, search engine service and so on.

There are too many advantages of using this solution. You can scale your processes and update your data in a nearly synchronous way.

RabbitMQ needs 2 additional features:

• It is lacking a good dashboard on the web interface; maybe they can develop a dashboard for monitoring.
• There is no alert mechanism. For example, sometimes consumers may be killed or the input messages in queues are greater than the consumed messages. Thus, I would like them to define a rule for alert; maybe they can develop an alert mechanism.

I have used this product for three or four years.

I have not encountered any stability issues.

I have not encountered any scalability issues either.

Since it is open source, you can resolve your problems either from forums or Stack Overflow in regards to RabbitMQ.

We have used different solutions before. We have tried MySQL as a queue and it was terrible.

It is not complex.

However, if you try sharding or cluster, it is just a little complex because of Erlang.

It is open source.

I did not look into other solutions.

I would recommend this product. It is great and resolves a lot of problems.

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.