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.

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.

Allowing for a fully asynchronous solution is crucial for this particular feature. The seamless nature of creating and connecting to a queue makes it really easy to code and understand. Pivotal Cloud Foundry allows us to easily scale the number of consumers (or receivers) as well. So far, no hiccups have been found with the PCF implementation.

RabbitMQ allows for asynchronous solutions where previously everything was synchronous.

The product works pretty well, but one small thing could be an improvement to the monitoring site. It could be a little bit more modern, instead of postback refreshing, etc.

We have been using Rabbit for a while and I started integrating it into the mobile project a few months ago.

Every so often, I need to clear out the queue during development. This could be a symptom of something else, but unpacked requests tend to get trapped in the queue at times.

PCF allows us to scale the consumers.

I haven't used any technical support yet.

To my knowledge, this is the only queuing system my company has used.

Thanks to Pivotal Cloud Foundry, initial setup was straightforward. We simply created a new RabbitMQ service, obtained credentials for the queue and started developing.

I personally have not explored other queuing solutions, but have used Akka HTTP, with is a fully asynchronous web server of sorts. It's not a queuing system, but I mention it because of the asynchronous behavior. RabbitMQ was perfect for our current solution, however.

The RabbitMQ documentation is pretty good. I'd only suggest making sure to read through it for the implementation language of your choice first.

The most valuable feature is it’s robustness. Message queues need to be extremely reliable as they are the glue between system components.

Also, the speed is important and its good scaling capabilities.

It allows developers to focus on application functionality without having to re-invent interprocess communication, which is difficult.

I also allows us to develop smaller, more efficient, and less complex subcomponents of a larger application.

I would like to see better documentation on how to set up complex webs of RabbitMQ servers — master/slave, multi-master, etc.

I have been using RabbitMQ for 7+ years.

We have not encountered any stability issues.

We have not encountered any scalability issues.

We were using IBM MQ, but it was too costly and not open source.

The initial setup was simple for my applications, but I have not used RabbitMQ on a complex project that would require clusters of servers.

My advice is to read the message boards and play with the API.

Message queue, because it is easy to use, reliable, not a big load.

We are using it to distribute pieces of some large jobs to multiple machines, which improves performance several times.

Improve the ability to handle the large message load.

People usually use RabbitMQ as the lightweight messenger, if they have a large message load people are inclined to use Kafka. But at the beginning stage of most projects, the data is small, people do not need to use a Kafka type of messenger, they are more likely to use RabbitMQ. If RabbitMQ can handle the large message load and support ordered delivery, with the project growing, data bigger, people can still use RabbitMQ and wouldn't need to find another tool to use like Kafka which is much more convenient.

Half a year.

Didn’t have issues.

Didn’t have issues.

Very good. 8/10.

Simple. We followed the tutorial about RabbitMQ with Python.

We are using it internally with a very small data load in the developing period, which is free right now.

Yes, I evaluated Kafka.

Kafka is more suitable to large amount events in order. RabbitMQ is more suitable to the related small amount of messages, which is my situation and I don’t care about the message order.

RabbitMQ is a very easy to use and reliable message broker. If the work has a relatively small message load, RabbitMQ is the most robust and reliable choice.

I've found that the database warehouse, data compression, and ETL to be the most valuable features for us.

Loading batch data has really improved the efficiency of our organization.

I'd like so see better scaling, better performance from in-memory databases, and a higher compression rate. We have been facing some performance issue when doing batch loading with optimizer the scaling does works fine. They are working on having optimization techniques which made me write room for improvement.

I've used it for over two years. I have been working very closely with the EMC folks.

Yes, at times, but it depends on your modeling and data retrieval.

It's been stable for us.

Its scalability needs to be improved.

I would rate technical support as good and there is not much technical expertise at the start of the SR.

We tried other MPP’s.

It was complex, but there was a change in the setup.

We got support from the vendor at the start.

If you want to implement this product, you would need to scale your product well before trying to implement.

Strong integration with Greenplum Servers.

Loading data to Greenplum server after batch processing.

6 months

Yes, issues with HA and issues in syncing with the Greenplum.

You cannot expect a split second response.

On a scale of 10 I would rate it as 7

On a scale of 10 I would rate it as 8

This has just been used for POC period not for a regular use.

Initial setup works absolutely well. We were using with only Greenplum.

I've found that the data compression and ETL are the most valuable features for us.

In 4.3.8.1 Pivotal confirmed that even restoring schema level backup is possible from a DB backup.

- restoring schema from a DB level backup has been tested and working fine .

ORCA - the Pivotal Optimizer does a good query plan but does not works with all business logics. This needs to be tested based on your requirement.

Loading batch data has really improved the efficiency of our organization.

Running Extracts has drastically improved the timings. Being MPP which is a bulk operator - we were able to do 1.5 million calculation in 15 minutes.

Scaling of the solution needs to be improved.

HD connection is available where as, not to any file system.

Connecting Greenplum with Gemfire(In-Memory) to load, sync, and reconcile data would be really valuable.

I've used it for nearly for 3 years

We had deployment issues after installing new patches. Every new patches has some or other business hit where the release notes needs to be reviewed.

It's been stable for us.

They have a quick turn around but to dig into the actual information takes time, based on the Severity.

First level of technical support would not be that effective (based on own observation).

We were using Sybase and handling massive data, bulk operation was not possible.

It was simple.