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.

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.

Of particular value to our environment and applications are the following Greenplum capabilities:

1. Scalable (Massive) Parallel Processing (MPP) – The ability to bring to bear large amounts of compute against large data sets with Greenplum and the EMC DCA has proven itself to be very effective.
2. Fast load of data into Greenplum – We experience performance of approximately 1TB per hour loading data to Greenplum without the use of specialized hardware.
3. MADlib (madlib.net) – There are a number of statistical and analytical functions available within MADlib upon which we rely. Among these are linear regression, logistic regression, apriori, k-means, principle component analysis, etc.
4. User Defined Functions in Python (UDFs in PL/Python) – Where MADlib does not provide a direct solution to an application problem, the ability to quickly prototype and deploy user defined functions with Python has been effective.

We would like to see Greenplum maintain a closer relationship with and parity to features implemented in PostgreSQL. The current version of Greenplum is based on a fork of PostgreSQL v8.2.15. This edition of PostgreSQL was EOL by the PostgreSQL project on Dec 2011. The current version of PostgreSQL is v9.5.

We began production use in November, 2011. Alongside Greenplum, we're also using EMC Data Computing Appliance v2.3.3 (8/10), of which we have two and a half racks in production, and one and a quarter racks in dev/tests.

We had no issues with the deployment.

The only issues with stability we’ve experience have been the sporadic fail over of primary to mirror segments. The environment continues to operate in this instance with the failure of queries that were in flight at the time of the fail-over.

We have had no issues with scalability whatsoever.

The service and support we’ve received from both Pivotal and EMC has been exemplary. The exceptions to this would be:

1. The EMC Request for Product Qualification (RPQ) process – EMC DCA support is contingent upon EMC approval of all third party software installed onto a DCA. There have been times that this approval has taken as long as 60 days to process.
2. Root Cause Analysis of Greenplum Database Incidents – When Greenplum Database incidents have occurred (e.g. primary database segments failing over to their backup), and Pivotal has been called for support, the response has been near immediate (30 minutes or less). Additionally, the incident resolution provided has been equally expedient. Where this has caused some disappointment is the response to our request for a root cause of the incident. These requests tend to queue up and we don’t seem to get answers beyond the typical vendor response of “that’s been fixed in the next release”.

The purchase of Greenplum was our first interaction with Pivotal. We have been a customer of EMC for a very long time.

My primary reason for reducing points on this rating is due to the fact that Greenplum is based on a fork of PostgreSQL v8.2.15 (EOL by the PostgreSQL project on Dec 2011). The current version of PostgreSQL is v9.5. There are a number of current PostgreSQL features of which we would like to take advantage (JSON support, materialized views, full text search, XML support, column-based permissions, row-based permissions, etc.).

I use the solution in my company for internal development. My company uses VMware RabbitMQ to develop an internal platform. In order to communicate with each other in our company, we use VMware RabbitMQ.

The most valuable features of the solution stem from the fact that it is flexible, resilient, and easy to improve and develop our company's projects.

The product needs to focus on offering more use case documentation because browsing the internet to find it can be a process filled with struggles. It would be difficult to find some documentation that can let you know how to choose the right integrations for the product. The documentation should be improved by the solution.

I have experience with VMware RabbitMQ.

It is a stable solution since it has worked 24 hours a year. The product has been stable and I have never faced any kind of problems with it.

It is a scalable solution since it is a product that is associated with microservices architecture.

The product is not used internally in my company and we use it to build products. The number of users of the tool in our company is something that depends on the kind of users or customers who are willing to buy our products. I know that my company deals with a customer who has 100 users and another customer with just 15 users.

When it comes to VMware RabbitMQ, you can get it ready to work in a matter of three to four hours. The tool has a very easy setup phase. It is also very easy to integrate it with other tools.

The product is available for free use since it is an open-source technology.

Speaking about the project or scenario where the solution improved the company's message processing capabilities of your system, I would say that working with microservices, you can allow the interaction between microservices in two different ways. One of the ways is synchronous, and the other one is asynchronous. For synchronous communication, my company uses RabbitMQ when microservices push messages into the queue. Asynchronous communication is used to collect and execute messages from queues.

With the microservices in place, my company does not need to deal with the clustering feature. The features associated with microservices are considered to be resilient.

Others who plan to use the solution should study the product behavior and the important thing is to be prepared in areas including important infrastructure components. VMware RabbitMQ is not a plug and play product, so there is a need to study about it from the partner and theory, while following the best practices.

With most of the products from VMware, users get minimal access to the user interface, but it is enough to deal with the projects we have in our company.

I rate the overall tool a ten out of ten.

Greenplum is a distributed database that we used for data warehousing.

The parallel load features mean that Greenplum is capable of high-volume data loading in parallel to all of the cluster segments, which is really valuable.

The service management capabilities are good.

The external data integration with Parquet, Avro, CSV, and unstructured JSON works well.

It has an advanced query optimizer.

The initial setup is somewhat complex and the out-of-the-box configuration requires optimization.

- OS settings need to be tuned according to the Install guide.

- Only group/spread mirroring by gpinistsystem, block mirroring is manual (Best Practices Guide)

- Db maintenance scripts are not supplied - some of them added in cloud - need to be implemented based on the Admin Guide.

- Comes with two query optimizers, PQO is default, some queries perform better with the legacy planner, it needs to be set.

We have been working with Greenplum for about five years.

Greenplum is pretty stable.

This product is absolutely scalable. We have more than 400 users in our database.

The technical support is exquisite.

This is a company that really listens to its customers. I am very happy with our relationship.

Before I joined this company, I used different data warehousing solutions.

Making the transition to Greenplum requires a completely different mindset because it is massively parallel. It's more like a Big Data mindset, where you need to consider that you are distributing data between cluster nodes. It is not always straightforward to make the switch.

The initial setup is kind of complex. You need an expert to set up a Greenplum cluster.

It may not be possible to simplify the initial setup because there's an out of the box configuration and you can use it. I've actually seen companies using it for years and it works, but it didn't work optimally so they were not happy with the results.

You can set up Greenplum but you really need to read the manual and the installation guide. I've seen people skipping it and then complaining.

A few people are enough to maintain this product. If you want to have around the clock support then you will need a couple of people in different time zones, but generally, maintenance is straightforward.

We are currently in the process of upgrading from version 5.26 to 6.11 and I can already see a lot of improvements. I can't wait to try them. According to the roadmap, there are a lot of new improvements coming in the V7 version, which is due out next year.

My advice for anybody who is implementing Greenplum is that they really need an expert to assist them. They might hire consultants or grow experts in-house, although that takes time and it is not always straightforward. You can use Greenplum out of the box but to really leverage all of the capabilities, you definitely need to tune your system and also design your database objects.

When people think about a database they usually think about Oracle, Mircosoft SQL, or maybe MySQL. Greenplum is a distributed database that needs a completely different mindset. I think that when people start to use it, they don't really understand. For example, you cannot switch from Oracle to Hadoop because you will need the same change, but when they switch to Greenplum from Oracle, or just put data from Oracle to Greenplum, they don't consider this change as seriously as they would for Hadoop.

Overall, I am very happy with this product.

I would rate this solution a nine out of ten.

My team uses Greenplum for automating a lot of job writing scripts using PSQL. We use it to automate reports. Also, I use the identity workbench for logging in. In addition, I use DBeaver as well.

It works very well with large database queries. It works efficiently even in cases where you have a query worth terabytes of data.

Its most valuable feature is the ability to quickly run through data. It has a good processing speed as well.

They should improve product performance. It does not share resources well whenever it has more than one process running. If you have a user consuming a huge load size of resources, it takes down the entire system.

They should work on resource pulling and sharing those resources properly. At present, it allows one user to completely take over everything.

We have been using the solution for eight or nine years.

I would rate the solution about seven or eight out of ten for its scalability. Around 30-40 people in my organization are using the solution. We are not looking to increase usage. 

You eventually have to get new hardware because the CPU stops quickly once the load increases. It's only limited to hardware. You don’t realize you need new hardware until you have to because it doesn’t have throttles.

We have used Snowflake, Oracle, and many such solutions.

The setup seems pretty straightforward.

The solution has its limitations. It works better with a serial-threaded program than a multi-threaded program. If you go for the solution knowing that, you should be fine. I would rate the solution as a six out of ten.

We use the solution for the asynchronous call and POPS mechanism.

The most valuable feature is asynchronous calls, which are easy to configure.

We needed to configure additional plugins. While it was relatively easy to do this on-premises, it became more challenging in the cloud.

I have been using VMware RabbitMQ for one year.

The product is stable. We haven't faced any issues.

VMware RabbitMQ needed to be a more scalable product. It wouldn't perform consistently if you wanted to add workload or users or reduce workload. We faced problems with it during heavy loads. The cloud version is scalable. We can scale it up or down based on our requirements, such as the number of users or workload.

Around seven or eight people were in every group, and many teams were using it for virtual use.

The infrastructure was handled by a person responsible for configuration and related tasks. I primarily focused on configuring connections as a developer. I could handle it by installing components like plugins. When issues arose in the cloud environment, we escalated them to the support channels.

We installed VMware RabbitMQ on a local computer. We are currently using Docker and Kubernetes for deployment in our local environment. It was relatively easy to deploy compared to an on-premise system.

The solution can be a bit challenging to handle. Not every configuration and deployment works seamlessly. It depends on the project team and compatibility, but is relatively easy to use.

The product is free of cost.

We configure the monitoring and alerting for the RabbitMQ setup. We transfer the message to the designated queue if there are any errors or similar issues. We use a Spring Boot application and microservices for this purpose, making it easy to route the message.

If you want to use this solution, you first need to understand the concept of exchange queues. Certain clusters require specific knowledge. The configuration may vary depending on the application type. For instance, the configuration was relatively straightforward in our case with microservices. We only needed to provide authentication and the correct URL. If it ran on a cloud environment, we would provide the instance, username, and password, and the configuration would be handled automatically. It would depend on the language and the specific type of microservice or application for more advanced customization, such as writing code.

The solution is easy to use, configure, and install.

Overall, I rate the solution an eight or nine out of ten.

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.