IBM MQ Reviews

The product does not allow users to access data from API or external networks since it can only be used in a closed network, making it an area where improvements are required.

I have been using IBM MQ for fourteen years. My company is a customer of the product. I don't remember the version of the solution.

Stability-wise, I rate the solution a ten out of ten.

Scalability-wise, I rate the solution a nine out of ten.

Around 15 to 20 people in my company use the solution.

The product is used whenever there is a need to use it in the development phase. Once the tool is deployed on a particular site, we don't need to use the product until and unless any issues or errors are reported.

I rate the technical support a nine out of ten.

Positive

Before IBM MQ, my company used to use normal point-to-point APIs. My company started to use IBM MQ because we wanted to introduce standardization in our processes.

The solution is deployed on an on-premises model.

I rate the product price a four on a scale of one to ten, where one is low price and ten is high price.

IBM MQ streamlined our company's application-to-application communication since it is a rigid and robust solution that allows you to transfer data from one system to another system using the tool's adapters. In general, the product is very robust.

A scenario where IBM MQ reliability was critical for our company's operations includes an incident involving three to four of our clients who use the product, among which a few are airports situated in regions like Delhi and Bangalore in India. All the big airports use IBM MQ as an integration platform, so it is considered a tier-one application. In the aforementioned areas, there is a need for a tool that offers scalability and robustness.

The feature of IBM MQ, which I found to be most instrumental for our messaging needs, stems from the fact that my company never lost messages when we were using the product. The product has a queue manager, and the message doesn't go anywhere until and unless you read it. The best part of the product is that it ensures that there is no data loss.

IBM MQ's security features have enhanced the data transmission process in our company since it functions in a very secure manner. Nobody can get unauthorized access to the product.

The product offers very good scalability to support business growth.

IBM MQ's integration capabilities with other systems are beneficial since we have developed many interfaces for many airports. Many systems use IBM MQ to send data from one system to another, so it has helped in a great way when it comes to the integration part.

I rate the overall tool an eight to nine out of ten.

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 are using version 9.2. The solution is deployed on the cloud and Azure is the provider.

There are four people in my company who are working with IBM MQ.

IBM MQ is robust compared to other products in the market. It also gives you support from the IBM team. We can connect to the IBM technical team in case of any production fault or errors.

For security, we have IBM MQ instead of any other products.

IBM support team is really only concerned with the IBM cloud. They're not supporting any other cloud platforms or suggestions. It would be nice if we could get support for Azure.

MQ supports more than 4MB of data transmitting. That is not supported by ASB. Because of this feature, we are using MQ. Otherwise, clients will be motivated to use Azure Service Bus. IBM MQ should think about how the cost can be minimized and how to provide better service for users. MQ could provide more incentives or services that are better than Service Bus, so that our users will be motivated to use IBM MQ.

I have been using this solution for about seven years.

It's very reliable and stable. We haven't received any frequent challenges.

We have sufficient memory and storage. From a network point of view, the TCP/IP protocols are challenging.

It's easy to expand and easy to scale.

We would like to see the IBM technical support team extend their hand to providing support for other cloud vendors like Azure, Google Cloud, and AWS.

I also have experience with RabbitMQ. IBM MQ has more valuable features and is more reliable in comparison when it comes to servers and applications.

Initial deployment is very simple. You don't need someone who is very technical to configure it, unless you are establishing a new environment or a server, or infrastructure as a service. If you're upgrading things, it's very easy.

We use one support engineer for maintenance. They monitor the server and infrastructure.

Deployment was done in-house. We've had some challenges, but that can be fixed while we are connected with our IBM MQ support team.

The length of deployment depends on if there is a huge queue manager and on the type of integrations that need to be done. If it's a simple integration or there are less than 100 or 200 applications, deployment will take four to five hours.

Small-scale companies may not want to buy IBM MQ because of its high cost. There are freeware in the markets, and many users are motivated to use those.

I would rate this solution 9 out of 10.

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.

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.

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 to connect the core banking system to several other systems in our environment. We are working on an IBM server with multiple clients sending XML messages through the IBM environment using MQ. 

The end users are working on front-end services that are communicating with the servers. We are installing MQ on the backend system to act as middleware. Mainly the users are coming from somewhere else.

The monitoring could be improved. It's a pain to monitor the throughput through the MQ. The maximum throughput for a queue or single channel isn't clear. We could also use some professional services by IBM to assess and tune the performance.

I started using MQ around eight to 10 years ago.

MQ is stable, but we face some limitations with redundancy.

MQ is scalable. 

I rate IBM support eight out of 10. We've never had problems with support. 

Positive

We previously used different protocols like TCP socket connections. Now, most of the services use MQ. 

Setting up MQ is easy. We had a "grow as you go" implementation strategy. We started with a single channel and progressed to multiple queues and channels depending on the systems and integrations with other systems. It was a gradual deployment and expansion as we grew the services interacting with the core system using MQ. Maintenance requires two or three admins. 

The MQ license is a bit high.  I rate IBM MQ six out of 10 for affordability. 

We are exploring other solutions, including the Kafka platform. There are other services that can do the same thing but maybe offer some additional features, especially on the monitoring side. It may be faster as well.

We are using Confluent Kafka for some other services, and it's a good event-streaming platform. It does almost the same thing as message queuing, but we it has some other features and can do some things better than MQ.

I rate IBM MQ seven out of 10.

We use the solution when connecting with the external system to process messages in a queue-based flow. When the solution receives a message, the flow is triggered to cycle through routing, mapping, and logic to create a pipe delimited, XML, or other formats that send to the end system. 

We created the queue-based flow to receive messages and connect them to end systems using a pop-up concept to classify messages by subscription topics. 

The solution is fast with end data compared to other messaging tools. 

With integration tools, the node is connected with the queue manager so there is some dependency. In the solution's latest version, the dependency was removed which allows us to create servers without any interdependencies.

The solution should offer a freeware version, free vouchers, or certifications for learning purposes and building a knowledge base. When creating an account to download software, you must provide user details like credit card information. If you exceed the allotted hours or days while trying to learn the solution, your credit card is charged for additional time which is what happened to one of my colleagues. 

Learning the solution is not as simple as MuleSoft or APG. Some developers left the market because they didn't know how to learn the solution. Other products provide free vouchers or certifications or learn programs but IBM currently doesn't do that. 

I have been using the solution for ten years. 

The solution is an older product and very stable. Our product teams never have issues with it.

We have experienced some issues with scalability because there is a known lag when scaling.

Technical support is rated a ten out of ten because we receive support very quickly but rarely need it. 

Positive

The initial setup is easy with no huge steps. 

There really isn't any deployment. Creating queues does not take much time and we use them with channels and subscription topics to push and pull messages

The implementation was completed in-house with integration developers doing the important work. 

If you want to route messages through a queue-based app, definitely take a look at this solution and research the cost.