IBM MQ Reviews

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.

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.

Reliability is the most valuable feature. MQ is used to support critical business applications.

The installation of product upgrades and patches is very difficult. It requires the use of the IBM Installation Manager (IM). The original IM data location used for installing the base must also be used for the installation of product upgrades and patches. In the Network Deployment edition, upgrades and patches need to be installed in the deployment manager and node agent profiles. I would improve this area by eliminating the need for the IBM Installation Manager.

We have not had stability issues.

We have not had scalability issues.

Technical support is excellent.

We had no previous solution.

Setup was complex. It requires a lot of components to be configured.

Use the new and lightweight version (Liberty) to lower licensing costs.

We didn’t look at other solutions.

Use the new and lightweight version (Liberty) to lower licensing costs. It is also easier to upgrade/maintain.

The pub/sub model is the one that we use heavily on IBM MQ. That's the most valuable for us. We are an enterprise team and we provide a lot of integration to the enterprise systems, so when the data changes on the enterprise systems, we publish a lot of these changes to all the subscribers, whether it's a customer change or the account changes.

It provides seamless integration with the enterprise and any enterprise data changes. Also, the reliability is important for us.

Using it as a service, as a platform on cloud, would be an improvement. I think it's always had room for improvement, so I would definitely put more on the cloud-based services than on what we currently use.

Also, ease of use isn't that great, as it's still considered enterprise class, whereas the more modern applications or platforms do offer modern interfaces and a way to integrate with those systems. Still, I feel its very legacy-natured.

I think the stability is great. That's one of the assets IBM MQ is known for.

So far, I think we haven't faced any scalability issues, but it is well architected in terms of its high availability and DR purposes.

I don't have any complaints about the technical support.

I think it was always an IBM MQ base which we used.

I was not involved in the initial setup.

I don't have information regarding which vendors were considered before we chose IBM MQ.

The features and the reliability of the product are important considerations when selecting a vendor.

Definitely it's a great product. But, I think we need better interfaces.

The benefit would be scale. Because of the way it works, you can really have many, many users who use the solution at the same time. Other benefits would be the ability to send messages between systems and do systems integration, without interrupting their run-time behavior.

It's ability to scale, it's ability to do guaranteed delivery and it's ability to do point-to-point of what we subscribe are the most valuable features. And finally, it's ability to handle messages in various formats and structures.

I would like the ability to connect with some of the more recent offerings, such as API Connect; being able to publish our MQ endpoints, the queues, the messaging infrastructure as IT assets. To control them, govern them and manage them and being able to publish non-functional requirements around it. For example, we support this size of the payload, we support this much throughput. Making it known and available to the rest of the organization, because this technology is so technical in nature, business management doesn't understand it. I would really like a business-friendlier or end-user friendly information layer, and some kind of simple ability to communicate what we have with the users.
I want an information layer that I can publish and tell the whole rest of the organization this is what you get.

Stability-wise, it has worked for us. It is an old technology and it has always worked well for us.

You can really have many, many users who use the solution at the same time.

We haven't had to use support much, because we have really good people. So, it has worked for us the way we wanted.

We did not have a previous solution. We always knew we needed something that worked asynchronously, something that did the messaging in the background. The reason we knew we needed MQ is, it's one of the integration backgrounds we supported and this was an obvious choice.

When selecting a vendor, the knowledge and the experience that the vendor has is most important. For example, IBM has had MQ for forever. So, that's definitely helpful. It's finding resources that know the product and technology and obviously the ability to support the platform. And, when necessary, be able to guide the customer through various usages and integrations with the rest of the IT infrastructure.

In the latest installation that we are talking about right now, I was not involved. But, for other installations in the past, I was involved in the set up and it was pretty straightforward. I'd consider MQ one of the simplest products to use.

We didn't look at many alternatives. We considered the Microsoft platform for a little bit, but we almost always knew we wanted to do this with MQ.

If they're thinking about a solution similar to this, I would say, look at your requirements and not just the business requirements. People often stop at that point. Look at your ability to support and run the platform, and the cost of running the platform, because, depending on your need, it could be very expensive to run a large messaging infrastructure. Also, think about what non-functional requirements you want to support now, but what you might have to support three, five, or ten years down the road. Think about it from the bigger picture perspective. And don't implement the solution for one small single requirement. People often make that mistake. They commit to a big licensing and support cost but what they're running is very small and there is not very much value added. That’s a problem there. So look at whether can you put a lot of solutions on it. Can you use it as a platform rather than a points solution is what I would look for.

Its integration capabilities and the security features are the most valuable features of this product.

We are using it to integrate systems. It's an asynchronous system and there are a lot of benefits of this method for us, so we are using IBM MQ.

If one of our servers or systems fail, MQ will store the messages for a long time, so we do not lose any information or messages. That's why we are using MQ.

• Security enhancements
• Active-active clustering: IBM MQ does not support active-active clustering, but we need that.

It is very stable.

It is very scalable, and very expensive.

We have used the technical support once or twice; it's good. We opened some tickets and received responses within a short time; so it was okay.

I did not previously use a different solution at my current firm but I have also used Microsoft Queues. However, there were a lot of issues with it in terms of the performance, stability and security. IBM MQ is better.

Initial setup was quite straightforward.

If you have money, then you can use IBM MQ. It is very expensive.

We are using almost every vendor such as Oracle, Microsoft, HPE, Solaris, etc. Our core systems are running on WebSphere, i.e., developed in Java code, so we are using most of the IBM tools. But, the most important issue when selecting a vendor is the support.

It allows us to do point-to-point integration in an easy manner. It allows different applications to talk to each other; applications that may speak different languages. You have mainframe technologies, Java-based apps, .NET, things of that nature, and MQ allows you the ability to share the data between those different types of systems.

The thing that I like about MQ most is its reliability. It's one of those types of products that just works. You don't have to tinker around with it too much. One of the biggest things that I really look for in a product is from a reliability perspective. Can I count on this to be up 24 hours a day, and do I have to keep hacking around with it? MQ is definitely something that is really reliable, so it's something that I really appreciate it.

I would just like a more user-friendly experience to do common administration tasks. I know that you can use MQ Explorer, but having something that's already built in would definitely be useful.

We haven't necessarily experienced any issues from a migration perspective. Typically, where we see the majority of our issues at is when we're doing upgrades to the Message Broker, or IBM Integration Bus is what it's called now. Those two products are typically married together. Most of our issues ... I wouldn't even call them issues. We see some issues when we migrate from different versions in regards to like, IIB. I think that's just because this is a more complex product. You have customized code in there. From an MQ perspective, everything's pretty straightforward.

I haven't had any stability issues. I think the biggest thing, when there are issues, is having an easy way to figure out what's going on. I think one of the things that I'm looking forward to, from a MQ perspective, is just having more of a user-friendly experience. MQ has traditionally been somewhat of a command-style solution, so anything that they could do to improve that would definitely be helpful.

We have not had any scalability issues.

We have teams that usually interact with IBM. My team doesn't necessarily do that that often but when we do, it's a fairly pleasant experience.

From an MQ perspective, it's something that we've been using for a long time. Unfortunately, when you're dealing with very large companies, it's difficult to transition away from stuff that you built a long time ago, so you have a lot of this stuff that's just hanging around, that's been built a long time ago, and you still have to maintain it. Once something goes into production, it's typically very difficult to get money to update that service five, ten years down the road.

Setup was pretty straightforward. MQ has been around for a long time. It's a reliable product. It doesn't change that much, so I think everybody, at least in my organization, is fairly comfortable with installing and implementing MQ.

MQ was, to me, pretty much the gold standard in regards to what it does. To me there's really no point to look at other vendors.

Have a common understanding of why you feel that you need MQ. MQ was something that we implemented years ago, so there may be new technologies out there that you may be able to utilize to make the project you're trying to do easier, and make your implementation a little easier.

Scalability and guaranteed delivery are the most valuable features. It's pretty straightforward to scale out. We use MQ to back our enterprise service bus. Guaranteed delivery is very important for most of the data that we send. Having a product that enables that is very valuable to us.

My organization has used MQ for a long time. It is a very scalable, common platform that we can use for sending messages. We use MQ in terms of messaging, MQTT, and MQ FTE for file transfers. It's versatile; it's very functional; and it provides us with a common messaging platform. It eases our integration.

With the introduction of MQ FTE, we've been moving away from other file transfer options, and standardizing the actual large file transfers with MQ FTE versus the previous product that we had. We've standardized on MQ FTE, in terms of shutting down basic transfers like FTP and other basic ways of transferring large files. Adding the MQ FTE functionality, on top of the MQ backbone, has been nice.

The product itself is not difficult to use. I guess you could always ask for a little bit better GUI admin console. All in all, it's not hard to use.

In a large organization like ours, sometimes we have a large MQ installation base; lots of connection points. If there was a more graphical representation, in terms of looking at the overall landscape of where we have MQ implemented, that you could drill in and out; that would be nice. A picture’s worth a thousand words, a lot of the time; if it was more graphical in terms of displaying the overall topology and layout of the MQ infrastructure we have; just from a high-level, admin-type view; just an easier way of looking at things.

It's very stable. It's been around forever. They have functions and features that are useful. Core-wise, it's a very stable product.

I'd probably recommend going with MQ. Don’t waste time with some of the other products out there. We constantly re-evaluate our portfolio and solutions; test things; and do comparative work. We've had other vendors come in, and we've run tests with them or even done limited deployments. Sometimes we buy a package and it comes with either Oracle's OSB, webMethods, or another integration platform, if you will, with their own version of their bus and messaging. Those mostly stay point-contained solutions, and that's for a reason. For the cost and everything you factor in, MQ is a pretty good product.

It's a great product. The only bad thing I could ever say about MQ is sometimes finding the right talent to administer it. It's a bit of a specialized skill set. Sometimes you can have challenges finding somebody that's really a competent admin. Other than that, it's a great product.

The most important criteria for me when selecting a vendor to work with depends on the product. The company's financial stability, their ability to scale to an organization of our size, is very important. Depending on the project, when you're reaching into new territory, sometimes it is looking at and evaluating who does have the best or most innovative approach to solving a problem.

We use MQTT, which is an open standard but works with MQ for the smaller messaging, for a lot of our messaging across the enterprise service bus that connects our digital or customer-facing activities back to our older, more legacy-based systems. It gives us a good interface.

We don't really have any barrier to success; we're pretty successful with it.