IBM MQ Reviews

Stability and reliability are the most valuable features. It's very reliable and very stable. You can do a fast recovery in case of any failure. It's a very consistent and stable system.

The whole integration channel between PowerVM and third-party applications goes through MQ. This is why MQ plays the role of middleware, of integration, and it helps us to quickly integrate all applications around PowerVM.

One possible area with room for improvement is some integration with the alert system to alert us in case of any failure of any message to be transmitted from one source to another; maybe that could help. It doesn't do that right now.

We will see how MQ will help us when we go to cloud, one day.

It’s very stable.

We have never faced any problem with upgrading or scalability between MQ series and the IBM the PowerVM. It's good.

Once you install MQ, you don't need a lot of support. Of course, we have support with an IBM partner in our country, but up until now, we have never faced a major issue that could impact our business.

Implementation was very straightforward.

Our environment is 60% IBM. We did not shop to search for another solution.

In general, though, the most important criteria for me when selecting a vendor to work with are support, response time, credibility, to be near to us, and that they are not working from the cloud.

In a financial institution, for very critical applications, when you invest, you have to invest one time. You don't have time to redo the work over and over. When you build your setup, your infrastructure, to do your service and your financial service for mission-critical applications, you have to choose the best-of-breed application that supports you. This is why we choose IBM without any hesitation.

We have never faced any problem. It works fine.

We are a bank, and regulations restrict us from using the cloud, at this point. We're using MQ only on our data center.

Obviously, the biggest thing is that we’ll never lose a message. We use it for a lot of real-time information between our systems for integration, where we cannot lose data during that point in time, because then we lose track of inventory, our manufacturing systems, sales orders and things like that.

It's reliable. It's a solid foundation. It’s always up and running. MQ doesn't crash on us. It gives us the stability of the platform to be able to do all of the integration between our applications.

The user interface might be an area with room for improvement, but we use MQ Explorer and that helps solve a lot of our problems there.

On my test systems, I have over 150 queues; maybe a better way to manage those and to see them visually instead of just one long list.

We started using MQ back in 1996.

It’s up 24/7.

We haven't had any scalability issues. We keep adding more applications to it all the time.

We use technical support only when there are problems, which is very rare. It's always been good when I've had to call them; responsive, efficient.

I was partially involved in the decision process to invest in MQ. We were not previously using something else. We were actually early adopters, really and truly. We started using MQ back in 1996. We've been using it ever since then.

Initial setup was straightforward.

At that time, there were no other vendors on our shortlist.

The most important criteria for you when selecting a vendor to work with is obviously that it is a stable company; a vendor that will be around for a while. Those kinds of things.

Take a look at it. It's well worth the effort to play with it and to understand it.

The multiple queuing features, so that everything that we use for talking to our reservation system, the main system we use it for; whatever systems that are sitting on Linux or other environments such as AIX, and then talking to iSeries, which is our “mother ship”, the reservation system. The most valuable features are being able to handle those multiple queues and being able to scale properly.

Before we used MQ, basically it was more of a batch job, sending and receiving messages; kind of like an upload, download type of thing. Now, it's real time, where we can effectively handle millions of transactions an hour, once we implemented MQ.

My only thing for improvement would be the way that we've got it configured. I don't know if it's capabilities and using those capabilities. I feel that we installed it a little bit, say, out of the box. There's a different way we could set up some queue management, that we could do better. It's partly us, but probably using some outside resources to look at our transaction volume and flow. We set it up probably eight years ago and we haven't really changed it since. Our business has changed.

I would just like it to be more resilient. In that area, if there is something that happens, it would alert us better or reset itself automatically, which is the greatest thing, where it tells you, "Hey, there's a problem, but by the way, I've already taken care of it. Just so you know. " That's where I see we've had to do more application monitoring around that to do the actual queue management; understanding that something is wrong. It could help us do that. I lose sleep at night, because of, if we have issues.

It is extremely stable.

Scalability is fantastic, basically because of the Power Systems. It scales along with whatever environment it's sitting on.

We've had problem tickets and things that we've called in to analyze issues. The good part is that it never really was an MQ issue. It was some other issue that came out, but we would get them involved and they would be able to diagnose. It helped us a lot.

Their response was quick; very quick response and very detailed response. Basically, they usually do captures, send in the data and do the analysis. Usually, within 24 hours, we got the information back we needed.

They were really just doing batch file uploads, downloads; probably a couple different things versus MQ. It was a big implementation from IBM. They partnered with us, also to help us. We also started slow and then used it in other areas as well.

I highly recommend it, but I also highly recommend getting services with the actual product to make sure it's implemented correctly.

The most important criteria for me when selecting a vendor to work with is truly being a partner; taking a little bit of the ownership; not just reading from the book of suggestions – because we can read that same book – but really understanding all of our environments, how we do business, make recommendations and implement them. That is important: not just making recommendations; doing it.

It's fairly easy to set up and configure. It's very effective as far as what we need to do with the type of processing that we're trying to get done, message-based processing. It is easily replicate-able. We have tons of servers that actually handle different queues; it's very helpful with that.

In conjunction with some other products we use, such as IIB, it does a lot of the transformation. It cuts out a lot of programming that has to be done for transforming data from our carrier customers into the format that we need it to be. That's really one of the big benefits.

There is room for improvement with the price. It's actually not really one of the high-priced items, but everything's relative.

I'm not really sure that there's a lot that we could really think of that we would need above and beyond where we are today, and the way we use it.

What would be nice is some kind of a built-in monitor. That would be something that'd be really helpful; some kind of a performance-type monitor. I know there is one, but it should be built-in. It should be automatic.

Or, a particular queue manager; that would be really helpful, I think.

It's extremely stable. We very seldom have any issue with it. We have it clustered between z/OS and zLinux. We've never had any serious problem with it.

It is easily scalable; very scalable. We can scale both internally in a virtual machine – the size of a queue or a number of queues – and it's also across multiple virtual machines. We use it both ways to scale up.

On z/OS, queue managers are very easy for us to generate and build new ones if we need to or multiple queues on the same queue managers; it’s a very effective tool.

We have occasionally used technical support for MQ, if we really run into an issue. That has worked out pretty well. As a matter of fact, most of the time, for any kind of an issue, we've usually had it resolved within a day. That's the way we want it.

The decision to invest in MQ was made prior to my starting at the company I'm at. I can't take claim for that. I was at another site, and we weren't using MQ at that other site.

I'm a director and me and my team were involved in the initial set up of MQ. It was very straight forward. We had people that were familiar with it. Some of the people that I worked with, or that worked for me, really had a good background, so it went very quickly, and it was very straight forward.

One of the things that we've been asked about is using open-source message queuing alternatives. One of the things we've always fallen back on is that we like the IBM support; we like the release. We don't want to have to worry as much about the levels of software; IBM already takes care of that. It integrates with the other products that we're using. All of those things kind of play together, especially in our case; we're a very big WebSphere Application Server, and as I’ve mentioned, a very big IIB server as well. It's really important that they all work and play together.

I’ve had really very little trouble with it. It's very effective. I don't think on either side, z/OS or zLinux, we've really had any trouble with it to speak of. Sometimes when we do some of the clustering things, we've run into questions or we run into things.

In general, it's been very, very solid.

The most important criteria for me when selecting a vendor to work with is that they're established; that we're not going to be concerned with, "They're here today, and gone tomorrow."

Probably one of the bigger criteria, nowadays, is the ability to support the software. We know we're going to run into trouble. We know we're going to have problems. We know we're going to have questions. We want to make sure that we have a vendor that can support us at that point.

Our primary use case for IBM MQ is as an enterprise messaging between applications. So when applications need to transmit data from one to another, they use a messaging broker, the IBM MQ, RabbitMQ and ActiveMQ.

We have found the MQ messaging topologies valuable mainly the published, subscribe and direct messaging. A feature that no other market could offer at the time was data-addressed encryption.

The clustering model can be improved to allow consumers to consume from all brokers simultaneously. Currently, the issue is that they're using a very old clustering model where several of the individual brokers in the same cluster still behave as individuals rather than behaving like a cluster. They call it a cluster, but it's just a group of brokers not working as a cluster. It doesn't properly share the resources between all of the member clusters. Compared to other solutions like Apache Kafka, or RabbitMQ, this is a huge drawback.

We have been using the solution for approximately nine years, deploying it on public, private cloud and on-premises.

The solution is stable.

The solution is not easily scalable. 

Technical support is tough to connect with because the training and documentation from IBM are awful and the technical support from IBM is also poor. So it's easier to solve your issue using Google rather than calling support at IBM.

The initial setup was a bit complex. The installation itself can take anywhere from half an hour to four hours, and the configuration could also take a couple of hours, depending on the complexity of the design.

The solution is expensive.

I rate the solution an eight out of ten. The solution is good, but the clustering model can be improved. My advice to others considering the solution is to check other products on the market and ensure their product of choice complies with everything they need. They should go for IBM MQ but ensure they carefully read the terms and conditions and view the price beforehand. Alternatively, if they want to go with a more lightweight solution that is just as reliable, they should review RabbitMQ.

Primarily, I use IBM MQ for microservices, modeling, and communications.

IBM MQ's flexibility has sped up our active communication. 

I've been using IBM MQ for five and a half years.

IBM MQ's stability is good.

IBM MQ can scale, but there are some challenges with it.

IBM MQ's pricing is higher than its competitors'.

I would rate IBM MQ seven out of ten.

IBM WebSphere MQ is deployed on a Windows machine, as well as almost all of our infrastructure. Windows services read and write to the MQ server - this is the way that we interact with it. All the messages that we put on the queue are also stored in an SQL Databases. A Windows service reads that message from the SQL Database storage and puts it on a queue on a certain channel; these Windows services are running indefinitely, on a loop so any message is read instantly. 

The solution is very easy to work with.

The solution is very stable, it also offers transaction management and support.

The solution offers very good integration with other services. It's one of the great advantages of the service.

We have had it for a long time now - version 7.1, which is not the latest. 

The admin interface of MQ Explorer that is used to interact with the server seems a little bit dated. It makes it somehow difficult to interact with it. It needs a major update to make it more modern and easy to navigate, maybe a web version.

The solution isn't free. There are other solutions, like RabbitMQ, which are open source and absolutely free to use. This open source solution we use it for non-critical processes.

IBM offers a special version that you need to get if you want to transfer files, especially large files. Maybe it should be included in any version.

We've been using the solution for a very long time. It's been at least a decade - about ten years.

The stability of the solution is good. We've never run into any issues.

IBM MQ offers clustering. We don't have this yet, as it hasn't been implemented, however, I know that you can install it in a cluster of servers. 

My understanding is RabbitMQ is also easier to scale. I'm unsure as to how well IBM can scale in comparison.

I've never contacted technical support in the past. I can't speak to their level or service due to the fact that I've never directly dealt with them.

We're also using RabbitMQ. While IBM is more stable, RabbitMQ is easier to work with. 

We've been trying to change our architecture, and RabbitMQ is more appropriate for us as it's easier to put together with microservices.

While I was part of the process for implementing RabbitMQ, which was very simple and straightforward, in the case of IBM, I didn't install it myself. Unfortunately, I cannot explain how easy or difficult it was as I was not part of the experience. My understanding is it's not too difficult.

In terms of maintenance, we have two people from the support team handling that aspect. They can restart the server or look into the queues. They aren't working in shifts, however, if there are issues, one of them is normally available to troubleshooting.

In comparison, for RabbitMQ, we had only one developer that installed it and created the publishers, workers etc. I believe the support will be the same as for IBM. In both cases, there aren't too many people needed for maintenance.

I'd recommend the solution. It's a very stable solution and very resilient. 

If there is not essential data that needs to be transported between services, then I would go for a RabbitMQ, because it's easier in style, and it's free to use. On top of that, you can have it to wrap around everything in a straightforward way.

That said, I'd rate the solution nine out of ten. We've used it for a number of years and it's always worked very well for us.

Our primary use case is for messaging monitoring. 

The reliability of the queuing is the most valuable feature. 

I can't say pricing is good. It is a popular and reliable solution. IBM can be integrated with other products which is why it gets sold. People also like Oracle. They can be integrated with multiple systems. That is a selling point for these solutions. 

We have been using IBM MQ for fifteen years. 

It is stable.

We never have had a problem with the scalability. We had a problem but the company who was helping us figured out that it wasn't because of IBM MQ, it was another problem. Scalability has been good.

We have a little more than 100 users. 

The product is stable and reliable. We don't generally have support issues. If the product isn't good, people will say that it's not a good product but the support is good. If it's a good product, you won't need much support. 

The initial setup for the messaging part is straightforward. For other features, it's of medium complexity.

I would rate it an eight out of ten. Not a ten because of the pricing.