VMware Tanzu Data Solutions Reviews

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.

I primarily use the solution for research purposes. I've utilized it for my academic studies for comparing HTTPS protocols. RabbitMQ supported the protocols I needed and I've read also that it's one of the most commonly used broker services.

The solution has really cool features to use. Its management console is excellent. You can utilize plugins to view the performance of the whole service on one network. It's wonderful. I really like it.

I was struggling with installing a few things. It would be good if was somewhat similar to RedHat. There should be more documentation regarding installation troubleshooting.

It's pretty straightforward, the setup, but it would be useful to know what to do if you do face certain challenges. Right now, without more in-depth documentation, it's unclear.

I've been using the solution for about one or two months. It's rather new to me.

The solution is very stable, from what I've witnessed so far. It's also a very fast system.

I haven't scaled the solution myself, so I can't speak from personal experience. I have heard that the solution is not so simple to scale because there is a core node beside the solution. There's some sort of smoothing methodology when it comes to the messaging, so I assume it's not so simple.

I've never contacted technical support for assistance.

The initial setup was simple. The first time I installed it, I installed it on Windows. For me, it took about one hour. If a user was facing a few problems, I'd say it could take up to two hours. Typically it's pretty quick to set up because the recommendations are pretty good.

I handled the initial setup myself.

I was considering using ActiveMQ on AWS, but after some research, I decided RabbitMO was a more complex solution and one that is more commonly used, so I chose RabbitMQ over it.

I'm only really using the solution for the purposes of research. I've just installed and am working on the latest version. My interest in the solution is purely academic, so I can't speak to how it would function within an organization.

I'd definitely recommend the solution, especially over HTTP in the Nico services platform. I've done my research and have discovered it's two times faster and more commonly used. It's also really easy to use on the Nico services platform because all of the components are in the cloud.

I'd rate the solution eight out of ten.

My company runs on high availability. It is known for high accuracy in its items that are being shipped.

To do this, drivers/vendors who are shipping these items have to send their location details frequently to the server to update their current location. It all depends on accuracy.

Based on this, the end user can plan to receive shipping items on his end. We wanted a JMS tool that can create 'queues' on the fly and pass messages from one system to another.

• Queues and topics
• Native cloud app support
• Light-weight
• Easy maintenance
• Simple and straightforward admin portals: Made it easy for users and worked out excellently for our requirements

The solution needs improvement on performance.

It was stable enough to process our requests.

We were able to operate multiple nodes and we implemented a load balancer to meet our high traffic requirements.

We have never needed technical support. It was all there in the API documents provided by RabbitMQ and there are numerous blogs available on internet.

We analyzed our requirement thoroughly and were sure that RabbitMQ was the solution for us. We didn’t look at anything else.

It was bundled with PCF, so it was never a problem for us.

Again, it was part of PCF bundle, so that was never a worry for us.

This is a great product. It is lightweight, supports cloud native applications, is easy to implement, is easily manageable, and has excellent support. I would say, just go for it!

We're using this as our central messaging bus. It drives our micro-service architecture.

• Great management UI: The best in its class of messaging products
• Very sophisticated routing control and priority messaging capabilities

• The product should have much better scaling and scalability capabilities. Currently, they're really falling behind some of the competitors such as Kafka and NSQ.
• The installation of the HA version and clustering mechanism should be made much easier.
• The fact that a single queue can't be distributed across multiple instances/nodes is a major disadvantage.

We had multiple issues with stability. The product tends to be highly unstable when under heavy loads.

We had multiple issues with scalability. The product's scalability is rather problematic. It tends to be very complex to maintain with various sharding and high availability options.

I have never used technical support.

We tested some earlier version of Apache Kafka, but it wasn't stable enough at the time. At the moment, we're considering switching back to Apache Kafka.

The non-sharded/clustered setup is very easy and straightforward. The clustered solution setup is much more complicated.

We have only used the open source version.

We evaluated Apache Kafka, NSQ, and ActiveMQ.

Check the scaling issues. If scale is not an issue and you're just looking for a stable messaging queue, I would highly suggest it.

If scale is an issue, I would suggest using Apache Kafka.

I've found that the database warehouse, data compression, and ETL to be the most valuable features for us.

Loading batch data has really improved the efficiency of our organization.

I'd like so see better scaling, better performance from in-memory databases, and a higher compression rate. We have been facing some performance issue when doing batch loading with optimizer the scaling does works fine. They are working on having optimization techniques which made me write room for improvement.

I've used it for over two years. I have been working very closely with the EMC folks.

Yes, at times, but it depends on your modeling and data retrieval.

It's been stable for us.

Its scalability needs to be improved.

I would rate technical support as good and there is not much technical expertise at the start of the SR.

We tried other MPP’s.

It was complex, but there was a change in the setup.

We got support from the vendor at the start.

If you want to implement this product, you would need to scale your product well before trying to implement.

The most valuable feature of RabbitMQ is the ability to set up workflows simply with configuration. We had some very complex problems (logging, auditing, sequential and parallel operations) that have been easily solved by inserting a queue in the middle of an existing workflow.

Our software has evolved dramatically over the past 18 months of development.

Major modifications to business logic have been handled easily. This is because each operation that the software performs has been atomic. That was then wired up with other operations via RabbitMQ exchanges/queues,

• RabbitMQ is great, but it depends on the Erlang VM.
• I understand that Erlang is the reason why RabbitMQ is what it is. However, having to install and maintain yet another VM product has been annoying.
• The configuration for RabbitMQ borders on the esoteric. Once we got all of the moving parts working, it’s been a dream. However, it was an effort just to get it going.

We’ve been developing with RabbitMQ for about 18 months now. Our product launch is scheduled for April 1, 2017.

There were stability issues. We originally tried to mirror RabbitMQ servers behind a load balancer. (This is not completely recommended, by the way.)

That suffered from stability issues when network hiccups were a problem.

We ended up moving to a central LDAP authentication with completely disconnected servers, which has been stellar for stability.

We have had no scalability issues at all. We have RabbitMQ servers behind a load balancer, with Queue listeners attached to them.

I have estimated that we will be able to scale quite dramatically without any change to network topology.

RabbitMQ is an open-source project, so the level of tech support is relatively low. The documentation is adequate. There is a decent amount of activity on Stack Overflow and that has answered most of my questions.

I did actually use an open-source plugin and had a lot of communication with the developer. He was responsive and helped me significantly.

Our initial solution was a simple web API. We quickly realized that it would be difficult to maintain.

Scalability and reliability were my primary concerns. HTTP has no reliable delivery built-in, like AMQP does. Changing API versions would have been more difficult if we had stuck with HTTP.

The initial setup was fairly complex. Installation was not difficult, but configuration of the server itself took some work.

I ended up creating code that does the RabbitMQ setup based on a configuration file. This eased the setup dramatically. I also set up a central LDAP server for authentication, which helped. Otherwise, configuration of RabbitMQ was not very straightforward.

Being free and open-source, I have no advice here! Free is a good price!

I looked at other service bus/message queue solutions. In particular, I investigated:

• Azure’s Queue Storage: No real service bus ability without plugins
• AWS’s Simple Notification Service: Not much in the way of service bus capability. It did not allow private queues on the fly.
• A few other open-source message brokers

RabbitMQ seemed the most full-featured option for what we needed.

By all means, try to reduce the amount of up-front configuration of RabbitMQ as much as possible.

At this point, we can spin up a very generic VM with RabbitMQ on it and get it in use immediately. However, that was not the case at the beginning.

RabbitMQ is very flexible, which is good and bad. Once the flexibility is understood, it’s great. Before that, you may be in for a little bit of head-scratching.

• Parallel processing
• Takes minutes to process millions of records

This has improved our daily load process reducing the run time at least by three to four hours which made other departments within the organization to look for data from the Enterprise Data Warehouse.

It acts like a mainstream product not a novice any more. There are a lot of areas that can be improved. The bug fixes come as many patches like a start up instead of having scheduled release with proper improvements.

I've used it for five years.

It took a while to fully take advantage of this as we had to come up with lots proprietary solutions when linking to other products.

There is no issue with its stability.

There is no issue scaling it.

8/10 we had a technician come out on a new year in 2012 to fix some hardware failure.

We were one of pioneers in adopting this solution. So we got the best deal when compared to the competitors in several areas.

The initial move was a bulk transfer from the old system to new Greenplum based solutions. It was all done by Greenplum contractors. But to get it working with other products was challenging.

Greenplum employees developed and supported the initial move. Later they became remote consultants with support through phone and in-person as needed.

They gave a really good deal and we have been with them for five years even though the product got bought over by couple of different companies.

You need strong DBAs and architects to support the initial transfer.

Strong integration with Greenplum Servers.

Loading data to Greenplum server after batch processing.

6 months

Yes, issues with HA and issues in syncing with the Greenplum.

You cannot expect a split second response.

On a scale of 10 I would rate it as 7

On a scale of 10 I would rate it as 8

This has just been used for POC period not for a regular use.

Initial setup works absolutely well. We were using with only Greenplum.