VMware Tanzu Data Solutions Reviews

We use it to achieve what we call asynchronous processing. Asynchronous processing is where applications need to communicate with each other, but they don't need to rely on failures, maybe network failures, or dependencies between them. So how you do it: one application publishes a message to VMware RabbitMQ , and another application will consume that message from VMware RabbitMQ. And so do much, its processing. 

I'm in payments. Let me give you some background on Africa. In Africa, you normally use mobile services, often called Momo, to make payments. So basically, money sits in the customer's wallet, and you need to send them a PIN prompt for them to authorize the transaction.

Now you think about it. If you are on checkout, you need to click on a button to check out. Then, there's an intermediate API that will receive your request. Now, if that API had to call the service provider to issue the PIN prompt, then that takes about one minute. So what you are doing, you are creating a latency of one minute or sixty seconds between your checkout page and the provider.

So, how have we done it on our end? When checkout calls the API, the API publishes a message to RabbitMQ and sends a request back to checkout within 20 milliseconds. And tell the customer that, "We sent you a PIN prompt. Please approve." Now, the consumer who will pick that message up is the one to call the service provider.

Moreover, clustering is actually good because you don't need to have just a single instance of RabbitMQ, which then becomes a single point of failure. In our setup, we actually have two instances for our RabbitMQ cluster. What that means is if one instance is down, we have the other instance which is still processing.

I like many features in RabbitMQ. 

Number one, reliability for the messages is key. RabbitMQ ensures your messages are safe. They are not deleted and stuff. 

Number two, they have a very good feature called Retrying messages – it's all about retries. You can easily retry a message through RabbitMQ. So, if processing fails, you can push the message back into RabbitMQ. Maybe you can re-consume it and so on.

They also have features like tags, which we call "dead-lettering (DLXs)." If it's approved, it means the messages have been delivered. If it's false or missing the first time you get it, you can make decisions based on that. The feature assigned to code for it is called the dead-letter queue.

Moreover, the management interface is so cool. It's simple. It's able to give us an overview of the messages that have been consumed, pending messages, messages that have been delivered, messages that have been acknowledged, and so on. We can also extend that management to tools like... we can extend the management through, like, Kibana or Grafana

Once in a while, we have downtimes associated with RabbitMQ. However, the long-term solution is to architect your solution for a commercially supported messaging broker.

I've been using VMware RabbitMQ for the last three to four years.

It is highly available. However, if messages pile up until the space of the memory is full, then basically, the cluster goes down, and someone has to log in through the backend and purge all messages.  

The trick here is that it's not about the tool. It's about how you build your application and also how you manage your messages. 

I would rate the stability an eight out of ten. It is not a ten because of a few reasons. 

Number one, look at the management console. It is not very secure. If I were to claim it is not very secure, well, we have advanced MQs like IBM MQ. So, companies have come up to build more secure messaging brokers on top of RabbitMQ. 

Number two is – if you don't manage your messages well, then it can surprise youand it goes down.  

It is a highly scalable product. 

We've not had to engage external guys for support. You can easily train your guys to have in-house support.

The initial setup was very straightforward for both on the cloud and on-premises. 

For on-prem [deployments], you definitely need to download the artifacts and install them on a server. 

But for the cloud, we have some managed services. Like, we have a managed service by AWS ECP. You can easily purchase and just spin up a working instance for yourself. RabbitMQ gives you all the credentials, and you're up and running.  

The benefit of achieving asynchronous processing. This gives you:

• Number one is the comfort of your system being stable and running in a very reliable way. Therefore, you'll have very minimal downtimes, which means more revenue for you.
• If you're able to set it up correctly on-prem, then it actually becomes a one-time cost, actually, installation. So you don't need to pay for it ongoing. That means your revenues even become higher. 
• But if you lack the technical capacity, you can purchase a managed instance from Microsoft, AWS, GCP –  cloud-managed. By the time you're going to those platforms, I think you have enough revenue to pay for the cost. But you will also get a very higher rate of uptime.

We are evaluating Kafka.

Overall, I would rate the solution an eight out of ten. If you are starting, you can have RabbitMQ on-prem. 

If you scale up, you can still maintain on-prem, but with higher availability, maybe a few more nodes. When you are processing extremely high traffic, you can now go to the cloud – AWS and so on. 

And when you become an enterprise, you now need to look for an enterprise-managed commercial queue. An example is the one offered by IBM.

I use the solution on cloud and bare metal servers for our company's cloud-native application development needs.

My company's IT personnel work with VMware products since we have its license.

Speaking about the features that have proven to be the most effective for managing database operations, I would say that RabbitMQ is used for the middleware layer, which will give good performance in terms of TPS and availability.

Other tools besides RabbitMQ provide good TPS and HA. If RabbitMQ can match what its competitors provide, then we can probably give it a ten out of ten.

I have been using VMware Tanzu Data Solutions for around ten to twelve years. I am a user of the solution.

Stability-wise, I rate the solution a seven or eight out of ten. I am exploring other products right now. So far it has given a good performance.

There are more than 1,000 people with more than ten administrators using the tool in our company.

My company has RabbitMQ's support. The solution's technical support is good. My company gets a quick response from the product's support team. I rate the technical support an eight to nine out of ten.

Positive

I have experience with MSN which is a Microsoft, but it was not offering a good performance owing to which we had to move to RabbitMQ.

There is no point in spending money on a tool that is an open-source product. It will perform well. Everything in the tool will be a value addition to our platforms.

RabbitMQ is an open-source tool. Since the tool is an open-source product, there is no need to pay anything.

I am correctly exploring options like Apache Pulsar and NATS, and I see both offer good performance in terms of TPS. The benchmarks and numbers of both tools are good when compared to RabbitMQ. Apache Pulsar and NATS are committed and offer 100 times the performance when compared to RabbitMQ. Apache Pulsar and NATS are open-source tools, but both tools have commercial support, similar to RabbitMQ.

Speaking about how the automation capabilities enhance our company's data management processes, I would say that in case of any volumes, we basically use RabbitMQ for the messaging platforms. Our company handles 1,500,000,000 transactions per day.

RabbitMQ affected our company's teams' collaboration and workflow efficiency since everybody is familiar with the tool we have been using for a while now.

My company has not explored the AI part of the tool.

I recommend the product to others.

My company has provided a lot of suggestions regarding VMware Tanzu Data Solutions to other people since it is free and serves everybody's purpose.

I rate the tool an eight out of ten.

We are using the product for analytical purposes like reporting and billing.

We maintain the servers on our premises. Compared to Snowflake, Greenplum is a cheap solution for analytical purposes.

The latest version is better than the older ones. The solution updates very fast. The loading speed is very good.

Maintenance is time-consuming. It takes time to VACUUM and ANALYZE the tables to remove the fragmentations.

I have been using the solution for five years.

The solution is stable.

Compared to Snowflake, Greenplum is not scalable. The solutions used on premises are not scalable compared to the cloud solutions. Around 200 to 300 people use the product in our organization.

Support is fine. We do not use high-level support. The support team is quite supportive.

The setup is easy. It is not complex.

We must set up the instance and run scripts to deploy the product. It is very simple. We can deploy the scripts with one or two commands. One person is enough to deploy the solution.

It’s an open-source solution. There are no expenses for using it.

We are using the latest version of the solution. Some of our clients asked us why we were not using Snowflake, so we are evaluating Snowflake as per their request. If we replace Greenplum with Snowflake, the purpose would be to minimize maintenance time and enhance scalability. If someone is looking for a cheap solution, Greenplum is a good choice for them. Overall, I rate the product a six out of ten.

We specifically use the solution for queuing purposes, and it has proven to be fantastic in that aspect.

The solution's best feature is its exceptional speed, delivering efficient utilization of resources. It uses a memory desk processor very efficiently. It offers high performance while maintaining a low cost.

The solution is a fine product. However, to make it perfect, in some cases, there might be a need to traverse the queue. RabbitMQ currently lacks the capability for archiving the queue, which essentially turns it into a log.

For such requirements, you may need to explore other options like Kafka or custom drivers that allow traversing the entire queue. In RabbitMQ, while you can traverse the entire queue, you need to devise a workaround to handle the messages. For example, you can read a message from one queue, publish it to another queue or keep it in some other way to retain the desired entries, and then stop at that point.

Additionally, the need for support may vary depending on the usage and potential heavy loads on the system. The support feature could benefit from some improvement in terms of accessibility and responsiveness.

I don't encounter significant challenges or areas that require improvement while using the solution. Everything works smoothly, and I find it well thought out. It's got excellent compliance with MQP 9.0. Overall, I have had a positive experience with the solution.

I have been using the solution since 2017.

The solution is highly stable. As an example, at this moment, I am in front of my admin panel and can confirm that it has been running continuously for the past 173 days.

The solution is scalable, although I still need to utilize the clustering option. A single server is sufficient and efficiently handles most of our workloads. It effectively uses system resources such as memory, CPU, and disks, resulting in excellent performance with minimal resource usage.

So far, we have not needed any support from the solution's official support team or community. We rely on Google search and our team's research, leveraging various online resources to explore and implement solutions independently.

When I joined my current company, I initially explored Apache Kafka, but I realized that Kafka is primarily a log system rather than a queuing system. I encountered limitations with Kafka, such as maintaining pointers for each process and manually removing messages from the queue.

Comparatively, RabbitMQ proved to be more convenient as it automatically deletes messages from the queue when using auto or manual acknowledgment. Considering these factors, we switched from Kafka to this solution due to its efficiency.

The solution's installation process was straightforward, especially if you have good skills in installing software and a good command of Linux. Once the Bandit software is downloaded and extracted, the installation is completed.

After that, accessing the admin interface allows for a user-friendly GUI experience. The deployment process took around half an hour. 

We have a private cloud infrastructure using VMware, which means our servers are running on-premises and are owned by our company. We have a limited number of servers running the solution.

Specifically, we have one primary server and one secondary server without implementing clustering. Replicating these two servers is sufficient for our workload, and they can be installed by a single system administrator in just half an hour without any issues, provided they have DPU-installed Linux available.

Overall, I would rate the setup experience as nine out of ten.

The solution's pricing is cost-effective as it does not involve significant expenses. Licensing is required only for the server, while clients do not need any licensing. Therefore, it proves to be a cost-efficient option.

In my previous organization, we heavily relied on Tibco messaging solutions like Tibco RD (Rendezvous) and Tibco RV (Rendezvous) for the entire rating system. I have also explored Apache Kafka.

If you are looking for a queuing system for your application that guarantees insured delivery and ensures single delivery without duplicates, RabbitMQ is the right solution as it provides all these capabilities with ease of use.

With RabbitMQ, your application doesn't need to worry about receiving duplicate messages as the solution handles that internally, ensuring that each message goes through a single process for one delivery.

I highly recommend the solution and would rate it an eight out of ten.

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.

We can use the solution to move large amounts of data. Most of the functions have to be done manually.

The features of the solution are similar to Anypoint MQ. The transaction of data is pretty fast. Large amounts of data can be moved pretty fast using the solution.

The product is pretty hard to configure.

I have been using the solution for almost a month.

I rate the stability a seven and a half out of ten.

The tool's scalability is similar to that of Anypoint MQ.

The initial setup is complex. The product is deployed on the cloud. The configuration and setup are pretty complicated.

I use my own server and deploy the code with Jenkins.

It is an open-source product. We have to pay for additional features.

The configuration and setup of Anypoint MQ are easier.

People wanting to use the solution must learn how to configure and deploy it. If the documents are pretty clear, they will be easy to use. Overall, I rate the solution an eight out of ten.

The product's feature of data transaction works fast.

VMware RabbitMQ's configuration process could be easier to understand.

We have been using VMware RabbitMQ for a month.

I rate the platform's stability a seven and a half out of ten.

The initial setup is complex. It is difficult to find any documentation explaining the process. I deploy the code on the server using Jenkins.

It is an open-source platform. Although, we have to pay for additional features.

I rate VMware RabbitMQ an eight out of ten. You should know how to configure and deploy it on the servers. If they provide good documentation, it will be easier to use.

We primarily use the solution for consumers and publishers. It's for messaging and consumer publishing. That's it.

The solution is simple to use.

It's great for messaging and consumer publishing.

Companies can scale the solution, so long as they have server room.

The stability is good.

The user interface could be improved. We have an interface that shows the consumption rate, the number of consumers, their occupation rate. We should have a column in that interface that shows the estimated time until, at the current rate of consumption, the number of messages is to be consumed from a specific queue. That would be great. I wanted to read, however, as it is right now, JavaScript would have loaded the browser too much. Basically, I'd just like to see the consumption rate in each queue without too much fuss.

The solution could use some plugins that could be integrated into the server installation. We had a plugin that we used to delay something that from one version to the other was integrated into the server setup. Maybe it was more of an extension. However, more plugins could be also be integrated into newer versions of Rabbit.

I've used the solution since 2013 or 2014. It's been about eight years at this point. 

The solution is usually stable. We have problems with space on the Rabbit servers. When they are full, we might lose everything. That's a big no-no. This is a problem for Kafka as well, however, we have higher thresholds in that area. Rabbit is the poor brother to Kafka, so it receives less space. That's why, sometimes, in some departments, this problem occurs.

The solution can scale, however, we use a lot of space for Kafka. We have clusters through the servers, and there may be more for each department. If some needs appear, we can increase the number of servers in a cluster to better manage messages. As long as your company can increase the number of servers, it can scale. 

We have about 100 departments that use this solution in some way.

In our case, we have in our department five people and we have two clusters with Rabbit for two different directions. For us, it's enough. We do not plan to increase usage.

I've never directly contacted technical support. We use recommendations on the site, which is very good. I appreciate the recommendations, however, I'm not sure about the maintenance of the documentation from one version of Rabbit to the other. The older versions of the documentation might be less accurate.

Other departments might use, for example, Kafka, however, I'm unsure as I have no visibility on them.

I was there when the solution was initially implemented and, from what I recall, it took half a year. 

It was completely new. No one knew anything about it. However, we knew that we had to do something to improve the communication between departments. It was a good solution. That said, it took a long time before everyone understood how it works.

We had a few dedicated people who liked the idea of Rabbit and implemented it. It took a while for the rest of the company to get behind them and learn how to do it.

There are one or two people at any given time available to handle any type of maintenance responsibilities.

We handled the implementation process ourselves. 

We're using a few different versions. It depends on the department. Some departments have the latest, some don't, some use a very old version. I'm using 3.8. We do have plans to make an upgrade. 

It was a few years ago now when I learned this process of separating publishers versus consumers in terms of messages and communicating between departments. This was the biggest game changer for myself. I'd advise new users study that aspect and understand it.

I'd rate the solution at an eight out of ten. It's a very good tool and we use it all the time.