VMware Tanzu Data Solutions Reviews

We use VMware RabbitMQ to transfer information from one point to another. 

VMware RabbitMQ needs to create a new queue system. 

I have been using the solution for one and a year. 

My company has 10-15 users for VMware RabbitMQ. 

VMware RabbitMQ's installation is easy. However, it doesn't come with any manuals. 

You should use the solution if you want to store your details in the queue and start taking inputs from the queue. I rate it a nine out of ten. 

Tanzu Greenplum's most valuable features include: the integration of modern data science approaches across an MPP platform, including the ability to massively denormalize data and spread it across your MPP segments; the ability to index data and make it searchable, which significantly reduces the need for ETL; its fast performance. Tanzu Greenplum is also very active in providing additional functionalities and software when needed, like GPText indexing of JSON events.

Tanzu Greenplum's compression for GPText could be made more efficient.

I've been using Tanzu Greenplum for eight years.

Tanzu Greenplum's overall performance is outstanding.

Tanzu Greenplum is highly scalable.

VMware's technical support is probably the best I've seen.

The initial setup was very easy.

Tanzu Greenplum's pricing is really competitive and gives excellent value for money. I'd say that the benefits of orchestrated deployment and the features of GPText make the licensed version worth it.

When considering implementing Tanzu Greenplum, I recommend viewing it as a massive lakehouse, not just a data warehouse. I would rate Tanzu Greenplum ten out of ten.

The use case involves the transferring of messages between services. It includes asynchronous messaging and I also need messages flowing to multiple microservices. In this case, it's basically a fan-out mechanism.

RabbitMQ is configurable and quite flexible.

The performance is fast and reliable.

It is easy to use. The addition of more queues and more services can be managed very easily.

There are some security concerns that have been raised with this product.

The configuration works with a config file, where all of the controls, including that of the administrator and user access, are stored there. The security isn't very stringent or very elaborate.

RabbitMQ is a stable solution.

This is a scalable product. There are six or seven services that are connected and using it.

I have not been involved with anything that necessitated contacting the support team.

Previously, we were using MSMQ, which is the Microsoft Message Queuing service. However, with the new version of .NET 4, support for MSMQ was no longer available. We could no longer get the libraries. As a result, we had to switch to a different queue mechanism. 

I have also used Azure Queue.

The initial deployment was quite easy. It took less than half an hour to get it up and running.

I deployed it myself.

The pricing for RabbitMQ is reasonable. It is worth the cost.

We researched ZeroMQ, RabbitMQ, and Kafka. We found that Kafka was a bit of an overkill because our requirements were quite simple. RabbitMQ was pretty easy to set up, which is why we chose it.

My advice for anybody who is implementing this product is to establish your users and exchanges properly.

In general, I'm quite comfortable with RabbitMQ. It satisfies my requirements and the main complaint I have is about the security.

I would rate this solution a seven out of ten.

We use the solution on our SaaS platform to speedup and simplify customer access across services.

Some of the most valuable features are “publish and subscribe”, fanout queueing, and scalability.

We have a number of different use cases in our scenario. A key one is “publish and subscribe”. We have spent the last year breaking up a large monolithic application into microservices and each microservice has to subscribe to different events for the purpose of CQRS and other kinds of updates. RabbitMQ is perfect for “publish and subscribe”. It does an awesome job at fanout, perfect for CQRS, messages are delivered to all subscribers with almost no additional latency.

RabbitMQ provides the ability to scale queues in a very simple and elegant way. If it had a “failure queue” with robust delivery and recovery built-in with the same power, that would be great. We use a completely different queuing system for failures. So there is a little more effort to take messages in a failure queue, analyze them, figure out what went wrong and then restart them in Rabbit. It is doable, and we do it, but if we had a round trip solution in Rabbit, that would be awesome.

For me, having a robust failure queue, is high on the list of improvements needed in the near future. This is an important update needed because right now we are using Doctrine for our failure queue. Doctrine does a great job.

I have been using the solution in the past year.

Rabbit is a very scalable solution. We could easily queue 50,000 messages in less than a minute. The first day we introduced Rabbit to replace another queueing system that we were using, there was disbelief on the part of the product team because the response was so fast. We need tens of thousands of messages queued in a short period of time, approximately one minute. For example, one user action could spawn 65,000 messages. We also need the ability to segregate different queues. This solution did a great job.

The installation is very simple and elegant, and we love the graphics. It lets us see exactly what is happening with the ability to start the queue, stop the queue, consume messages on the queue. This is a huge help.

We design, develop and deploy the solution ourselves.

We are also evaluating Apache Kafka. Our process is very disciplined. We look at the analytics, the abstraction, the architecture relative to our technical architecture, we ask ourselves questions about the use case, which is better for use A or B. Kafka is not as simple for “publish and subscribe”. You can do it, but not the best fit for us. However as a queueing system, Kafka is great. The records are stored on the queue in the order they are received, However, you can easily search by topic no matter how large the list. Important if you keep track of everything.

There are many different use cases for each technology, as well as many approaches. So have the architecture team graph and document every solution. Have a few training days to clarify the goal, the solution and the implementation. One of the things we do in our training is to actually create prototypes, the abstract model of our ideal state. This demonstrates exactly what we all need to do. Developers understand more quickly with a model. It flattens their learning curve and they are more productive more quickly.

I rate VMware RabbitMQ a ten out of ten.

It's super easy to deploy and it also supports different languages and analytics.

As of now, I honestly don't see any room for improvement. I am very happy with this solution, It's helped me a lot.

They should add more analytics. Their documentation could also be improved so that I don't have to bother my coworkers and tech support so often. 

They should advertise more and make it easier for consumers to leave feedback. That way, customers could read the reviews and decide if it's the right solution for them and their needs.

I have been using VMware Tanzu Greenplum for roughly one year.

VMware Tanzu Greenplum is both scalable and stable.

Their technical support is great.

The initial setup is very easy. Deployment took us roughly one or two days.

I would definitely recommend VMware Tanzu Greenplum. It's open-source and the support is great. It's also relatively cheap compared to similar solutions.

Overall, on a scale from one to ten, I would give this solution a rating of ten — I really like it.

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.

Our primary use case is for telecom customers.

In terms of most valuable features, I'd say Pivotal Greenplum's shared-nothing architecture.

I'd like to see a bridge between Greenplum and Hadoop.

We didn't have any issues yet with stability.

In terms of scalability, I just have one master and two segment hosts.

Initial setup is a little complex. It took around two weeks to deploy.

I prefer an open-source solution but Pivotal Greenplum is cheap and has many functionalities.

On a scale of 1 -10 I'd rate it a 6.

I primarily use the solution for research purposes. I've utilized it for my academic studies for comparing HTTPS protocols. RabbitMQ supported the protocols I needed and I've read also that it's one of the most commonly used broker services.

The solution has really cool features to use. Its management console is excellent. You can utilize plugins to view the performance of the whole service on one network. It's wonderful. I really like it.

I was struggling with installing a few things. It would be good if was somewhat similar to RedHat. There should be more documentation regarding installation troubleshooting.

It's pretty straightforward, the setup, but it would be useful to know what to do if you do face certain challenges. Right now, without more in-depth documentation, it's unclear.

I've been using the solution for about one or two months. It's rather new to me.

The solution is very stable, from what I've witnessed so far. It's also a very fast system.

I haven't scaled the solution myself, so I can't speak from personal experience. I have heard that the solution is not so simple to scale because there is a core node beside the solution. There's some sort of smoothing methodology when it comes to the messaging, so I assume it's not so simple.

I've never contacted technical support for assistance.

The initial setup was simple. The first time I installed it, I installed it on Windows. For me, it took about one hour. If a user was facing a few problems, I'd say it could take up to two hours. Typically it's pretty quick to set up because the recommendations are pretty good.

I handled the initial setup myself.

I was considering using ActiveMQ on AWS, but after some research, I decided RabbitMO was a more complex solution and one that is more commonly used, so I chose RabbitMQ over it.

I'm only really using the solution for the purposes of research. I've just installed and am working on the latest version. My interest in the solution is purely academic, so I can't speak to how it would function within an organization.

I'd definitely recommend the solution, especially over HTTP in the Nico services platform. I've done my research and have discovered it's two times faster and more commonly used. It's also really easy to use on the Nico services platform because all of the components are in the cloud.

I'd rate the solution eight out of ten.