VMware Tanzu Data Solutions Reviews

We use the solution for event-driven programming. We have multiple queues and channels to provide scenarios for publishing into containers. You have to communicate the microservices, and consumers consume the services. 

We were using the solution to setting the tenant settings into the service. For example, if you have five microservices using the tenant settings, after updated, we publish the updates to other microservices. It helps get the updated data to be able to publish the settings into the updated queue.

The queues and the publishing are quite useful. We're able to create hierarchies and control channels and flows to control what is going from which queue.

The solution can scale.

It is stable and reliable. 

The availability could be better. When something crashes, a queue gets deleted, and my data is lost. They need to improve this so that we don't lose data during issues like crashes.

We'd like to understand how many queues are running on RabbitMQ. I'm not sure how to get these details and how to verify the information.

We need other protocols. 

I've been using the solution for three years or so.

The solution is stable and reliable. There are no bugs or glitches. 

The solution is scalable. However, we have issues with availability. 

Sometimes, it is hard to understand what is going on when you reach out to technical support.

Our DevOps team deployed the solution. 

I'm not sure what the exact pricing is. I don't handle the licensing aspect. 

I am using the latest version of the solution. I'm not sure of the version number. 

I've used this on multiple projects, and it has proven to be quite useful.

I'd rate the solution nine out of ten. It is a very good tool. 

We are using this product as a database for our platform. We are customers of VMware and I'm the project architect. 

In general, I think this is a very good platform, particularly as it's open source. It fits very well with use cases for public institutions or universities, where there is not always a big budget.

I'd like to see more support for structured data and features related to queries on NoSQL keys, extra filters would be helpful. 

I've been using this solution for two years. 

We've been working on this project and using this solution for two years and it's performed very well. 

The solution is scalable. We have around 20 users working directly on this platform and around 1,000 end users. 

We also use Cloudera and Oracle so we have a few alternatives. We currently use Greenplum because one of our customers needed an open-source solution that would scale well and after some investigation, we went with Greenplum. 

The initial setup was straightforward and we carried out the implementation ourselves. 

We're using the open-source version so there are no licensing fees. 

I recommend reading as much documentation as possible before starting to use the product. It helps to know how your data model should be implemented in order to get the best out of the platform and to figure out how it can improve performance, 

This is one of the best solutions I've used and I rate it eight out of 10.

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.

We use VMware RabbitMQ to transfer information from one point to another. 

VMware RabbitMQ needs to create a new queue system. 

I have been using the solution for one and a year. 

My company has 10-15 users for VMware RabbitMQ. 

VMware RabbitMQ's installation is easy. However, it doesn't come with any manuals. 

You should use the solution if you want to store your details in the queue and start taking inputs from the queue. I rate it a nine 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.

With VMware Tanzu Greenplum, one can make a huge database table and analyze the queries by adding in the SQL command. Some hint or command for the query goes over the multi-parallel execution. Also, queries can be sent quickly to other database systems.

VMware Tanzu Greenplum needs improvement in the memory area and improved methods for quick access to the disc. So, one of the quick goals of Greenplum must work on enhancing access to the disc by adding hints in the database.

I have been using VMware Tanzu Greenplum since 2017. I have installed the ring through the Dell Dell Platform, the EMC platform, and the DX100.

We use the VMware Tanzu Greenplum support directly, the community for open source Greenplum database. I rate it a seven out of ten.

Neutral

The initial setup was complex because of the architecture we used. Ten people are needed to maintain the product, of which eight are DBAs, and two support the operating system as the administrator.

For the support network of the product, overall installation, use of the database, and improved database and support, I rate the solution an eight out of ten.

Tanzu Greenplum's most valuable features include: the integration of modern data science approaches across an MPP platform, including the ability to massively denormalize data and spread it across your MPP segments; the ability to index data and make it searchable, which significantly reduces the need for ETL; its fast performance. Tanzu Greenplum is also very active in providing additional functionalities and software when needed, like GPText indexing of JSON events.

Tanzu Greenplum's compression for GPText could be made more efficient.

I've been using Tanzu Greenplum for eight years.

Tanzu Greenplum's overall performance is outstanding.

Tanzu Greenplum is highly scalable.

VMware's technical support is probably the best I've seen.

The initial setup was very easy.

Tanzu Greenplum's pricing is really competitive and gives excellent value for money. I'd say that the benefits of orchestrated deployment and the features of GPText make the licensed version worth it.

When considering implementing Tanzu Greenplum, I recommend viewing it as a massive lakehouse, not just a data warehouse. I would rate Tanzu Greenplum ten out of ten.

The use case involves the transferring of messages between services. It includes asynchronous messaging and I also need messages flowing to multiple microservices. In this case, it's basically a fan-out mechanism.

RabbitMQ is configurable and quite flexible.

The performance is fast and reliable.

It is easy to use. The addition of more queues and more services can be managed very easily.

There are some security concerns that have been raised with this product.

The configuration works with a config file, where all of the controls, including that of the administrator and user access, are stored there. The security isn't very stringent or very elaborate.

RabbitMQ is a stable solution.

This is a scalable product. There are six or seven services that are connected and using it.

I have not been involved with anything that necessitated contacting the support team.

Previously, we were using MSMQ, which is the Microsoft Message Queuing service. However, with the new version of .NET 4, support for MSMQ was no longer available. We could no longer get the libraries. As a result, we had to switch to a different queue mechanism. 

I have also used Azure Queue.

The initial deployment was quite easy. It took less than half an hour to get it up and running.

I deployed it myself.

The pricing for RabbitMQ is reasonable. It is worth the cost.

We researched ZeroMQ, RabbitMQ, and Kafka. We found that Kafka was a bit of an overkill because our requirements were quite simple. RabbitMQ was pretty easy to set up, which is why we chose it.

My advice for anybody who is implementing this product is to establish your users and exchanges properly.

In general, I'm quite comfortable with RabbitMQ. It satisfies my requirements and the main complaint I have is about the security.

I would rate this solution a seven out of ten.

We use this product for general purpose messaging in cloud-based environments and as an implementation to MTP spec. We are customers of VMware and I'm a senior technical consultant.

One of the key benefits for us has been the ability to use this solution for microservice architecture communications because it provides great flexibility. One of our clients was able to push messages from the source which were replicated and forwarded to all the other brokers nationwide. Everyone who needed it, received it, and it's very cost-effective. 

The high availability and not having to replicate is valuable as is the message consumer. It can be configured depending on the use case to be a very fast message broker. I like the stability, the built-in admin tools and the plugin architecture. One of the things that makes it unique is that all of the components for messaging can be created programmatically, meaning you can have services or applications that get spun up or have auto incrementing instances. If you're in an elastic environment, you don't have to pre-configure the messaging system and the keys don't have to be known ahead of time. 

One of the issues is that as soon as you go outside of a switch or not in IP address range, the clustering no longer has all the wonderful features so clustering outside of network boundaries is a problem. I'd like to see stream processing as an additional feature. Kafka has a streaming API and I'd like Rabbit to have that too.

I've been using this solution for nine years. 

This solution is very stable, no problems there. 

This solution is very scalable and the number of users really depends on the organization. 

Technical support is good, very good. But because the underlying implementation technology is Erlang, sometimes the technical problems are at that level, in which case there's one major technical solution provider called Erlang Solutions. They're okay but if the problem goes past the product level and into the technology level, then there can be a delay in getting support because you're dealing with two companies and two technical support services. 

These days the initial setup is moderately complex because it uses a technology that is worldwide, Erlang, which is obscure. You have to install Erlang first and that is moderately difficult. Deployment takes about a day. 

They use a credit based system for licensingwhere you purchase credits. People don't like it.

My advice would be to have the messaging topology mapped out before you deploy to make the process from installation to a functioning solution more efficient. If you start looking at the topology from the revenue perspective, it usually ends up with more iterations to implement the correct topology, whereas if you start off mapping and then install, it's a more efficient way to go about it. 

I rate this solution an eight out of 10. 

We use the solution on our SaaS platform to speedup and simplify customer access across services.

Some of the most valuable features are “publish and subscribe”, fanout queueing, and scalability.

We have a number of different use cases in our scenario. A key one is “publish and subscribe”. We have spent the last year breaking up a large monolithic application into microservices and each microservice has to subscribe to different events for the purpose of CQRS and other kinds of updates. RabbitMQ is perfect for “publish and subscribe”. It does an awesome job at fanout, perfect for CQRS, messages are delivered to all subscribers with almost no additional latency.

RabbitMQ provides the ability to scale queues in a very simple and elegant way. If it had a “failure queue” with robust delivery and recovery built-in with the same power, that would be great. We use a completely different queuing system for failures. So there is a little more effort to take messages in a failure queue, analyze them, figure out what went wrong and then restart them in Rabbit. It is doable, and we do it, but if we had a round trip solution in Rabbit, that would be awesome.

For me, having a robust failure queue, is high on the list of improvements needed in the near future. This is an important update needed because right now we are using Doctrine for our failure queue. Doctrine does a great job.

I have been using the solution in the past year.

Rabbit is a very scalable solution. We could easily queue 50,000 messages in less than a minute. The first day we introduced Rabbit to replace another queueing system that we were using, there was disbelief on the part of the product team because the response was so fast. We need tens of thousands of messages queued in a short period of time, approximately one minute. For example, one user action could spawn 65,000 messages. We also need the ability to segregate different queues. This solution did a great job.

The installation is very simple and elegant, and we love the graphics. It lets us see exactly what is happening with the ability to start the queue, stop the queue, consume messages on the queue. This is a huge help.

We design, develop and deploy the solution ourselves.

We are also evaluating Apache Kafka. Our process is very disciplined. We look at the analytics, the abstraction, the architecture relative to our technical architecture, we ask ourselves questions about the use case, which is better for use A or B. Kafka is not as simple for “publish and subscribe”. You can do it, but not the best fit for us. However as a queueing system, Kafka is great. The records are stored on the queue in the order they are received, However, you can easily search by topic no matter how large the list. Important if you keep track of everything.

There are many different use cases for each technology, as well as many approaches. So have the architecture team graph and document every solution. Have a few training days to clarify the goal, the solution and the implementation. One of the things we do in our training is to actually create prototypes, the abstract model of our ideal state. This demonstrates exactly what we all need to do. Developers understand more quickly with a model. It flattens their learning curve and they are more productive more quickly.

I rate VMware RabbitMQ a ten out of ten.