IBM MQ Reviews

We use IBM MQ as a reliable way of integrating different applications. Our transaction service operates using IBM MQ for organizing the asynchronous interaction between different applications and the core banking system. It is easy to organize parallel reading and writing, and you can easily link two IBM MQ servers using the remote queue feature. We also use IBM MQ in web services which are developed using IBM Integration Bus. MQ helps us scale web services and organize parallel execution.

IBM MQ helps us scale our applications and balance our applications' performance. MQ is quite reliable. In some cases, our application became simpler and more reliable simultaneously.

Reliable integration between MQ servers. IT helps us create flexible integration solutions.

MQ needs instruments for connection with new modern queues like Kafka or RabbitMQ.

For us, it's basically just our messaging bus. We pretty much use it just for events that are limited to various applications that we have in our company. That is pretty much the use case that we have with respect to the IBM MQ.

Also, the stability and reliability of the tool system is what makes it really easy to be able to work with.

Technically, it has made our lives a lot easier. Prior to having MQ, we were basically developing these custom in-house solutions, where we were running into a lot of issues. After bringing MQ on board, along with its integration and flexibility that it has provided us with, it has basically shortened the amount of work we had to do in order to get it set up and to get the communications happening in between.

Maybe it should have something with respect to being able to provide a graphical view of the data elements that we are processing. For example, how many messages are being processed by a certain queue or for how much time each message is staying in the queue, and so forth. If there's a way that IBM can provide this tool that can have this out-of-the-box dashboard feature, it would be helpful.

Right now, we are trying to build custom solutions so as to gather that information. We are using Dynatrace, which is one of our monitoring solutions. We try to use it to analyze how many messages this queue has processed today and then we are trying to calculate the data for how long did the message stay in the system before the application picked it up. If there is a tool that can actually provide an out-of-the-box solution of this kind, then it would be really efficient for us.

We have not experienced any stability issues. We have been running this for almost about five years now. I don't think, up to this day, we've had any server down issues primarily because of MQ, i.e., the product itself. It's very stable.

With respect to scalability, we're not such a big shop where we are continuously scaling up, but it's a pretty standard system for us. We did not really have to do a whole lot. It runs on very bare resources; it's pretty good.

We have had a few scenarios where we were trying to develop some custom security solutions that required MQ to be authenticated, when they are trying to push our consumer messages out. It was not really an issue but more of an enhancement that we were trying to do. That's when we tried to approach IBM and get their inputs on the best way to do this.

They certainly were very helpful. They provided us with the necessary guidance and showed us some technical documents that were available for our reference and basically, to get the project completed.

Actually, when I joined this company, they already had the solution.

First, assess your requirement. Basically, understand what you want to do and that's where it all starts. Doing the right analysis, finding the right solution; that's where success and failure happens.

• Ease of use
• Access to support resources
• Access to new release information in a timely manner
• Easy to digest

It is easy to use and seamless with our existing technology. It's a trusted name we know that we've used for years. It performs and it has very low downtime, if any.

With MQ, we always have trouble with the initial priming call failing. It would be nice if we didn't have the little wake-up service. Maybe if it self-monitored, had it's own health monitor, to fire those off upon startup, so we don't have to pay the price for it.

We are happy with the stability.

We have not had any scalability issues to my knowledge.

Our admins have used support in the past. As far as I know, they are satisfied with it. It's pretty solid and it's kind of the backbone of a lot of our stuff.

The initial install was a long time ago.

Stick with the out-of-the-box requirements, unless something tells you to go in another direction. And if so, definitely work with the vendor to make sure that they give you the adequate tools to do that, or help you scope that out.

When selecting a vendor, support is the most important criteria.

The integration it provides makes a lot of stuff easier. There are a lot of ways to integrate things but it works on a lot of different platforms and with a lot different technologies.

We've been able to get some disparate applications that weren't originally written to be integrated, but we've been able to make that happen.

I use the character-based interface for things but a lot of my peers like the GUI. Maybe there's a GUI available that I'm not aware of but that would be something that would facilitate it for some other people. Any kind of GUI; it could be on a phone or a browser or whatever. As far as I know, that is currently lacking, but maybe I just don't know. I primarily use the character-based interface for management when I work with it.

Because you can only put so much information on a text screen, sometimes you have to kind of shift views to look at things. That's something that, I imagine, if there was a GUI interface, you could do that a lot more easily. That would be an enhancement, I guess.

To some extent, it just runs in the background and you kind of forget about it. You don't really think about what else you could do with it. It’s just kind of running there.

It's rock solid.

I don't think we've tested the really high-end but it handles everything we can throw at it.

We have used technical support very occasionally. It's gone well when we've called, but we really haven't had too many opportunities.

Give it a try. It's not hard to do a proof of concept, get something going and build on that. You'll find that it's pretty easy to work with and it does a lot for you.

The only reason I haven’t given it a perfect rating is probably because I don't know everything it can do. I probably could take better advantage of it, but I might not be doing that right now.

The most important criteria for me when selecting a vendor to work with is reliability. I've got to trust that the product will do what they say, that they'll be able to support it, and that they'll be around in 5 or 10 years when I'm still using it. I kind of lump that into reliability. When I invest in something, I want it to be there and still working later on.

We are not using MQ to connect across cloud, mobile and devices as part of the internet of things. We don't do that on this project. The barrier to success is that nobody's interested. It's that blunt.

Our use cases for IBM MQ involve share markets.

In this organization, we are not using many of the features because we have a very small infrastructure. In my previous organizations, I used many of the components including AMS. However, here, we are just using it as a messaging solution and not any of the other components.

The MQ appliance has very good performance.

The user interface should be easier to use.

The user interface should be enhanced to include more monitoring features and other metrics. The metrics should include not only those from the IBM MQ point of view but also CPU and memory utilization. These kinds of features would be really helpful when we have a large infrastructure. Right now, this limits us from using the product.

In general, the user interface should be more catchy, to entice users.

IBM should promote the use of the MQ appliance because the speed and performance are superior when compared to traditional ways of using the product.

If IBM were to release as least some limited features for MQ as open-source, then it would be great because people will migrate to this solution instead of choosing open-source products like Apache Kafka or RabbitMQ.

I have been working with IBM MQ for almost 13 years across different organizations. I began working with version 5.3 and am currently using version 9.

The stability is absolutely perfect when it is running on AIX. However, I have experienced some issues with certain Linux distributions. With AIX, I have not had any problems with IBM MQ. With other flavors of Linux, there is some instability whereby the MQ configuration parameters are not giving the proper information. From this, I have concluded that the stability of MQ depends on the Linux distribution that it is running on.

The number of users in my current organization is six or seven. This is the number of applications that we have. This is not an extensive use of the product but we do plan to increase usage in the future.

In my previous organization, our use was more extensive. We had between 700 and 710 users.

This product scales and the number of users depends on the industry, as well as the financial strengths that the organization has.

The technical support from IBM is always reachable.

Internally, we provide technical support to our users. This is possible because our team is only six or seven users.

This initial setup is not complex at all. Deploying it was very easy.

Limited staff is required to maintain this solution because of its stability.

The licensing fees are paid quarterly and they are expensive. This is something that I have heard from all of the organizations that I have worked with.

I have evaluated Apache Kafka and RabbitMQ because of the open-source features and benefits. The open-source aspect is an advantage. I have found that not many users choose IBM MQ, even though it is stable, because of financial constraints.

If IBM were to release MQ or at least some limited version as open-source, it would become more popular. People would choose it instead of implementing other products, or other streaming solutions. This is what people are trying to do with DevOps.

IBM MQ is much more stable than these other products, although the rest of them work well with cloud providers such as AWS.

Overall, this is a good product. The only thing that I found complex was to build the user interface with the latest versions of IBM MQ. It was a little bit tricky to do.

I would rate this solution an eight out of ten.

• Secure
• Safe
• Very fast

It's a very good product. Very easy to work with.

I have been using IBM MQ for about nine years. We have many projects with it in many places in Kuwait.

There have been no issues with the stability of the solution.

I haven't had any issues with the scalability.

I only contacted technical support when I wanted to upgrade Windows Server. It's not that easy to move. I had Windows 2008, and I wanted to go to Windows 2012 or '16. You have to reinstall, or there was a solution somebody told me about and that made life easier.

The initial setup is straightforward. On the AS/400, setup takes about an hour.

Whatever the price is, it's worth it.

I would recommend it to other people. When somebody wants to do colocation with us, we force them to buy IBM MQ.

We use it to send a notification to our customers.

The clusterization which results in persistence is the most valuable feature. I only use a very small number of its features.

I have been using IBM MQ for about three years. For about one year I wrote adapters for IBM Broker and for two years or more I wrote services that used IBM MQ. This was a Java application by JMS.

The stability is okay.

Scalability is not an issue of IBM MQ. There is no replication of messages and that is very bad for systems. Only persistence can solve this issue.

IBM technical support is good.

The initial setup is difficult. Creating your own cluster is difficult and working with cluster repositories is difficult. Issue management with IBM MQ is difficult.

It's a very expensive product.

I like RabbitMQ more than IBM MQ.

If you have a lot of money then I would, of course, recommend IBM MQ.

All our applications run around MQ. We run a backend system working with a mainframe and we distribute records via MQ. We are using it daily.

From the time I joined this company I have been working with IBM MQ. Until now I haven't seen any severe issues related to it. Most of the time it's running. That is the advantage of IBM MQ.

It could be easier to use.

I have been working with IBM MQ for close to 14 years.

It is stable.

It can scale but sometimes, in terms of volume, it is not able to handle a huge volume. We also have limitations of queues related to IBM MQ. We often need to handle a very big volume, but currently we do have limitations. If those kinds of limitations could be relaxed, it would help us to work better.

I'm working on the development side. There is a setup team that is dedicated to working on implementations. I don't have enough hands-on in the configuration of MQ to comment on the setup.

If you're looking for stability I would recommend using IBM MQ. But people, these days, are starting to work with Kafka, which is an open system. I don't have enough knowledge about Kafka to comment on it. I just work with MQ.