IBM MQ Reviews

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.

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 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 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.

IBM MQ is the standard for financial industry messaging. As far as I know, it is the best in class.

The most valuable feature of IBM MQ is it has all the features necessary for contemporary messaging, not only for the financial industry but for any application.

IBM MQ has developed into some newer solutions. It has a message broker, it is now on the cloud, it has containerization, that has high availability features

IBM MQ may not be as convenient for Java programmers as Active MQ, for example, because Java programmers prefer Java, even though it is slower.

IBM MQ could improve by adding more protocols or APIs for a standard application, such as MuleSoft.

I have been using IBM MQ for approximately 15 years.

IBM MQ is stable, performs well, and is highly reliable. They guarantee message delivery.

The scalability of IBM MQ is good. There are cluster, container, and broker features available. It scales well horizontally and vertically.

Most of our company is using IBM MQ in my company.

The support from IBM MQ is good. They have always helped with my problems, but sometimes it can take them a while for a resolution. Sometimes you might find a bug in a one-year span of using the solution, but they will provide a fix within a matter of weeks.

Positive

The initial setup of IBM MQ can be straightforward if you have the documentation, it is step-by-step and straightforward.

IBM MQ is an expensive solution compared to other solutions. However, if you pay less you will not receive the same experience or features.

It may not have all the APIs, features, or protocols that the newest systems have, but in performance and reliability, it is the best.

The amount of people needed to maintain the solution depends on the company and how they want to maintain it. When I was working for a bank I supported 300 MQ managers with approximately 150 systems running. However, for the basic use of the solution, you do not need many people. If you add more features, such as broker and clustering you will need more people for maintenance.

My advice to others is this solution is the best there is. For maintenance, you will probably need fewer people to maintain it than other solutions because of its reliability. The features are probably the most extensive in its class.

I rate IBM MQ a ten 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. 

IBM MQ could improve capacity, monitoring, and automatization.

I have been using IBM MQ for approximately 22 years.

IBM MQ is a stable solution, it is used mainframe computers and it is secure.

The scalability of IBM MQ is good.

We have approximately 100 people using this solution in my company.

The support from IBM MQ is good.

IBM MQ has a complex setup. The time it takes for deployment take approximately two to three months.

We have a special contract with IBM MQ that give us a certain price.

I am satisfied with the solution overall.

We have five to six people for the maintenance of this solution.

I rate IBM MQ an eight out of ten.

The solution has many use cases from the middleware like IBM WebSphere, Message Broker, and payments.

All the features are valuable.

When comparing the solution to the new age of streaming in messaging technology it is so large, that there are complexities dealing with multi-cloud, multi-deployment, or high availability models. The use cases and APIs can also use some simplification.

I would like to see a dashboard that shows the application's performance.

I have been using the solution for ten to fifteen years.

The solution is rock-solid and stable. 

The solution is scalable in a vertical sense however when considering the available modern cloud technology, horizontal scalability is not a viable solution. It is not worth the additional resources, time, and cost required.

Customer support is good but there is room for improvement in their process. Their support is 24 hours so if you are dealing with support in the U.S. and it is passed over to a support person in the UK for example the person in the UK will not be provided with a detailed log of what has transpired. A lot of time is wasted waiting for them to catch up by reviewing the information each time the case is passed to a support person in a different country.

Neutral

If it is a standalone implementation, it is straightforward. If the implementation is the higher availability mode, XM mode, it becomes a complicated process because it comes with a shared disk resource where one instance goes down, and another instance comes up. This means it can not always be an Active mode, you require an Active-Passive mode all the time. This can increase the setup cost and complexity.

Implementation was done in-house and it took a couple of hours.

Within the first two years, you will see the initial cost returned. 

The fee for this solution is on the higher end of the scale. The licensing fee is high.

I rate the solution nine out of ten.

We currently use the solution with 30 to 40 applications across the organization. It requires four to five people to maintain the solution including engineers, application support, an architect, and integration engineers.

For all the cases where IBM MQ is no longer required, we are migrating to a different solution (Kafka). 

The solution requires a lot of work to implement and maintain. I would suggest looking at other more modern solutions depending on what your organization requires.

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.