VMware Tanzu Data Services Reviews

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. 

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.

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.

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.

• 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.

We use RabbitMQ for tasks that need to communicate in real-time. I have used it as a microservices message broker.

The most valuable feature is that it's really customizable.

When you have simple tasks, it is easy to use.

When you have complex tasks, RabbitMQ is hard to use.

There are several things that you have to do manually, so there should be better tools for that.

I began working with RabbitMQ several years ago.

I have had no issues with stability. It has been perfect.

Scalability is not a problem.

Because we are using the open-source version, we do not use technical support and have been solving problems on our own.

The complexity of the setup depends on the scope of the implementation. For a single node, the initial setup is very easy. On the other hand, for setting up RabbitMQ with a cluster, you really have to know what you're doing.

We are using the open-source version, which can be used free of cost.

My advice for anybody who is implementing this product is to learn the concept of message queuing and study the AMQP 0-9-1 protocol. If you study this then you won't have any problem learning the system and working with it.

In summary, this is a good product that I will continue to use, and I recommend it.

I would rate this solution a seven out of ten.

Of particular value to our environment and applications are the following Greenplum capabilities:

1. Scalable (Massive) Parallel Processing (MPP) – The ability to bring to bear large amounts of compute against large data sets with Greenplum and the EMC DCA has proven itself to be very effective.
2. Fast load of data into Greenplum – We experience performance of approximately 1TB per hour loading data to Greenplum without the use of specialized hardware.
3. MADlib (madlib.net) – There are a number of statistical and analytical functions available within MADlib upon which we rely. Among these are linear regression, logistic regression, apriori, k-means, principle component analysis, etc.
4. User Defined Functions in Python (UDFs in PL/Python) – Where MADlib does not provide a direct solution to an application problem, the ability to quickly prototype and deploy user defined functions with Python has been effective.

We would like to see Greenplum maintain a closer relationship with and parity to features implemented in PostgreSQL. The current version of Greenplum is based on a fork of PostgreSQL v8.2.15. This edition of PostgreSQL was EOL by the PostgreSQL project on Dec 2011. The current version of PostgreSQL is v9.5.

We began production use in November, 2011. Alongside Greenplum, we're also using EMC Data Computing Appliance v2.3.3 (8/10), of which we have two and a half racks in production, and one and a quarter racks in dev/tests.

We had no issues with the deployment.

The only issues with stability we’ve experience have been the sporadic fail over of primary to mirror segments. The environment continues to operate in this instance with the failure of queries that were in flight at the time of the fail-over.

We have had no issues with scalability whatsoever.

The service and support we’ve received from both Pivotal and EMC has been exemplary. The exceptions to this would be:

1. The EMC Request for Product Qualification (RPQ) process – EMC DCA support is contingent upon EMC approval of all third party software installed onto a DCA. There have been times that this approval has taken as long as 60 days to process.
2. Root Cause Analysis of Greenplum Database Incidents – When Greenplum Database incidents have occurred (e.g. primary database segments failing over to their backup), and Pivotal has been called for support, the response has been near immediate (30 minutes or less). Additionally, the incident resolution provided has been equally expedient. Where this has caused some disappointment is the response to our request for a root cause of the incident. These requests tend to queue up and we don’t seem to get answers beyond the typical vendor response of “that’s been fixed in the next release”.

The purchase of Greenplum was our first interaction with Pivotal. We have been a customer of EMC for a very long time.

My primary reason for reducing points on this rating is due to the fact that Greenplum is based on a fork of PostgreSQL v8.2.15 (EOL by the PostgreSQL project on Dec 2011). The current version of PostgreSQL is v9.5. There are a number of current PostgreSQL features of which we would like to take advantage (JSON support, materialized views, full text search, XML support, column-based permissions, row-based permissions, etc.).

It allows for asynchronous development and horizontal scalability.

The queuing system is the most valuable feature. It meets our requirements.

After creating a RabbitMQ service, they provide you with a sort of web management dashboard.

The dashboard allows you see things on your queues, purge/delete queues, etc. The dashboard is pseudo-real time, refreshing every N secs/mins, specified with a drop down.

I’d like this dashboard to use web sockets, so it would actually be in real time. It would slightly increase debugging, etc.

We have not had stability issues.

We have not had scalability issues.

We never used technical support.

We did not have a previous solution.

The setup was straightforward. We are implementing using Node.js and the module we are using was easy to use.

I am not the one in charge of licenses and pricing, so I do not know anything about this.

We didn’t have any alternatives. Our company has a contract with PCF, so it was our only option.

For Node.js development, use amqplib. It’s a really good library for RabbitMQ.