IBM MQ Reviews

I work for a company that has an ESB backbone built on the MQ. It's the enterprise bus for the whole company. I was a trainer for IBM products long ago, but I moved to different companies and now I'm a senior developer supporting MQ and IBM. 

I like the MQ's simplicity and rock-solid stability. I've never experienced a failure in two decades caused by the product itself. It has only failed due to human error. 

I started using MQ on a mainframe, so I understand the thinking behind it. However, there's a lot of legacy stuff lagging behind. I think a start-up company might find the approach to be outdated. 

IBM could revamp the interface. The API is huge, but some developers find it limiting because of the cost. They tend to wrap the API course into the JMS, which means they're missing out on some good features. They should work a little bit on the API exposure.

Support utilities are almost non-existent. MQ is dependent on third-party companies. I write everything I use, like a Linux-based command line interface for all admin stuff. 

I started using MQ in 1999, so it has been around 24 years.

I rate IBM MQ 10 out of 10 for stability. I can configure the topology on my laptop and copy identical stuff into a multiple mainframe configuration.

Setting up MQ is straightforward. Generally, installing MQ isn't a big deal. It's a simple product. The magic happens when you go configure the topology and do some performance tuning.

I work for a huge company, so the deployment is done by DevOps. We're on the application side. The installation was dodgy in versions 5 or 6, but now you just drop a container.  We try to automate as much as possible, so we wrote extended Jenkins jobs to flash install all the virtual machinesWe don't deploy MQ on the cloud, but I'm thinking of migrating it to Azure. I see no benefit in a private cloud. 

IBM could lower the price because many companies are abandoning MQ from Mickey Mouse products like RabbitMQ and Kafka. Kafka is horrible but free. 

We mainly use IBM MQ when creating the integration buses for different customers. For example, for creating external API for the internal systems, we use IBM MQ quite extensively.

The interface is good, and we work using API functionality in the main part of our projects. The solution is easy to understand and even medium developers can easily start using it.

More documentation would be good because some features are not deeply implemented.

I have been using the solution for more than ten years. 

It is a stable solution. I rate the stability nine out of ten.

The solution is highly scalable. We have a number of projects with more than one hundred thousand users. I rate the scalability ten out of ten.

The initial setup is easy. If the required access and permissions are provided, the deployment takes one day or less. But in most cases, we wait for some permissions or access to systems to finish the deployment on the customer site. One DevOps employee is enough for the deployment.

I rate the initial setup an eight out of ten.

The pricing seems good according to the functionality that the solution provides.

It is a very stable and scalable product and is a market leader in its appropriate sector. I rate the overall solution an eight out of ten.

I haven't used 100% of the IBM product. That said, the message transformation is very good. My application may not always be running, yet even if it is off, whenever I stick on my applications, I get all the messages that I'm supposed to get. Also, the sending functionality of the application may not always be on. I can keep sending the message, and they will get my messages when their applications turn on.

The initial setup is easy.

The GUI part could be better. The command line part is fine if the person knows the commands. However, we started using it on the GUI. It needs more direction, and it needs to be easier to understand. If the connectivity is not happening between the receiver and sender, it would be ideal to have some kind of a GUI that helps me to find the issue. Right now, whenever the connection is not happening, I use the debug a lot, and I use it to see configurations. I'd rather just have a message in the GUI that can say, for example, "The port is not enabled. The port is wrong." 

I used to get an issue with the connection. Maybe the configurations are perfect. However, the issue is on the other side, where maybe the component is down. I will only come to know that when I ping or ask the other person. Instead of that step, if there was a GUI that would tell me exactly what the issue is would make troubleshooting clear.

In general, they need better visibility and not just the GUI design side. They need something that elaborates to the customer or user where the issue is. 

Technical support needs to be faster and more knowledgeable. 

I've been using the solution for more than four years. 

Product-wise, there is no problem with the stability.

That said, when there are a lot of messages, I may need to increase the bandwidth or the queue size. If I have to increase the queue size, maybe I can increase it to even a million, however, in the down sessions, when I extract the transaction, it takes a lot of time. When I want to see what information is inside the queue when I extract it, it takes much more time, which could be looked into. It might be a performance issue or something. It might not happen every time. Whenever there is an issue with a large set of transactions, for example, if, in a minute, you get a lot of transactions, we might have an issue. Still, it rarely happens. 

We have had a limited number of users. We haven't tried scaling since we are rather small. There are very limited users. 

I have raised a couple of tickets with IBM support. The one thing I say is, all the support members are not always knowledgeable. I need a very senior person when I need something. Whenever I log a ticket, there will be one person who will not have the information to help, and I need to escalate. Every time I have to push and ask for somebody more senior, only I can get help.

What is expected is, as soon as we give some logs or share some issues, that we get a person to help immediately. However, that's not the case. It takes too long. 

I have not worked with other products. 

In terms of the initial setup, we never faced any problems. It's quite easy. Even the cloning and queue managers are really good. 

I'm not involved on the licensing side. 

I have only really been into IBM MQ. It's a good product at the moment. I didn't get an opportunity to look into or work with other products.

We're IBM partners. 

So far, I am satisfied. I'd rate the solution eight out of ten. 

I'd recommend the solution to others. 

We use it as our enterprise messaging bus, not from the transformation use cases. It's mainly from the messaging use cases only. We use it for connecting to mainframes predominantly.

It was the main messaging bus for us for a very long time. Therefore, we have applications connecting, and even some of the modern applications are still using MQ. From a company's productivity perspective, we see a lot of benefits. It's all point-to-point connectivity. For any point-to-point messaging needs, MQ is very good.

The reliability is great. You will not see a case of a message loss in IBM MQ unless there's a queue full or there's some issue with the capacity of the queue. I haven't seen any issues with respect to the message loss. That's the main thing I like about MQ.

It's very robust.

It's a stable product.

Support is helpful and there is lots of good documentation available. 

The solution can potentially scale. 

While there is support for API, it's not like the modern API capabilities. If you want to automate the creation of queues and topics, IBM provides command-line utilities. It does provide API capability; it's just not that complete.

They should make CI/CD available. There is no CI/CD support from the product. Maybe MQ should think about the modern way to handle deep-based development. 

As a user, I have about eight to nine users of experience with this solution. 

Stability-wise, we have no problems. It's very stable. 

Scalability-wise, in terms of the implementations that we have currently, it's not quite scalable. The implementations that we had were more active-passive kind of implementations up until now. There are product features that came up that allow it to scale. We understand it is scalable. However, we still need to explore it. There's a new HA capability that has come from IBM, which is a cloud-native replica set way of doing it. It's possible, it's just more difficult how we have it arranged.

We have a user base of millions and maybe 50 to 100 developers working on the solution. 

With MQ, we are trying to reduce usage since we have better products to support JMS. Most of the applications are Java-based applications, which have native support for JMS. We only use MQ right now for mainframe use cases. For all the other messaging use cases, we use Solace.

Technical support is quite good. They are some of the best. They are responsive.

Since we've used IBM for a very long time, we need to rely on them less. Most issues can be dealt with by looking at the documentation, which is available online. You often do not even have to reach out to support. That said, if you do, they are great.

We did not previously use a different solution. 

From an implementation perspective, it was hard for the features that we were using. However, recently, it has become quite easy to implement.

The setup team is a bigger team due to the size of MQ in the company, which is quite huge. We have around 200 managers and the size of the team is around 20 members and they can all assist with deployment tasks.

The initial setup is done by our deployment team. In fact, I currently work in pipeline development for MQ, so it's easy to implement.

Returns are quite good for the amount that you pay, since, with IBM products, you see fewer bugs.

I don't have any information related to licensing costs. 

We likely have an enterprise license, based on the size of infra that we have. My understanding is it is not very expensive. However, for a new company, it may be pricier.

We get everything in a bundle. There are no extra costs involved. 

I didn't look into other options. When I arrived at the company, MQ was already there. They've used it for even longer than I have - for maybe 15 years. 

We are customers and end-users.

We have various versions that we use, including versions 7 and 9.1. We have both cloud and on-prem deployments and mainly deal with on-premises. 95% is on-premises. 

If you're looking for a guaranteed messaging platform, MQ is quite good. That said, it might be expensive for new organizations. If you're looking for a cheaper option, maybe you may need to look for other MQ open-source protocols or open-source products. You may not get the same guaranteed message delivery experience that you have with MQ. However,  it might be more affordable. With MQ, from a reliability perspective, you see very few bugs. It's been running in the bank for a long time. We have very few cases where we had to reach out to IBM support. It's just too bad they do not have CI/CD capabilities.

I'd rate the solution nine out of ten.

There were some long-running processes where it was timing out. We got the request from this source application, and we put the data into IBM MQ. Then, we read the data from IBM MQ before doing the rest of the processing. Especially for real-time processes, we have just decoupled it into two different ways to ensure there is no time-out.

The publish and subscribe features are the most useful aspects of the solution.

It's not too difficult to set up the solution. 

It's stable.

Technical support is quite helpful. 

The moment you send the data, there is no latency there.

We haven't experienced any data loss. 

If they could have some front-end monitoring tool that could be easily available for the team to use, that could be great. While you may not be able to edit your messages, at least if you could look at them, see the queue, and what's inside, et cetera, that would be helpful. We'd like visibility on the health of the environment. 

I've used the solution for two years. 

The stability is good. In fact, we have not seen any issues. Only recently have we observed an issue. There was a limit on the number of messages it could contain. We are having an issue now, however, we have not usually seen any issues related to IBM MQ. Therefore, in general, the solution is stable. I'd rate its reliability eight out of ten. 

I haven't seriously explored the scalability of the product and therefore don't know the full scope of scalability.

We handle about 300 to 400 transactions per day. 

Technical support is very helpful and responsive. We are satisfied with the level of support we get. 

Positive

I have previously used TIBCO EMS as well. 

The initial setup is pretty easy. It's not that complex. I'd rate the ease of implementation at a seven or eight out of ten.

The deployment time is pretty short. It's not a long process. 

In an integration scenario, like payment processing, where the payment has to go to the backend system, SAP, or talk to multiple applications, due to the fact that it's a lengthy, complex business process, we just decouple it. Some of the information we get immediately after receiving the request, and we pass on the information to the customer. Then, we put the payload into the IBM MQ, and then we started processing from IBM MQ. So there are integrations that sometimes need to be done or worked with. 

We have an admin team that does the configuration and setup of the solution. They can do it in one or two business days. 

We have witnessed an ROI while using this product. For example, we've had no data loss since using the solution

A different team handles the setup, and likely they also handle the licensing. I don't have any visibility on the cost of the product. 

I'm a user and customer. I'm not a core developer of IBM MQ. However, I'm a user of IBM MQ.

I'd recommend the solution to others. I'd rate it seven out of ten overall. 

The solution is primarily used for business transactions. It's used for financial transactions as well. Those are the two main use cases. We exchange information with our in-house applications before we supply information to our customers and so on.

The messaging queue is the main feature that we use. We use other products like publish and subscribe, which are very useful to us as well. 

We can share data and other people can subscribe to it. 

The solution is very stable.

The solution can scale well.

We've found the installation to be extremely straightforward and well laid out.

It's easy to maintain, easy to administer, and easy to see what's going on there. Overall, it's a good product.

Technical support is excellent.

The way the solution provides us with the product and the way we use it gives us what we need. We don't actually have any issues with it. 

There could be a better front-end GUI interface for us, where we can see things more easily. However, apart from that, it works well. 

The pricing is definitely could be cheaper. Also, the support model, even though it's very good, could be cheaper as well.

I've been working with the solution for about 25 years or so. It's a good amount of time. I have a lot of experience.

The product offers good stability. There are no bugs or glitches. It doesn't crash or freeze. It's very reliable in terms of performance.

The product scales well. If a company would like to expand, it can do so. It's not a problem.

It's hard to say who exactly is working on the solution at this time. We have around 30,000 people working on it, in some way or the other.

We've got to keep using it for the foreseeable future. We don't see any reason not to as it provides us with a good solid platform. We have no reason to change anything.

We have found the technical support to be very good. They are responsive and knowledgeable. They are also very friendly. We are satisfied with the level of support we receive. As soon as we raise any issue, they get in touch with us and sort it out. It's great.

We did not previously use a different solution. We started with IBM MQ a long, long time ago and we stuck with it.

The initial setup is not complex. It is a very simple installation. I've been provided with instructions that make the whole solution extremely easy to download and install.

The entire process is very fast. It only takes about 30 minutes to deploy.

We have different departments that can handle deployments. We have about 100 people on our team that can handle this type of assignment.

This is a licensed product. We do pay for it.

While, of course, it would be better if it was cheaper, the service they provide with it, including the maintenance facilities they provide, is very good. We're quite happy. Most people have to use what IBM provides, however, it could be a cheaper license.

We're just a customer and an end-user.

I'd recommend the solution to any organization.

I'd rate it ten out of ten. It really provides everything we need.

It's wonderful and is our primary backbone for moving data across different applications, within our company. Especially when we're talking about the healthcare and pharmacy industries, where we have patients' critical data, this is what we use to move data across. It's our backbone for data transmission.

The important thing for us at this point is the amount of data that we move, the guaranteed delivery and message affinity that it offers. These are very critical features when you talk about patient data.

It has definitely brought a lot of benefit into our organization, especial when you talk about applications talking to each other. For example, when you look at a patient's experience, i.e., from the moment the patient comes in, sees the doctor, the doctor makes a lab/pharmacy order and by the time a patient goes through the lab, the data needs to be there. It provides a lot of value in moving the patient data from the entry point until the patient gets out of the building.

One of the features to pinpoint is migration. When we want to migrate from one version to another, it takes years. So, definitely, we want to see some solution for IBM's standpoint, in order to make it easy for the customers to migrate from one version to another.

There are some operation challenges; however, it could be not because of the product but instead in terms of how we use it. We might be looking for improvements by adding some self-service capabilities, in order to go through the hoops of different teams to get the objects created. Thus, this will make it easy for the developers to access some of those things.

There were no issues in regards to the stability or scalability so far. Like I mentioned elsewhere, I've been using it for years now and it has really matured, at this point. We are really happy.

Lately, quality of the technical support is not that good, as it used to be in the past. IBM supports us from the infrastructure's standpoint to the part where they provide us product support as well. So, one of the things that we did notice recently was that the qualified people who were supporting all this stuff are not there anymore.

It is important to understand how to implement it and for what exactly you want to implement it. Sometimes, we get into a situation where you may not be choosing the right solution and may not really need MQ to support your product. You may be expecting something that MQ doesn't offer, so it is important to understand your business requirements and the features that MQ offers, in order to see if it is effective in implementing the solution.

The important thing while selecting a vendor is to help the customer go through the implementation phase. One of the typical situations that we run into are the people who you're interacting with, i.e., from a customer's standpoint, the vendor may or may not have the comparable knowledge that is required to make them move to where they want to go. That's the challenge we face across all our vendors. It doesn't have to be an escalation all the time so as to get what you want. The person you're working with should be knowledgeable enough to take the customer from the start to the end.

I like its ease of administration. We just recently moved to the MQ appliance and the high availability (HA) feature is outstanding. We're really, really pleased with it and the power of the appliance itself. When you throw more work at it, the faster it goes.

For example, when you're doing maintenance, you can fail over the entire group of queue managers in that HA group or you can fail them individually if you'd like. So, it's very helpful that way. But that's the manual fail over. The automatic fail over is what we are really interested in. We did have an appliance go down. Everything failed over and none of our clients knew of it. So it was very good. We were very pleased with that.

The user interface is good. The command line version of it, MQ CLI, is good. The web user interface is really handy; really a good feature.

It updated everything. We started with Version 7 with Linux and now, with the appliance, it seems to be bringing us more into the 21st century so to speak.

We have an M2000. The M2001 has a 3 TB SSD, which is a good feature. I wish they had had it when I started. But as we upgrade, in the future, we'll probably move to that. Everything is working properly with the current version.

The reason the migrations are an issue is, we came from Version 7.01 and Version 7.5. The security in Version 8 was a little tighter. So, there were a few things we had to learn. Be sure that we were up to speed, so that's all.

We haven’t had any stability problems at all. Stability has been outstanding. We went from multi-instance queue managers, which worked fine, except they worked often. That wasn't good for us. So it was a perceived outage for our clients. The availability has been outstanding with the MQ appliance.

I have used support on several occasions. We were an early adopter, and there are always a few bugs along the way. We did use technical support and we went all the way up to the lab a couple of times. It was outstanding as usual.

We have been an MQ adopter since 1998. We were using z/OS, so we have been using MQ along the way. Then we went to Windows, to Unix, to Linux, and now the appliance.

Actually, setup was straightforward. I'm not a hardware person and it was a first-time setup. It was what they said it was. It wasn't a 30-minute setup, but it was pretty easy.

Plan your file systems. Plan your messaging names and your network routes. You want to be ready with everything before you start and once you do that, you're in good shape.

When choosing a vendor, I want knowledge and availability. Those are the two things that are most important.