Amazon Simple Queue Service (SQS) vs. TIBCO Rendezvous

While we use AmazonSimple Queue Service (SQS) in our serverless applications, it would be a great option to handle queue management for any internet-connect application. It provides the most benefit in situations where your application or service must maintain mission-critical queue of messages or jobs. If you're already using other AWS services you will find the greatest benefit.

Incentivized

I would recommend TIBCO Rendezvous to a colleague for several reasons. One of most important could be to use it on different operating systems (i.e. Windows, Linux) and be able to create real-time communications. Another reason could be the easy message addressing: only those who subscribe to specific subject receive the messages.

Incentivized

• SQS is reliable and fully managed. Our engineers do not have to worry about running RabbitMQ.
• SQS is very inexpensive.
• SQS allows data to be encrypted in transit, which may be required for compliance in some products.
• FIFO queues provide exactly-once processing.

Incentivized

• Faster broadcast data.
• Exchange data across multiple networks.
• It works without a central server.
• Messages filtered based on specific subject.

Incentivized

• More frequest polling will be expensive
• No detailed monitoring of queues, just current data and regular monitoring is present
• No way to fetch messages back from the queue

• RV doesn't support centralized administration to manage the delivery of synchronous messages in run time without changing its configuration which was done in code base

Incentivized

Not likely to renew or buy the license as they are using the TIBCO EMS as the primary mode of communication.

Incentivized

Attending an official TIBCO classroom training, where you can have an active participation with an expert teacher, you can find the answers to all yours needs. In any case, if you are not satisfied on your requests, the teacher takes the time to find the best solution.

I had the opportunity to attend one and I could learn all features I needed for my business: now I can say TIBCO Rendezvous is very usable.

Incentivized

Online blogging and documentation for SQS is great. There are many examples of implementing it and if you look hard enough, more than likely there are examples that meet the exact case with which you are working

Incentivized

I never needed support for TIBCO Rendezvous. I always used it without any issue and until now I don't remember some situations where it interrupted its 24/7 uptime.

Incentivized

To be blunt: Amazon SQS was the simplest to implement given our requirements. Other services in this space work just as well, and SQS does not have any benefits outside of being the easiest to implement when using an otherwise fully AWS stack. AWS itself even has other solutions that would work just as well, however, SQS had the most reasonable pricing model for our given situation. That will certainly not always be the case, but in several of the instances where we are using it, it just made the most sense.

Incentivized

TIBCO EMS provides centralized server administration to manger the delivery of services in run time

Incentivized

• Under the AWS Echo system, it provides great operating power to the application.
• The cost is much less for messages, and it also supports a multi-user option.
• Not for us, but for a larger organization, low throughput might become an issue for a standard queue type.

Incentivized

• Positive - RV supports faster delivery of messages to multiple subscribers (asynchronous communications)
• Negative - RV doesn't support centralized administration and guarantee delivery is more accurate like EMS Persistent delivery mode

Incentivized