IBM MQ Reviews

During my tenure, there was a transition to using IBM MQ due to its compatibility with IBM mainframe systems, which was beneficial for projects involving message queuing systems, particularly for clients like Volkswagen. I've handled various tasks related to IBM MQ, including testing connections, configuring and installing the system, setting up high availability and disaster recovery solutions, and providing administration support. Additionally, I've conducted training courses on IBM MQ.

One of the most crucial aspects for us is ensuring no data loss, and IBM MQ excels in this area, especially in banking environments where reliability is paramount. The feature I find most effective for ensuring message delivery without loss is the backup threshold. This feature allows for automatic retries of transactional messages within a specified threshold. For instance, if the backup threshold is set to five, IBM MQ will automatically retry sending the message up to five times. If unsuccessful, the message is then sent to the backout queue, indicating that it has been attempted multiple times. This flexibility allows us to handle message delivery failures by either discarding, logging, or retrying the message using mediation patterns.

The security features of IBM MQ have met our data protection requirements well. We utilize encryption with SSL keys to ensure data encryption. Additionally, many companies prefer using MQ connections with SSL challenges for added security. The integration with operating systems like Linux and authentication with Active Directory or Open Endpoint of Microsoft has made security configuration straightforward.

IBM MQ could streamline its complexity to be more like Kafka without the channel complexities of clusters, making it more straightforward. Migrating to IBM MQ from another messaging solution has not impacted our operational efficiency as we always build our messaging solutions from scratch.

I have been using IBM MQ from 17 years.

Regarding stability, IBM MQ itself is stable, but issues can arise from the surrounding infrastructure or configurations. Technical support from IBM can be hit or miss, with varying levels of expertise and dedication among support personnel.

In terms of scalability, IBM MQ has supported our growing transaction volumes effectively. We use telemetry and performance tools like Mehdi, Nessus, Zavix, etc., to monitor and manage scalability. While some tools like Cisco AppDynamics offer proprietary solutions, we often create or customize performance monitoring tools within MQ for scalability monitoring.

The initial setup of IBM MQ can be quite complex, often leading to mistakes during configuration. The documentation, while extensive, can be challenging to navigate. The deployment is typically on-premises, and the actual deployment time can vary based on the complexity of the configuration.

I was part of a small team that tested and used the IBM infrastructure in a QA environment. My activities included configuring and creating test environments and finding solutions to monitor the infrastructure.

Using a message queuing solution, we had a banking solution that integrated multiple branches and interbank systems. Different systems for credits, debits, CRM, and others communicated through this message queue solution. It wasn't just about communication; for instance, a CRM application needed to collect information from various banking systems, such as account balances, properties, contracts, and credit cards.

These systems were separate, and the message queuing solution combined information from all of them into one message. When a request was made from a workplace for information about a person or company, the message queue infrastructure routed the request to all connected systems, ensuring the workplace did not need to be aware of all configuration details.

The product's most valuable feature is its ability to work in clusters. This allows for creating a cluster of message brokers, providing horizontal scalability. Another important feature is the extensive command-line interface, which allows for comprehensive monitoring and management of the system. This enables the creation of complex scripts to configure, making it a complete and very powerful tool.

The tool is expensive. 

I have been working with the product for four years. 

The tool is scalable. 

IBM MQ is stable.

The tool's support is not cheap and fast. You can't expect a resolution from support. 

The setup of message queues in an enterprise trade system is complex, especially when dealing with hundreds of message brokers and thousands of message queues. Configuring such a large infrastructure isn't straightforward and requires tools for testing, validating, and identifying missed components.

We manage a large configuration file, likely an XML file containing thousands of lines. Many teams update this file to reflect changes in their systems. It can be split into multiple smaller files to manage this file, but this complicates maintaining a single point of truth and requires validating all combinations. Systems communicate with each other using these components, needing a common protocol.

The benefits of using IBM MQ include buffering your transaction flows, which is useful if you have spikes. For example, it can handle this increased load if you normally have 100 messages per second but expect 10,000 the next day. You can also build clusters of message brokers to scale horizontally.

The license for IBM MQ is commercial and not cheap. You get a multi-platform solution, which is important because it lets you connect systems on mainframes, personal solutions, Unix, Linux, etc.

Applications produced and consumed messages, with the IBM infrastructure serving as the transport and storage for these messages. Messaging was based on IBM MQ, and several other IBM products were involved, though I can't recall their exact names. These products were used for transforming messages, validation, and routing. The infrastructure could route, validate, split, and combine messages.

I rate the overall product a ten out of ten. Our goal was to measure the performance of the integrated system, not just individual components. This involved external systems as well. We used various command-line tools, such as IBM MQ, to collect detailed information about processes and systems. Measurements had to be aligned with configurations, meaning we couldn't use a universal solution. Instead, we had to adjust based on specific requirements and configurations.

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 are an integration company, so we deal with many software systems that aren't necessarily online all the time. Using MQ helps us by keeping a storage of the messages sent from one party to another so that once the second party comes back online, it will take from the queue. It is used for integration and middleware purposes.

I really like the SSL support in MQ, which allows us to include certificates so the queue is fully secured and prevents man-in-the-middle attacks. It is easy to create a new queue, and the queue manager connecting to the remote queue works smoothly once the IP and port are included. These features benefit us by ensuring integrity and security.

The software has many complications, especially with authorization on the queue. I had many issues with unauthorized errors and editing this authorization and giving users the right authorities on the queue was really hard. 

Another improvement could be the inclusion of more advanced queue features where you can configure a queue to push messages to consecutive queues automatically. 

Better error handling, such as a default dead message queue for errors, would be beneficial.

I have been using it for about three months now.

I have used IBM MQ with IBM ACE, and sometimes there are issues with messages in the queue not being taken by the message flow. I am unsure if this is a problem with ACE or MQ, however, it sometimes affects stability. Thus, I would rate stability at six out of ten.

It is very scalable since it handles the concepts of message queues, the most scalable technique in integration development. 

It allows for scalability and reliability by adding multiple queues and ensuring messages don’t get cluttered. It is very scalable, ten out of ten.

I didn't need to contact technical support. 

Positive

The usual solution was HTTP requests, and MQ is much better. It is more complex, however, we get persistent storage and the messages don't get lost if the other party is not online.

The pricing is very high, but if it's going to be used by an enterprise or a large company with thousands of users, it will be very convenient. However, for personal use, it's not a good idea.

I would recommend IBM MQ for companies. If we get a new IBM client, we will definitely recommend MQ because it will facilitate a lot in its request handling. For a legacy IBM client who is not using MQ, we encourage its use because it will improve architecture significantly. 

Overall, I rate IBM MQ at nine.

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.

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. 

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.