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.

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.

Postgres is a database. Like Oracle is a database, this is a database.

We replaced our Oracle paid database with the open-source Postgres database, and we migrated around 50 lakhs of consumer data there with different rows and tables. We deployed this in different production staging and testing. We created three deployments, and each deployment has three servers.

Earlier, we were using the Oracle paid database, which is a commercial product. Then we switched to open-source due to the fact that we have lots of new projects and we could not handle the licensing costs. So we migrated our data from the Oracle Database Server to the Postgres Server. It helped us to evaluate the cost. We saved lots of money in terms of licensing.

It is open-source.

It provides the database load-balancing capability itself. It has data, like Pgpool, an open-source database, and a load balancer also.

We can also create the cluster in between the database in active, standby mode.

The solution is stable.

It's scalable. 

It doesn't have any GUI-based monitoring tools. Oracle has some proprietary tools for monitoring all the databases and all that. Postgres doesn't have any graphical capabilities where we can monitor the database. We have to do it with the Sierra stuff and run some random commands. Then we can get the data from the cluster and databases table.

The initial setup is complex. 

It would be ideal if they could provide an active cluster in Postgres. If one primary DB goes down, it should automatically fail over to the second database.

We've been using it for four years. I've used it since around 2018.

It's stable. There are no bugs or glitches. It doesn't crash or freeze. It's reliable. 

It is very scalable. 

From the user's perspective, we have around 500 users. However, we have around 50 lakhs of consumer records in the solution.

We plan to increase usage. We already added the sponsors, and we require the capacity and the transactional processing. Therefore, it's scalable. We don't have any licensing restrictions, so we can add on as required.

While we don't have technical support, we do have creative support. They are quite good.

Positive

We used to use Oracle Database.

We required lots of planning during the initial setup. The migration phase is very complex when you move from Oracle to Postgres. The installation and configuration have a moderate amount of difficulty.

The deployment and maintenance require three people, including one system administrator and two database administrators. 

We handled the initial setup in-house. We didn't need any outside assistance.

We haven't invested any money into the solution and therefore haven't looked into ROI.

We have zero licensing costs. The solution is open-source.

We also evaluated some parts of MySQL. However, we didn't find it very suitable and scalable.

You need to be clear about your use cases and the transactional requirement you are observing from the database architecture before beginning with this solution. You need to consider your architecture based on the scalability and reliability of the applications. You need to take this into account before deploying any solution to Postgres.

I'd rate the solution eight out of ten.

We were using it as a high-volume text messaging solution. 

It's fully open source, has a high throughput, and the serviceability is good.

This solution struggled with multi-regional synchronization.

The stability of this solution was very good. 

The scalability was good. It's very comparable to the other databases on the market. We were doing 5,000 transactions a second, and probably one third of those were unique users at any one time.

The tech support was fine. We rarely needed to use it. 

The setup was pretty straightforward, just standard database install stuff.

For maintenance, we had a single DBA, and a couple of people on our software development team served as their backups.

On a scale of one to five, with five being the most competitive pricing, I would rate this solution as a four. 

We were using SQL Server in some circumstances, and the two solutions are very comparable, other than one being open source and one not. We've also used Cassandra, Bitquery, and a whole bunch of others. Each solution has unique advantages and disadvantages. From a feature standpoint, this solution is relatively close to parity in the environment. It stands out because it's opensource and cost effective, and it does everything pretty well.

For those looking into implementing this solution, my advice would be to think about how you want to handle multi-regional replication.

I would rate this solution as an eight 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 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.