"Stability has been good for us. It is quite high."
"Push notifications are the most valuable. I have mostly used push notifications for my system. Amazon SNS supports all devices for push notification services. It supports iOS, Android, and Windows notifications. It provides reliable push notification services. We have queues, and we can track which notifications have failed or had some issues. We can then figure out the issue. We can also debug the issue because of which our push notification didn't reach the end users."
"The mobile push notifications are the most valuable. Previously, we used to use Firebase Cloud Messaging (FCM) for this functionality. It is a Google service for sending push notifications. Android did not have a good service for sending push notifications, but now, Amazon SNS integrates with FCM. Under the road, it is actually using FCM, but we can see all the metrics on our AW service itself, which makes it a lot easier instead of using a third-party service for this particular functionality."
"It also has a backup queue concept and topics, features that I have not seen anywhere else. I like these features very much."
"I haven't seen any severe issues related to it. Most of the time it's running. That is the advantage of IBM MQ."
"RabbitMQ and Kafka require more steps for setup than IBM MQ. Installation of the IBM product is very simple."
"The clusterization which results in persistence is the most valuable feature."
"What is quite useful is the asynchronous function which means we don't lose everything in the bank. Although we use a lot of things synchronously, asynch is the best thing so that no banking information is ever lost, even when the network goes down and comes up."
"Whenever payments are happening, such as incoming payments to the bank, we need to notify the customer. With MQ we can actually do that asynchronously. We don't want to notify the customer for each and every payment but, rather, more like once a day. That kind of thing can be enabled with the help of MQ."
"The methodology and the way in which the platform has been produced as a standard is most valuable. There are so many different versions of it now, but the actual basic functionality and the simplicity of it have made it far easier to be implemented in so many different instances. When I worked with the OS/2 or PS/2 machine environment, the messaging mechanisms were based upon IBM MQ. It is so versatile, which is the main reason that I'm a fan of it."
"I have found the solution to be very robust. It has a strong reputation, easy to use, simple to configure in our enterprise software, and supports all the protocols that we use."
"I recently worked with Firebase, and it provides an option to create a marketing campaign with a title and a specific image to inform our audience about something. We just design the campaign and then use the push notifications. It would be good if Amazon also adds a similar feature."
"A major issue with AWS as a whole is that it has a lot of services that do the same thing, and people get confused about which one to use in which scenario. Previously, we used to use SNS for connecting microservices. SNS has around six types of subscribers. We can subscribe to Lambda, HTTP, HTTPS, SMS, email, and push notifications. We used to use HTTP endpoints and Lambda for connecting to microservice systems. Now we have something called EventBridge, which actually does that for you. For connecting to services, we should just use EventBridge rather than SQS, SNS. I hear a lot of complaints from people wherein they do not understand when to use EventBridge and when to use SQS, SNS. They can remove these features so that it doesn't confuse users about when to use SQS, SNS, or EventBridge."
"In terms of improvement, I would like to have better customer support for SNS. We can then manage it very easily."
"Everything in the solution could be simplified a little. We have trouble with the configuration and cost which is mostly an internal issue, but nevertheless, the errors do come up when there are configuration changes across a specific version. We have slightly different versions, which may have slightly different configurations which cause issues."
"They could integrate monitoring into the solution, a bit more than they do now. Currently, they have opened the REST API so you can get statistic and accounting information and details from MQ and build your own monitoring, if you want. IBM can improve the solution in this direction."
"There are things within the actual product itself that can be improved, such as limitations on message length, size, etc. There is no standardized message length outside of IBM. Each of the implementations of the MQ series or support of that functionality varies between various suppliers, and because of that, it is very difficult to move from one to the other. We have IBM MQ, but we couldn't use it because the platform that was speaking to MQ didn't support the message length that was standard within IBM MQ. So, we had to use a different product to do exactly the same thing. So, perhaps, there could be more flexibility in the standards around the message queue. If we had been able to increase the message queue size within the IBM MQ implementation, we wouldn't have had to go over to another competing product because the system that was using MQ messaging required the ability to hold messages that were far larger than the IBM MQ standard. So, there could be a bit more flexibility in the structuring. It has as such nothing to do with the IBM implementation of MQ. It is just that the standard that is being put out onto the market doesn't actually stipulate those types of things."
"The initial setup is difficult. Creating your own cluster is difficult. Working with cluster repositories is difficult. Issue management with IBM MQ is difficult."
"The main issue we are having with the solution is due to the connection dropouts which have been going on for a long time now."
"There are many complications with IBM MQ servers."
"I wanted to upgrade Windows Server. It's not that easy to move."
"They have provided a Liberty Profile in the Web Console for administration, and that could be further enhanced. It is not fit for use by an enterprise. They have to get rid of their WebSphere process and develop a front-end on Node.js or the like."
Earn 20 points
Amazon SNS is ranked 3rd in Message Oriented Middleware (MOM) with 3 reviews while IBM MQ is ranked 1st in Message Oriented Middleware (MOM) with 45 reviews. Amazon SNS is rated 9.4, while IBM MQ is rated 8.0. The top reviewer of Amazon SNS writes "Automatically scalable, very stable, and full of solid and useful features". On the other hand, the top reviewer of IBM MQ writes "We don't lose messages in transit and we can store messages and forward them when required". Amazon SNS is most compared with Amazon EventBridge, PubSub+ Event Broker and TIBCO Enterprise Message Service, whereas IBM MQ is most compared with Apache Kafka, VMware RabbitMQ, ActiveMQ, PubSub+ Event Broker and Aurea CX Messenger. See our Amazon SNS vs. IBM MQ report.
See our list of best Message Oriented Middleware (MOM) vendors.
We monitor all Message Oriented Middleware (MOM) reviews to prevent fraudulent reviews and keep review quality high. We do not post reviews by company employees or direct competitors. We validate each review for authenticity via cross-reference with LinkedIn, and personal follow-up with the reviewer when necessary.
