VMware Tanzu Data Solutions Reviews

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.

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.

My company runs on high availability. It is known for high accuracy in its items that are being shipped.

To do this, drivers/vendors who are shipping these items have to send their location details frequently to the server to update their current location. It all depends on accuracy.

Based on this, the end user can plan to receive shipping items on his end. We wanted a JMS tool that can create 'queues' on the fly and pass messages from one system to another.

• Queues and topics
• Native cloud app support
• Light-weight
• Easy maintenance
• Simple and straightforward admin portals: Made it easy for users and worked out excellently for our requirements

The solution needs improvement on performance.

It was stable enough to process our requests.

We were able to operate multiple nodes and we implemented a load balancer to meet our high traffic requirements.

We have never needed technical support. It was all there in the API documents provided by RabbitMQ and there are numerous blogs available on internet.

We analyzed our requirement thoroughly and were sure that RabbitMQ was the solution for us. We didn’t look at anything else.

It was bundled with PCF, so it was never a problem for us.

Again, it was part of PCF bundle, so that was never a worry for us.

This is a great product. It is lightweight, supports cloud native applications, is easy to implement, is easily manageable, and has excellent support. I would say, just go for it!

We're using this as our central messaging bus. It drives our micro-service architecture.

• Great management UI: The best in its class of messaging products
• Very sophisticated routing control and priority messaging capabilities

• The product should have much better scaling and scalability capabilities. Currently, they're really falling behind some of the competitors such as Kafka and NSQ.
• The installation of the HA version and clustering mechanism should be made much easier.
• The fact that a single queue can't be distributed across multiple instances/nodes is a major disadvantage.

We had multiple issues with stability. The product tends to be highly unstable when under heavy loads.

We had multiple issues with scalability. The product's scalability is rather problematic. It tends to be very complex to maintain with various sharding and high availability options.

I have never used technical support.

We tested some earlier version of Apache Kafka, but it wasn't stable enough at the time. At the moment, we're considering switching back to Apache Kafka.

The non-sharded/clustered setup is very easy and straightforward. The clustered solution setup is much more complicated.

We have only used the open source version.

We evaluated Apache Kafka, NSQ, and ActiveMQ.

Check the scaling issues. If scale is not an issue and you're just looking for a stable messaging queue, I would highly suggest it.

If scale is an issue, I would suggest using Apache Kafka.

We use the solution for event-driven programming. We have multiple queues and channels to provide scenarios for publishing into containers. You have to communicate the microservices, and consumers consume the services. 

We were using the solution to setting the tenant settings into the service. For example, if you have five microservices using the tenant settings, after updated, we publish the updates to other microservices. It helps get the updated data to be able to publish the settings into the updated queue.

The queues and the publishing are quite useful. We're able to create hierarchies and control channels and flows to control what is going from which queue.

The solution can scale.

It is stable and reliable. 

The availability could be better. When something crashes, a queue gets deleted, and my data is lost. They need to improve this so that we don't lose data during issues like crashes.

We'd like to understand how many queues are running on RabbitMQ. I'm not sure how to get these details and how to verify the information.

We need other protocols. 

I've been using the solution for three years or so.

The solution is stable and reliable. There are no bugs or glitches. 

The solution is scalable. However, we have issues with availability. 

Sometimes, it is hard to understand what is going on when you reach out to technical support.

Our DevOps team deployed the solution. 

I'm not sure what the exact pricing is. I don't handle the licensing aspect. 

I am using the latest version of the solution. I'm not sure of the version number. 

I've used this on multiple projects, and it has proven to be quite useful.

I'd rate the solution nine out of ten. It is a very good tool. 

The most valuable feature of RabbitMQ is the ability to set up workflows simply with configuration. We had some very complex problems (logging, auditing, sequential and parallel operations) that have been easily solved by inserting a queue in the middle of an existing workflow.

Our software has evolved dramatically over the past 18 months of development.

Major modifications to business logic have been handled easily. This is because each operation that the software performs has been atomic. That was then wired up with other operations via RabbitMQ exchanges/queues,

• RabbitMQ is great, but it depends on the Erlang VM.
• I understand that Erlang is the reason why RabbitMQ is what it is. However, having to install and maintain yet another VM product has been annoying.
• The configuration for RabbitMQ borders on the esoteric. Once we got all of the moving parts working, it’s been a dream. However, it was an effort just to get it going.

We’ve been developing with RabbitMQ for about 18 months now. Our product launch is scheduled for April 1, 2017.

There were stability issues. We originally tried to mirror RabbitMQ servers behind a load balancer. (This is not completely recommended, by the way.)

That suffered from stability issues when network hiccups were a problem.

We ended up moving to a central LDAP authentication with completely disconnected servers, which has been stellar for stability.

We have had no scalability issues at all. We have RabbitMQ servers behind a load balancer, with Queue listeners attached to them.

I have estimated that we will be able to scale quite dramatically without any change to network topology.

RabbitMQ is an open-source project, so the level of tech support is relatively low. The documentation is adequate. There is a decent amount of activity on Stack Overflow and that has answered most of my questions.

I did actually use an open-source plugin and had a lot of communication with the developer. He was responsive and helped me significantly.

Our initial solution was a simple web API. We quickly realized that it would be difficult to maintain.

Scalability and reliability were my primary concerns. HTTP has no reliable delivery built-in, like AMQP does. Changing API versions would have been more difficult if we had stuck with HTTP.

The initial setup was fairly complex. Installation was not difficult, but configuration of the server itself took some work.

I ended up creating code that does the RabbitMQ setup based on a configuration file. This eased the setup dramatically. I also set up a central LDAP server for authentication, which helped. Otherwise, configuration of RabbitMQ was not very straightforward.

Being free and open-source, I have no advice here! Free is a good price!

I looked at other service bus/message queue solutions. In particular, I investigated:

• Azure’s Queue Storage: No real service bus ability without plugins
• AWS’s Simple Notification Service: Not much in the way of service bus capability. It did not allow private queues on the fly.
• A few other open-source message brokers

RabbitMQ seemed the most full-featured option for what we needed.

By all means, try to reduce the amount of up-front configuration of RabbitMQ as much as possible.

At this point, we can spin up a very generic VM with RabbitMQ on it and get it in use immediately. However, that was not the case at the beginning.

RabbitMQ is very flexible, which is good and bad. Once the flexibility is understood, it’s great. Before that, you may be in for a little bit of head-scratching.

• Parallel processing
• Takes minutes to process millions of records

This has improved our daily load process reducing the run time at least by three to four hours which made other departments within the organization to look for data from the Enterprise Data Warehouse.

It acts like a mainstream product not a novice any more. There are a lot of areas that can be improved. The bug fixes come as many patches like a start up instead of having scheduled release with proper improvements.

I've used it for five years.

It took a while to fully take advantage of this as we had to come up with lots proprietary solutions when linking to other products.

There is no issue with its stability.

There is no issue scaling it.

8/10 we had a technician come out on a new year in 2012 to fix some hardware failure.

We were one of pioneers in adopting this solution. So we got the best deal when compared to the competitors in several areas.

The initial move was a bulk transfer from the old system to new Greenplum based solutions. It was all done by Greenplum contractors. But to get it working with other products was challenging.

Greenplum employees developed and supported the initial move. Later they became remote consultants with support through phone and in-person as needed.

They gave a really good deal and we have been with them for five years even though the product got bought over by couple of different companies.

You need strong DBAs and architects to support the initial transfer.

Asynchronous messaging; supporting data integrations between multiple applications on behalf of our many customers. RabbitMQ allows us to elegantly fan-out data to a variable number of subscribers, with almost zero effort.

We have been able to set up a messaging system that facilitates data integration between the software modules that we sell.

RabbitMQ allowed us to do this quickly so that we could focus on the business requirements, rather than divert our efforts to message broker implementations.

Once the architecture was proven, we were able to return to the RabbitMQ message layer in order to implement an HA cluster with a minimum of problems encountered.

Our business now has a fit-for-purpose information hub that we can apply across our systems. As the customer-base grows, we know that the hub can grow with it.

RabbitMQ is a solid, widely-used messaging system with a low cost-of-ownership. It is open, but with commercial support potentially available from Pivotal if required. (We have never needed it.) There is also a strong online user community.

One crucial feature was guaranteed messaging. We needed a solution that we could trust to not lose data.

Its built-in clustering capability allowed us to configure it as a highly available message broker, so that we can have confidence in the resilience of our architecture.

It can be scaled as well, although we have not tested this.

After almost two years' usage in our production environment, I am impressed by how stable the platform is - even when running on Windows Server 2012. Sure, we have had to tweak our set-up here and there as we have learned a few operational lessons along the way but overall it is very good.

RabbitMQ is clearly better supported on Linux than it is on Windows. There are idiosyncrasies in the Windows version that are not there on Linux.

The documentation for the Windows version is also less plentiful and less accurate.

The online community clearly provides better Linux support, but this naturally follows from the smaller Windows installed base.

There are also some potential concerns about how we maintain high-availability whilst also scaling out.

We have had no stability issues.

We have not used the scalability features yet.

We have not used technical support.

No previous solution was used.

The initial setup was straightforward. The online documentation was adequate and there is minimal initial configuration required to get up and running.

After that, it is simply a matter of experimentation with the various features and learning as you go.

This is an open source solution.

We looked at MSMQ, NServiceBus, Azure Service Bus, and Apache Kafka.

I would recommend that anyone who intends to deploy RabbitMQ on Windows should first consider whether a Linux implementation is a viable option for their situation.