VMware Tanzu Data Solutions Reviews

We are working with Cisco in terms of DLP, which is a data prevention solution. Nowadays with VMware, after the acquisition by Broadcom, there are a lot of complications. To be honest, there is less market share for what we do on the VMware perspective because the entire license structure has been changed after the acquisition by Broadcom.

I am working across VMware products. I'm working with VMware Tanzu Data Solutions as well, including containerization, Kubernetes, and everything altogether.

The feature I find most valuable in VMware Tanzu Data Solutions is in terms of management. The management tool is much easier to access when comparing to other brands.

That's also what I'm saying about seamless Kubernetes integration. If there are any issues, the operations are also easier than with other competitive tools.

Regarding the multi-cloud feature by VMware Tanzu Data Solutions, many of the other brands have certain limitations. VMware Tanzu Data Solutions has no limitation. We can meet the maximum customer requirements.

Data transformation is a management tool done by Tanzu Mission Control.

From my perspective, the biggest challenge with VMware right now is the pricing. To be very honest, in many cases I find myself recommending alternative solutions instead of VMware. Even if those alternatives come with a bit more complexity, customers are often more willing to accept that than the current VMware pricing model.

In the past, VMware used a socket-based licensing model, which was easier for customers to understand and budget for. Now the shift to a core-based licensing model has significantly increased costs for many environments, especially for organizations running modern high-core CPUs. One positive aspect of the new model is that VMware has bundled several components together. For example, earlier when deploying vSphere, customers also had to purchase vCenter separately for management. Now multiple components are packaged into a single SKU, which simplifies some aspects of procurement and deployment. While this consolidation has its benefits, the overall licensing and commercial costs remain very high.

Pricing is not the only issue. I believe Broadcom also needs to reconsider its strategy in light of the current market conditions. The approach they are taking may be strategic from a business perspective, but from what I see in the field, it is leading to lost opportunities. Many customers who previously relied on VMware are now actively exploring alternative virtualization platforms. I’m not sure where this direction will ultimately lead, but based on my experience, it is already affecting adoption. Since you’ve been trying to reach me for some time—and we also had a discussion a couple of years ago—I hope this feedback helps Broadcom understand the current sentiment in the market and potentially make adjustments.

Another important concern is the way features are bundled. In many cases, customers only need basic virtualization and high availability capabilities. However, the current packaging often includes additional features that they may not need. A good analogy is that if a customer only needs an entry-level car, we shouldn’t be forced to sell them a Rolls-Royce. VMware could benefit from adopting a more modular or à la carte licensing model, where customers can choose only the components they truly require. For example, if a customer only needs core virtualization functionality, they should be able to purchase just that. This would allow partners and solution providers to better align solutions with customer requirements and position VMware more competitively in the market.

Another challenge I want to highlight is the pricing model based on U.S. dollars and the way multi-year licensing is handled. In many enterprise and government projects, customers prefer to commit to three-year or five-year licenses and pay the full amount upfront. However, in approximately 20% of the deals I work on, we lose opportunities because VMware only provides dollar-based pricing for the first year. When it comes to the following years, the contract requires renewals annually rather than allowing a fixed multi-year upfront payment.

This approach is particularly problematic for government and public sector customers. Many of them are ready and willing to pay for three or five years in advance, but the current VMware model does not support that structure effectively. Because pricing is tied to the U.S. dollar and subject to yearly adjustments, VMware does not lock in pricing for the full term. From a customer’s perspective, this introduces uncertainty and makes procurement more complicated.

Ideally, if a price is quoted—for example, $100 per year—it should remain consistent across a multi-year agreement. Customers would be comfortable committing to a five-year term if the price were fixed and predictable. Unfortunately, that flexibility is currently not available across VMware products, whether it is vSphere, VMware Tanzu solutions, or other offerings.

For large enterprise environments, one-year commitments are usually not practical. Many enterprise customers prefer longer-term agreements for budgeting and procurement reasons. Even when they are willing to accept the higher cost associated with the core-based licensing model, the lack of a clear multi-year upfront option often becomes a deal-breaker.

For VMware Tanzu Data Solutions, I have been using it for about five years since it came out. With VMware, it's more than a decade.

The support is also good. If anything happens in terms of technicalities and I raise a ticket, they address it immediately, irrespective of the SLA agreement.

In terms of support SLA, I can give an eight out of 10.

Positive

My main use case for VMware Tanzu Data Solutions is Tanzu Basic TKB version 2.4.

I focus on the creation of Kubernetes clusters with VMware Tanzu Data Solutions.

VMware Tanzu Data Solutions has positively impacted my organization because it is efficient, easy, fast, and aids in the creation and administration of web servers.

The best features VMware Tanzu Data Solutions offers are its speed and the creation of web servers.

These features help me day-to-day with the creation of Dockers and other tasks.

The principal aspect is the creation of Kubernetes clusters.

VMware Tanzu Data Solutions can be improved as it is better and faster for administration and clusters, Dockers, and Kubernetes.

Improvements are needed in the documentation.

I have been using VMware Tanzu Data Solutions specifically for two years in my experience.

VMware Tanzu Data Solutions is stable.

Its scalability is an upgrade for both Broadcast and VMware.

Customer support for VMware Tanzu Data Solutions has been good with me and with VMware, including Broadcasts.

Neutral

I have not used any different solution before VMware Tanzu Data Solutions; only VMware Tanzu.

For deployments, both scenarios are good: on-premises, public cloud, private cloud, or hybrid cloud.

I administer deployments using Azure and Google Cloud; both scenarios include Azure for cloud and Google Cloud for on-premise.

I have seen a return on investment with VMware Tanzu Data Solutions because of its speed and the robustness of the environment.

My experience with pricing, setup cost, and licensing for VMware Tanzu Data Solutions is that it is a bit expensive.

Before choosing VMware Tanzu Data Solutions, I evaluated other options.

My advice to others looking into using VMware Tanzu Data Solutions is to use containers and Dockers. I rate this solution 9 out of 10.

We mainly create functions and scripts required for reporting.

The product is not complex; I do not have to create stored procedures, functions, or views. It's just simple to use.

There is general room for improvement.

I have been using it for five years.

I have faced stability issues, mainly due to the storage my organization has, though I am not sure if it's specifically due to the tool. For stability, I would rate it six out of ten.

Scalability issues are present. Most of our functions or jobs are queued due to that. I would rate scalability six out of ten.

I have never contacted the support team.

On a scale from one to ten, I would rate the solution a seven. I would recommend this product to other people.

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.

With RabbitMQ, I appreciate that it's an open-source platform. 

RabbitMQ provides access to SDKs for development and the ability to raise and log tickets if we encounter issues. We can integrate RabbitMQ using various languages like Java or Python using the provided SDKs.

By comparison, Anypoint MQ it is a bit difficult. It's not open-source, so we have less flexibility. It's tightly coupled inside the Anypoint platform. This gives an advantage to clients already heavily dependent on the Anypoint platform, as they can easily adopt Anypoint MQ. 

Aside from that, Anypoint MQ is generally well-optimized inside Anypoint. Other aspects like reliability are standard across queueing systems. 

I haven't encountered any issues with the features I've used within the queueing functionality. Since queues provide message reliability, that's our primary concern.

RabbitMQ integrates easily. It's open-source and provides the required SDKs for development.

Overall, the aspects I've used – queues and monitoring – have been up to the mark.

Implementing a circuit breaker scenario using RabbitMQ is complicated. This complexity arises because manual intervention is required to manage worker details and handle operations based on worker IP addresses.

The use of public and private ports, specifically HTTP 8082 and HTTPS 8092, introduces complexity.

So, we had thought about moving away from RabbitMQ to Anypoint MQ because there is a complex scenario where we need to implement a circuit breaker. 

Using RabbitMQ is getting complicated, so we need to implement it manually. Anypoint MQ is well-optimized within the Anypoint platform itself. Anypoint MQ is a Mule-related broker, so it's very well optimized for the Anypoint platform itself. So, it will be easy if we are using Anypoint MQ; we can implement this circuit breaker scenario in a very easy way.

But because using RabbitMQ, it is a bit complex, because we need to get the details of the worker and we need to catch, we are stopping the worker based on how many workers we are having by getting their IP addresses, and this stuff is getting pretty much complicated. Then, all this stuff will work when you are on HTTP's public port 8082. But in general, we won't use public ports. HTTP 8082. We generally use 8092, which is a private port over HTTPS configuration. 

This will help us in several ways: the security purposes of the organization and everything else. So, that's why it's getting a bit complicated to implement this scenario while using RabbitMQ. So we got to move to Anypoint MQ.

I have been using it for a year. 

Based on my experience with this solution, I would rate the stability a nine out of ten.

I would rate the scalability a nine out of ten.

We haven't had to escalate any issues on our end with RabbitMQ; the features we use have been working well.

We're considering moving away from RabbitMQ and towards Anypoint MQ. The reason is that we have a complex scenario where we need to implement a circuit breaker using RabbitMQ, and it's proving difficult. 

Anypoint MQ, being a relatively new broker, seems well-optimized within the Anypoint platform itself, making it easier to implement this circuit breaker pattern.

Using RabbitMQ, we'd need to manually gather worker details, stop workers based on their IP addresses, and so on. It gets especially complicated because in a typical production environment we wouldn't expose public ports like HTTP 8082 – we generally use private ports like 8092 over HTTPS for security reasons. Due to this complexity, we're inclined towards Anypoint MQ. 

I also worked with ActiveMQ. It's quite similar to RabbitMQ, also open-source. I'm not sure why ActiveMQ isn't as widely used anymore, maybe due to pricing changes. Currently, I mostly hear about RabbitMQ and Kafka being used.

I didn't have much involvement in the setup process. 

My access is limited, so I mainly use it for creating queues and other resources for code reusability. I am not utilizing the full range of RabbitMQ's features, just the queueing aspect at this point.

Our access is restricted to the service queue level, where we handle messages coming from the queue into the code.

The only thing I have observed is that Anypoint MQ is cost-effective. But more importantly, it is well-optimized with the Anypoint Platform. So, if someone wants to implement multiple scenarios and keep everything inside the platform itself... it's an IPaaS, an Integration Platform as a Service. If they want to keep everything within Anypoint, they can choose Anypoint MQ.

Some companies or clients think, "No, I don't want to use multiple technologies. This will end up complicating things. Let me keep everything on one platform."

In that case, they'll go with Anypoint MQ, even though they don't have complete access to the Anypoint architecture. They can't make changes to the platform or Anypoint MQ unless they understand the complete architecture. Mule doesn't reveal the internal architecture of how things work inside the Anypoint Platform, so it's not possible.

So, the only advantage is the optimization. Mule is optimizing Anypoint MQ internally.

There were also concerns about things like vendor lock-in and a limited community.

Currently, Salesforce has acquired MuleSoft, and they are expanding. So, in the future, Anypoint MQ will definitely be a stronger competitor for RabbitMQ and other queues we currently have. They'll likely provide more features in the future.

I would recommend using it. The only thing is that RabbitMQ can be used with any programming language, and we can use any web portals. H

owever, Anypoint MQ is exclusively for MuleSoft and is not available outside of the MuleSoft platform.

Overall, I would rate the solution a nine out of ten.

It is a stretched cache layer between two data centers. It allows active implementation. We put our application cache data, load it into memory, and make it accessible across multi-data centers.

The solution improved our site reliability.

The stretched cluster is a valuable feature.

When we had outages, we had timeouts. Sometimes, the nodes would drop out of a cluster. Therefore, the applications would get timeouts. There is a newer version out that we're planning to upgrade to for some stability. It could also be caused by our design. 

The product must improve its reliability. It'd be nice if nodes could drop out and notify each other in a timely manner so that the applications wouldn't know if there was a problem.

I have been using the solution for six years.

I rate the tool's stability a six out of ten.

I rate the scalability of the tool a seven out of ten.

The initial deployment was a little difficult. We needed 25 people for the deployment.

The price is pretty good. It is a CPU-based system. The price depends on how big our cluster is.

People who want to use the product must not choose a stretched cluster. They must implement it as two separate clusters. We chose stretched clusters, but it caused some issues for us. Overall, I rate the solution a seven out of ten.

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.

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.