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.
VMware vSphere | Horizon View | Citrix Virtual Apps | Microsoft Intune | Azure | SCCM | Windows 365 at Adecco
Real User
Top 5
Oct 14, 2025
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.
Senior Director, Engineering at Tanla Solutions Ltd
Real User
Top 10
Aug 1, 2024
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.
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.
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.
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.
Senior Manager of Operations at a comms service provider with 10,001+ employees
Real User
Dec 12, 2023
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.
VMware Tanzu is a robust platform tailored for data warehousing, complex analytics, BI applications, and predictive analytics. It excels in scalability, performance, and parallel processing, enhancing data handling efficiency. Users report significant productivity improvements and streamlined operations, making it ideal for comprehensive data solutions.
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.
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.
There is general room for improvement.
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.
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.
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.
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.
We needed to configure additional plugins. While it was relatively easy to do this on-premises, it became more challenging in the cloud.
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.