VMware Tanzu Data Solutions Reviews

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.

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.

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.

We have two use cases for Tanzu; the first is for deep archiving where we're archiving a lot of data in petabytes and the second use case is for complex financial analytics for the regulators. We are customers of VMware Tanzu. 

Tanzu has cut our expenses because it doesn't use expensive hardware. We can store huge amounts of data in a single place and query that data quickly if regulators want to see older data. Carrying out large-scale analytics on a cheaper platform and getting it within 30 seconds is not easy. Tanzu helps us to achieve that. 

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.

We were using it as a high-volume text messaging solution. 

It's fully open source, has a high throughput, and the serviceability is good.

Postgres is a database. Like Oracle is a database, this is a database.

We replaced our Oracle paid database with the open-source Postgres database, and we migrated around 50 lakhs of consumer data there with different rows and tables. We deployed this in different production staging and testing. We created three deployments, and each deployment has three servers.

Earlier, we were using the Oracle paid database, which is a commercial product. Then we switched to open-source due to the fact that we have lots of new projects and we could not handle the licensing costs. So we migrated our data from the Oracle Database Server to the Postgres Server. It helped us to evaluate the cost. We saved lots of money in terms of licensing.

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.