IBM MQ Reviews

We use it for application-to-application integration.

Reliable messaging and throughput are the most valuable.

We are looking at the latest version, and we hope that resilience, high availability, and monitoring will be improved. 

It can have some more improvements in the heterogeneous messaging feature. The current solution is on-premises, so good integration with public cloud messaging solutions would be useful.

I have been using IBM MQ for 20 years.

Its stability is great.

Its scalability is okay. The inside scalability is great. We are hoping that the outside scalability is improved in the latest version.

Most of the users are just using the applications, and they are using IBM MQ without realizing it. In terms of the number of people really dealing with IBM MQ on a global scale, there are probably around 30 users. They are actually working with the product. There are thousands of developers who are using applications with IBM MQ.

I am an architect, and I talk with the architects of IBM. The engineers talk with technical support when needed.

The basic setup is simple. The deployment is fully automated.

We received the software from the vendor, but we deployed it on our own. We also do the maintenance ourselves. 

There is real money involved here. As compared to RabbitMQ, IBM MQ is on the higher side in terms of cost.

I would recommend this solution for similar companies. I am very fond of IBM MQ because of the reliability and throughput part, at least on a single server. On the consumer and application side, RabbitMQ seems a bit easier to consume. It is a bit ahead in terms of the scale-out feature.

I would rate IBM MQ an eight out of ten.

We work with an organization who has only one product and that works with IBM MQ. Combined with IBM MQ, this product is our primary data store.

There are many things that I like about IBM MQ, such as, its performance and reliability. 

I'm not sure that current version has event-driven mechanism requests that people go for. I would like the latest version to come with both type of event-driven mechanisms: an email server and a POP server. If that is not there, then that would be a great addition.

I have been with a company for the last three years who has been using IBM. I was with another organization before that who used it for four or five years.

For the last three years, I haven't faced any stability issues. I would rate the stability as a nine (out of 10).

Support is managed by the vendor management team. This is being taken care by some of the managers.

I was not involved in the pricing structure.

There are quite a lot of competitors of IBM MQ who have high capabilities.

I would rate the product as a seven (out of 10).

It can do messaging throughout multiple platforms. That's the major benefit for MQ. At the same time, we use it quite extensively to do messages between the iSeries and the mainframe.

The amount of transactions: You don't have to send a file down. You just send the messages; whatever the transaction is. It's going to be much more effective and more trackable.

It's pretty good right now the way it is.

I don't know whether it is available with the new features, but in the older versions, I remember, to test a queue, you actually had to call an API to send messages back and forth. If that would be a one-command scenario like on the iSeries, instead of me calling the API, sending a message and receiving it, I would like to have something like that. I don't know if MQ’s new features support something like this.

Stability’s pretty good. I haven't had any issues. Although, in clustering, you have to know exactly what you're doing. Otherwise, your cluster will be out of whack a little bit. Otherwise, it's stable. It's very stable.

You can scale it anywhere.

I have not really used technical support in the last year.

When I did, I've had experiences with channels not starting up, either due to connectivity issues which turned out to be either network-related. The messages are really clearly defined and errors are logged, so we referenced that and based on that, we took action.

When we do contact technical support, they're excellent; 5/5.

Because I had worked with it before, initial setup wasn't that bad. If I look at myself at the beginning, when we wanted to set it up, I actually went and took a course before setting it up. Especially on the iSeries side and all the communications, you have to get familiar with all the terms and terminology that are being used on the application. Once you know that, then setting it up is not a big deal.

It's very easy to set up, it's very stable and it's trackable. MQ is a really good tool to be able to send messages back and forth between multiple platforms. If they're looking for a solution for sending files across, they can actually use MQ to send the messages across.

I haven’t given it a perfect rating because there's always room for improvement.

The most important criteria for me when selecting a vendor to work with is being strong and supporting it, and being there for a number of years, so I don't have to worry about an unsupported product.

We use it mainly on iSeries and mainframe, so I’m not really involved in using MQ to connect across cloud, mobile, and devices as part of the intranet of things.

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. 

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. As a result, rather than following the recommendations and the standard that was within the IBM MQ implementation, some suppliers say that we need the ability to have longer message lengths than they've implemented, but that's the way it is. Other than that, I'm very pleased with it as it is. It is good at doing what it does. I love the actual implementation, and I've used it a lot.

I've been using IBM MQ since it came along. We've got a lot of different platforms. We have IBM MQ. We have had BizTalk, IMMQ, WebSphere, and WebLogic platforms, but we're moving very much into the cloud.

The support that we have goes through third-party vendors. In the past, their support has been very good, but I can't say anything about it today. About 15 years ago, in the companies I was working with as a consultant, we had very good support. We were working very closely with IBM, and IBM implemented the PS/2 and OS/2 operating system together with Microsoft. The implementation there in terms of the connectivity was an implementation of the IBM MQ series in the OS/2 operating system, PS/2 environment. The support we received for that work back in the late '80s was fantastic.

The initial setup is usually left to other people to do. I've never actually done the installation and setup of it myself. It has been other people with a bit more deep technical knowledge who have done the implementation and actual installations. It was a very long time ago when I received the first set of CDs where we were going to be doing the installation of it, but I don't have that deep technical knowledge of the implementation as such.

I think it's pretty reasonable, but I'm not so too sure of the current pricing strategy from IBM. We use many bundled services, and most often, we go through a service provided by some other third-party implementation. So, I can't really give an honest opinion about that.

I would rate IBM MQ an eight out of 10.

We are mainly using it for communication, for connecting to multiple systems. Applications are putting their messages on MQ and, from MQ, we are reading them using IBM Integration Bus. We then process them and send back the response.

The MQ protocol is widely used across multiple applications and it's so simple for connectivity. 

Other valuable features include the 

• messaging format
• message persistence
• security features, including several connection channels and name-based and user-based authentication.

I had some issues earlier, two, three years back. I don't exactly remember them now.

I have been working with IBM MQ for eight years. We are currently trying to implement IBM MQ on OpenShift and cp4i. We have MQ on-premises and we are trying to migrate it to OpenShift, a container platform.

Stability-wise, it's very good. People have been using it for 15 to 20 years. MQ and IIB are the most stable products from IBM.

We can scale up and down anytime. There are no issues there. We have 20 to 30 internal applications connecting to middleware and all of them are connecting using the MQ protocol.

We haven't had major issues, but whenever we have had an issue we have written to IBM and they have gotten back to us on a timely basis.

The setup is straightforward. There is not much to create, it's a one-time setup, including configuring the high-availability. That is the main thing. The parameters create the queues. It takes about 10 to 15 seconds for each queue.

In addition, we had IIB, the IBM Integration Bus deployment, including message flows and DB scripts, etc. So the deployment was not only MQ. In deploying IIB flows, we had some queue creation, server connections, and channel creation. Overall, it was about 80 percent IIB deployment and 20 percent MQ deployment.

We had two people involved: one guy from the support team and one guy from admin. For maintenance, in the sense of the application support, we have four team members but we are handling multiple applications, not only MQ.

We deployed it ourselves.

Although I'm not involved with costs in our company, IBM products, in general, have high licensing costs and support costs are too high. A lot of people have started using open-source, like Kubernetes and microservices. There is also Apache ActiveMQ. There are many other products out there.

I would tell people to use this, except that the pricing and support costs are too high.

I would rate MQ at eight out of 10. 

The integration between applications is the most valuable feature. We can use it with multiple applications.

It provides faster interaction between the applications. It makes it easier to integrate the applications.

So we're on MQ version 8, and I was at a recent event for MQ 9 and it looks like they've already added some of the features I was looking. For example, a better monitoring system, and a GUI to display messages, which I think they've already done.

MQ is very stable. It's a very simple application to set up, and once it is set you don't have to really configure or monitor it so much.

Since it is very lightweight, the only thing you have to really scale is hardware. So, migrating is very simple as well. It supports HA, so we have it set up with just an active/passive type set up. And we don't have to scale it as much. So far, its been working out great.

We haven't had to use support yet.

Our first time using a message queue system was MQ, so we went with the IBM MQ product.

Being with a state agency, we actually go through what's called a hub that has a relationship with IBM. We can't directly purchase from IBM, so we have to go send bids. But, since we have quite a few IBM applications, we always you know target IBM since we already have the support that we need and our relationship with our sales person is really great. So, we always choose IBM.

I was involved in the initial setup. It was fairly straightforward. Once you start creating the queue managers, there's some configuration involved, which our developers take care of. I just take care of the basic installation of the product, which is very simple.

I don't know the names of any alternative vendors.

MQ is awesome.

It's certainly a product that you can rely on. It delivers the stability and security within our applications that we desire as an organization.

The time to deployment is quick and easy. Again, it is stable, auditable, and uses automation to deploy products and keep the systems up and running while the business is still functioning.

I think the cloud is our next solution. Because we’re in the healthcare industry, I want to make sure the security is really strong and capable of keeping our members' data secure.

It's very scalable. It's very easy to build out with high availability, and you're also able to scale both vertically and horizontally very easily.

I was not involved in the initial setup.

We used all the big players and we chose IBM just because of the fact that we've used them before with other solutions. We know their capabilities. Their delivery solution team has helped guide our solutions across the board and has delivered high availability, high quality to our members.

We also used Oracle, and we also used the Tomcats and JBoss product lines.
The most important criteria when selecting a vendor is reliability; knowing that they're going to be there to support you when you need them; the ability to bring solutions to an issue in a quick manner that allows you to keep your business going.

Every application could always use improvements, but it's a very stable application and delivery solution tool that we are able to implement quickly and add applications to it quickly; keep us going in an ever-changing environment.

Guaranteed delivery of the messages and then the ability to scale the messages the way we need it according to our application, performance, and scalability.

It helps us to make sure that every time you do a swipe on your credit card, the credit card transaction is guaranteed to transact.

Some of the new features that their competitors are coming out with. Things like AMQ are coming out with - transformation of messages with the security aspect of it and even scalability with AMQ, it's scaled at the microservices level and MQ is not quite there yet.

We're currently evaluating AMQ to see if from a cost perspective it makes sense or not to switch from IBM MQ. We still have IBM MQ.

Very stable. Within the last year or so we hardly had any issues with the MQ or the queue itself going down.

Scalability good, we can scale by the application needs and also scale by the need of the application but also the need of the infrastructure. At our peak, we're able to scale and make sure the transaction goes through.

Service is good. We've been able to meet all our SLAs in the agreement that we signed with them.

We have an enterprise level agreement with IBM. If there's any issue with MQ, we have a direct line to them.

AMQ is one of them, Kafka is the other, and of course IBM MQ has always been on the list.

We chose IBM a long time ago from all the criteria I mentioned and then at the time other players were not evolving yet. IBM MQ has been an enterprise solution for many companies and the stability's there. It made a lot of sense for us to use IBM MQ back then.

Partnership with the vendor and stability of the product are most important when selecting a vendor. I mentioned AMQ earlier, and there's no guarantee that AMQ will be around next year.

Stability is key to the product and the performance of it, you can get high availability, high performance too, but we talk about tens of thousands TPS through the product so, from that perspective there's no other competitor on it.