IBM MQ Reviews

We use the solution as a messenger software, in order to send messages to various applications.

The main issue we are having with the solution is due to the connection dropouts which have been going on for a long time now. Sometimes randomly the connection gets disconnected and we try to send a message, we get a failure. We then need to manually take an action on the message, which is happening quite a lot in production. We have been working together with the MQ team trying to increase the connection and some channel upgrades. We are taking steps in the right direction but the issue is not completely fixed.

Additionally, there is not any statistical messaging information being captured. We are not able to pull up any reports to determine when a message was sent. For example, how many messages during the day or during five minutes.

I have been using the solution for 13 years.

The solution is very stable. We have not had issues, except for the connection dropouts which could be related to the machine we are using.

The solution is scalable. It is flexible because, for us, we used the solutions adapter to provide the connection parameters to send a message. This has been quite easy.

We have previously used and still do, Rabbit MQ, which is open-source. It is getting quite popular because it is also stable and it has a good UI. This UI allows us to check the messages with some statistical data.

This solution requires a license and we have purchased an enterprise license.

I would recommend this solution. However, there are some emerging competitors on the market that provide a competitive alternative.

I rate IBM MQ a seven out of ten.

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.

We are using the solution for taking messages off the mainframe and distributing them down to a large, high-performance computing environment supporting over 4,000 servers.

The most valuable features I have found to be the message queue itself and its ability to bridge between mainframe type services to distributed services.

The clustering capabilities have provided some difficulties when it comes to resiliency. This has been a challenge for managing the environment.

I have used the solution for approximately 15 years.

We had stability issues with the solution. I would be looking at replacing the product, but I am not in charge.

I was not on the team that was on our internal MQ for support but I know IBM support services are really good. While I have had some issues and long nights supporting IBM software in my 33 years of IT, the support personnel are good. I always say good things about them. It is not their fault that their products come up short, but they do a good job at supporting customers.

The installation was straightforward until we started to have resiliency problems, it then became more complex to have to set up clustered MQ servers. We were using Linux Red Hat cluster services, which became an extra burden. When it eventually came time to do other activities, such as updating the operating system or a specific driver, for example, a firmware driver for the bare-metal servers themselves, having the MQ's clusters being sensitive caused a challenge for service and support.

The solution costs are high, it is going to cost a fair bit for annual operating costs and support.

I would advise, if I was the person in charge, I would tell my architecture team, "Bring me three other MQ-type solutions and do a POC to see if we can get better performance, resiliency, and reliability at a lower cost."  I guarantee there are solutions out there that can do just those three things.

I rate IBM MQ a six out of ten.

The primary use case of this solution is for the general merchandising and retail market.

From the infrastructure point of view, it's a great improvement and it's more flexible to the latest hardware. Also, it is flexible for whatever is coming or whatever is available for on-premises and cloud integrations.

The most valuable features are RDQM and queue sharing.

There has been a lot of improvement in architecture. It handles better with the new architecture such as Cloud, and Cloud-on-premises integrations.

Also, how Kubernetes can be deployed is helpful.

I would like to see message duplication included. We don't have a mechanism for duplicating a message.

There is a different model where you can have multiple subscribers and not publish the stored data to multiple subscribers. 

Duplication is the most important for sending the same data for different applications.

We have been using IBM MQ for 15 years.

We are using 9.0.0.6 and in the process of upgrading to 9.02.

In terms of stability, IBM has proven to be very rare. It's a very stable product.

We test in very large volumes.

We tested ActiveMQ and it's nowhere close to IMB MQ.

Scalability is an area that has improved a lot. The scalable data is different. 

The way the cluster handles and cluster load balancing is different than what it used to be.

Now with the uniform clusters, it's much better. There is a lot of competition especially with messaging. With streaming, people are using it for messaging also. 

It's very flexible to scale.

We have been using it for a long time. We have a team of 15 people who are using this solution. There are more than 5,000 integrations that are using this solution in all platforms, such as Mainframe, Windows, and Cloud environments.

Tech support is very good. I guess other support groups if someone is looking for ADP accounts it lacks but in general technical support is good.

I would rate them a nine out of ten.

Previously, we did not use any other product. I am not familiar with other technologies.

I'm learning and doing some experiments, but we have found a  product for the volume we have.

The initial setup is straightforward, it's easy.

If someone knows its basic structure, it is easy, but the open-source is much easier than IBM MQ because you just have to install it and start working on it. With IBM MQ you have some installation procedures.

The open-source version needs route access which could be security compliance and could be complex.

IBM is expensive.

I would recommend this solution and suggest you start using it if you have the budget. It's very stable and robust. It's a proven technology, so no one needs to worry about that.

It all relies on the budget, that where all of the problems are. People want to use open-source, and businesses do not have a budget.

It's a good product to use.

I would rate IBM MQ a nine out of ten.

We are all using the file transfer or MQ FTP feature. We are also it for distributed queuing and clustering.

Currently, we are not using many advanced features. We are only using point-to-point MQ. I have previously used features like context-based authentication, SSL authentication, and high availability. These are good and pretty cool features. They make your business reliable.

For critical business needs, everyone uses only IBM MQ. It is the first choice because of its reliability. There is a one-send-and-one-delivery feature. It also has a no-message-loss feature, and because of that, only IBM MQ is used in banking or financial sectors.

It would be an advantage if they can include streaming in IBM MQ, similar to Kafka. Kafka is used mainly for streaming purposes. This feature is clearly lacking in IBM MQ. If they add this feature to IBM MQ, it will have an edge over other products.

I have been working with IBM MQ for the last 14 years.

IBM MQ is a very stable product. You also get very good support from IBM, but we rarely have to go back to IBM for support.

It has good scalability. We are using point-to-point or distributed MQ, so we are not that much worried about scalability. If we need scalability, we can use MQ clustering for a high workload. We can configure it for resiliency and high availability by using the multi-instance queue managers. If one of the nodes goes down, it will automatically failover to the other node. It also provides some advanced high availability features on top of the multi-instance queue manager.

You get very good support from IBM. If you are facing any issues that are tricky or there is any code issue where FDC files are being generated and you're not sure what is happening, you can open a case with them. They will help you with that. They are very efficient.

The initial setup is very simple. The installation doesn't take more than 15 or 20 minutes.

I have installed it myself. I'm also doing maintenance, patching, upgrades, and migrations. We have a team of 11 administrators who are working on IBM MQ. They use it on a daily basis.

The upgrade process is simple. I refer to IBM Information Center. As a part of the preparation, I go through all the steps that they have given. I correlate the information with the infrastructure that we have. According to the current infrastructure, we document the requirements, and after that, we do the upgrade. We couldn't do in-place migration or upgrade, so we had to do parallelization. We took a new server, installed the new version, created a new queue manager, and migrated all the services.

It is a licensed product. As compared to an open-source solution, such as RabbitMQ, it is obviously costly. If you're using IBM Message Broker, which is a licensed product, IBM MQ is included in the same license. You don't have to pay separately for IBM MQ. The license cost of IBM MQ is lesser than IBM Message Broker.

I have been asked to do a PoC for one of our use cases, and we used RabbitMQ for that. They wanted to assess RabbitMQ in comparison to IBM MQ.

Obviously, IBM MQ has more advantages when compared with RabbitMQ. The main reason for doing this PoC was that RabbitMQ is an open-source product. Cost-wise, it looks effective, but from a technical point of view as well as from the point of view of scalability and features, IBM MQ is very enriched.

I would definitely recommend this solution, but it also depends on your needs and business case. I have been using IBM MQ for the last 14 years. I am very much used to it, and I like it. I have used other products too, such as RabbitMQ and Kafka, but not that much. 

I would rate IBM MQ an eight out of ten.

It's the EAI for connecting all our services like transport systems, replenishment systems, and order entry systems to our supply chain warehouse systems.

The most valuable feature is that it's a very strong integration platform and it is quite a monolithic solution. It's got everything.

At the moment we're trying to be a little bit more nimble in terms of how we deliver things for the business. We need to look at using some of the cloud-first as we have invested quite heavily in Azure. So we want to move away from all our legacy data centers and at the right time, we will move into the cloud as much as possible.

It's hard to put in a nutshell, but it's sort of developed as more of an on-premise solution. It hasn't moved much away from that. But we want to use the auto-scaling and scalability of some of the cloud services. It has developed a fair bit in terms of even the database of the board and stuff like that. Over the next three to five years, we want to move totally into the Azure.

I have been using IBM MQ for fifteen years in total. 

It's very stable.

It's the old way, old school scaler, where you need to add calls and you need to add memory, you need to add compute power, and you need to add storage capacity. You need to have bigger CPUs and more and more cores.

That's the old way of doing it. So you need to think about hardware. You need to think about memory, you need to think about storage capacity, you need to think about different switches, network switches, and whatnot. Scalability hasn't been a problem. It's just the sort of older generation of doing scaling so we want to be able to scale in the cloud.

The process for the scaling could be a little bit simplified.

IBM handles technical support. They are good. 

We did a selection and instead of going with some of the others, like TIBCO and whatnot, we went with IBM MQ.

We've set it up in several ways. I had it for a year. Each original implementation was with Accenture and we've had several crews come in to manage the services. There are different SIs that come in like Tech Mahindra and HCL. Over 15 years we've had a lot of independents come in and support. 

We're just building on top of the existing platform now. But we've made a strategic decision to move away from this on-premise infrastructure, the data centers if possible.

We've got 4,000 employees, it's quite a sizeable business that we take on vendors to come in. We're not an IT shop. Different managed services from different vendors.

We don't consider users for the platform. It's more about what transactions. So I think it ranges from two and a half million to 10 million messages a day.

My advice would be to rethink the cloud strategy. Make sure to have certain components that you can put into the cloud. Think about cloud-first properly so that it scales automatically. It knows how to work with some of the container services that are out there so that it scales better. It has some cloud components that are good but you still have quite a strong on-prem infrastructure to support it.

It's quite a complete solution. They have modules and stuff that they acquire and may add on as features and modules, additional modules, which is a very complete solution. It's been expensive to keep going the way we're going. And the turnaround is a bit slow, slower than we want. The business is changing quite rapidly, being in retail so we need to pivot quite quickly. And so that's why we're looking at seriously moving towards the cloud where we can simplify some of our processes and actually even our maintenance in it and the way we operate.

I would rate IBM MQ a seven out of ten.

We are a bank whose core banking system is not so advanced. It is still running on an AS/400 system. Credit Card system is are deployed on IBM mainframes. About 70 to 80 percent of the bank's core systems rely on IBM AS/400 and mainframes. The enterprise service bus is used in conjunction with MQ to break synchronous web service /TCP calls into asynchronous MQ calls and expose them a web services-based or API-based service for both internal and external customers. 

As part of enterprise architecture principles, we have enforced all connectivity to be service/ interface based by using ESB, MFT or API. Minimize the point to point connectivity.

We are using dedicated IBM power/pure-app servers to run IBM Integration Bus, IBM MQ, and WebSphere Application Server. These are the three components being used for the bank's enterprise service bus.

People have started using the likes of Kafka, Spark and other new messaging technologies. But when you take the likes of banks into consideration, which mostly are running on mainframes and AS/400, implementing advanced technologies are not an easy job. Getting an MQ-certified guy is not that difficult in the ASEAN market. There are a lot of certified professionals. That's one of the reasons we still use MQ for most of our messaging. We are still looking at open-source deployments but we have not yet implemented anything like that because of the knowledge GAP & dependency on the existing products. We do not have a dedicated team to take on that task yet.

With IBM MQ still in the bank, and a dedicated team which has expertise in it, we really cut down the time-to-market, from a few months to a few weeks. The development framework is already there. If business comes up with requirements, technology team already know what needs to be done. And by building the in-house team, it gives us the facility where we don't need to ask the IBM guys or other vendors in the market to help us every time we have a new requirement.

Another way MQ has improved the way our organization functions is customer notification. Whenever payments are happening, such as incoming payments to the bank, we need to notify the customer. With MQ we can actually do that asynchronously. There are requirements for notifying customers on a real-time base & also for each and every payment sometimes, once a day. These are be enabled with the help of MQ.

In addition, there are fewer failures during the end-to-end payment process. MQ comes in very handy because we don't lose messages in transit (message persistence). It gives us the ability to store and forward messages when required. We heavily rely on MQ for these kinds of requirements.

Also, we have certain applications that want to receive the messages in both production and the disaster-recovery data center at the same time. Without MQ in the picture, it would have been very difficult for us to configure that. MQ Publish subscribe capability is very helpful in that scenario.

MQ has helped to reduce integration costs, mostly by acquiring the enterprise license of MQ. We can actually set up multiple MQ servers in the same environment and each MQ server is dedicated to a particular application. We also use MQ up to a level where the messages are coming from multiple host systems and they go back to a single channel. When written back, the response goes to the exact host that had sent the request (Message Affinity). Without a tool and without a messaging architecture that is as good as MQ's, it would take a lot of time in hard-coding to achieve that. Prior to the team being set up and having these frameworks in place, it took roughly two to three months to deliver any of these integrations. Now it takes three to four weeks. It has helped reduce the effort and man-hours by half.

We have been using the normal messaging along with channel authorization. 

At certain times — although not in this bank, in my previous experience — we had used the message authorization on top of the queue. That meant that the moment a user tried to write a message it would be authorized before it was written. 

In the ESB architecture, MQ is used to decouple synchronous consumer specific web services calls from the host system calls, by implementing state management. Request and response message matching rely on MQ Message ID & Correlation ID (MQMD header properties).

Message load balancing being implemented using MQ or achieving high throughput, while Message affinity ensures response messages are propagated to the very same host system which had generated the request message.

MQ publish subscribe feature being used to for notification where multiple instance of one or more applications can subscribe to the same topic at different time. 

Message expiry features ensures the redundant or unwanted messages are expired automatically from the MQ based on the settings. This feature is being used at times to ensure no duplication of payments.

Message persistence feature ensures the message availability even after any planned/unplanned downtime.

MQMFT feature ensures files are delivered asynchronously and complete file transfers are automated.

MQ authorization can help to ensure high level of security in accessing the messages from a MQ server or sending messages via MQ channels between two or more systems. 

Day-to-day, I don't really see anything much that we are lacking, but I have never really compared MQ with other products to see what it lacks.

I am well aware of the way that IBM sells the suite of products. But I would like to see it integrate with the newer ways of messaging, such as Kafka. They might say that you have IBM Integration Bus to do that stuff, but it would be great if MQ could, out-of-the-box, listen to public Kafka.

One of the other improvements that I would like to see from MQ is for it to be containerized. It may already have that functionality.

I have worked with IBM MQ for more than 10 years. I started using it in 2006. Recently, in the last three to four years, I have not had any work in the development area. I have moved on to enterprise architecture, so I don't really get a chance to use the solution every day. I haven't used it in the last three years.

I do read up on the new features when I get a chance to read, but I don't exactly have hands-on now-a-days. I now guide the team when they have issues, on things like how to set it up, how to have particular architectures on MQ. I still consult on it and I'm still familiar with it.

It is stable.

We have only had issues with the IBM GPFS File System, but that is a different product. We had an issue when we wanted to have an Active-Active deployment architecture across our production and disaster recovery site. We wanted the same MQ server to fail over to the disaster recovery site and come up from the state in which it went down on the production site. To achieve that we need a synchronous file system that is able to replicate the same data on the other side.

We haven't had any scalability issues with MQ. We are running on a scalable hardware platform with a goal of virtualizing deployment up to multiple cores, and it can add on more and more compute and RAM when required.

For at least the next five years we are sticking with the existing implementation, while we are looking to implement new features, such as containerization.

Our in-house support members are all certified. Most of them have 5 to 10 years of hands-on experience. They don't fall back on IBM for day-to-day support/issues. But if there is a Severity-1, they do log a problem ticket for further expert advises from IBM.

We have only had one issue that I can recall from the last four or five years, to do with the file synchronization. To figure it out, it took a few days.

Overall, the support has been good. As IBM doesn't have a lot of resources in Malaysia, they rely on India or Singapore region for support sometimes.

I am MQ version 6, & 7 -certified solutions architect & system administrator. So I find the setup to be very easy. I have been using MQ since very early of my career, and I was also with IBM for quite some time. So for me, it's very straightforward. The installers come with a nice, quick-setup guide, and most of the time, after the training, users can go set up their own MQ.

The amount of time it would take to bring it to production depends on the scope of the services. If I just have to install MQ, it is not more than an hour. But if I have to install MQ for specific servers, I would probably have to take account of the log size, its location, and what the volume is per day or per week, availability aspects, so it would take a bit longer.

Most of the time, when we implement MQ, we implement it along with other products. It depends on the use case. If you just want to query the server to get the information, I would recommend that to be asynchronous because inquiries are huge in volume. If the use case is payments, it could be defined as synchronous mode, and within the flow we could still break it into two or three parts.

From the design point of view, it is still pretty straightforward, depending on what licensing model you want to go for. If you want to use one MQ server with multiple clients it's doable, but if you have more critical systems running, then you should go for multiple MQ servers so that you have a dedicated server for each particular application. Those are the guiding principles that we use internally for projects to follow.

For deployment, we have written our own scripts. We are mostly relying on AIX/ Linux server. Our scripts are pretty much standard to do things like create/ change queue, channels and it's properties, shut down, restart the MQ services. All these are already scripted, so for our support team it takes them a few minutes to run through them, one after the other, and wait for scripts to be executed.

We have a fully dedicated team in-house to support MQ. There are teams that can help. TCS is one of them and IBM itself is one of them. And there are a few local vendors in the market that are quite proficient in it.

We have a support/ maintenance team of four pax and we are running 200 to 300 services on MQ. The solution doesn't exactly provide a user interface to the business user. The solution is more of a technology layer to support applications and we have 15 to 20 applications that are connected via ESB & MQ.

We have a multi-year OIO (open infrastructure offering) with IBM and if there is any additional licensing required it gets deducted from the OIO. We have been using IBM's other services as well.

We have been looking at some competitors; for example, TIBCO Messaging and MuleSoft from Salesforce. One difference I have seen is that TIBCO is already a containerized edition. I have yet to discuss with IBM MQ if it is available on container. Another thing TIBCO has is that its messaging framework comes with a package for Kafka support as well as plugins for MQ connectivity. It allows you to connect to MQ or to Kafka for messaging.

We are also going to look at the IBM API-led integration. We have been running IBM products for some years so we may want to compare & see how these gets compared with their counter-parts.

Overall, MQ is good, capability-wise. You still need a messaging platform and MQ is quite a reliable messaging platform. I have not seen hiccups using MQ across multiple environments in the bank. I have been using it since 2006 and I have never experienced any issues with the product itself. The guidelines of the product, the way it is used, the way things are done, are pretty self-explanatory. There are multiple blogs/ online helps available and there is a lot of help available from experts around the world.

Have a look at the features. If they complement the requirements you have, go ahead with it. If you are very technical and want to understand more about the open-source tools and features, that may require a notable learning curve.

The product has been around for a long time. It's probably time to see what MQ is going to add to its features. We have not started using IBM Cloud Pak with Red Hat OpenShift yet. We are also looking at using containerization but probably it may take some time.

I worked as an employee for a bank where we recommended IBM MQ, and we used it.

It's for real-time messaging, an exchange between applications.

On the IBM side, we use Message Queue, all the Message Queue products from IBM. For six years, we used it for a bank, an international bank, and we integrated all the applications synchronously using Message Queue.

IBM MQ is highly scalable and has a reconciliation mechanism. These are the two main reasons we use IBM MQ. 

IBM MQ should have more extensive documentation because I couldn't find a lot of information on the system API side to help us monitor the message queuing. 

I would like to see more documentation.

I have been using it for six years. We used it for a bank, an international bank, and we integrated all the applications synchronously using Message Queue.

It has been a stable solution. 

It is a scalable solution. 

The customer service and support have always been great.

Positive

I know there are competitors like RabbitMQ and Dell Boomi. I believe RabbitMQ is built on open source and they have a licensed version as well. I don't know much about RabbitMQ or Dell Boomi at this point.

IBM MQ is highly stable and quite customizable to integrate with our systems.

We definitely installed using a service provider, and it's not that complex. It's easy. It took three to six months to start implementing the first use case. 

Around six to ten people were involved in the deployment. It is easy to maintain and stable.

The ROI is  good, but we only used it for a few use cases like banking customers. It's quite stable, so we got the value out of the installation.

I would rate it an eight out of ten. It's expensive, not cheap.

I would like to rate it as a seven out of ten. It is quite stable, but it needs to have more documentation, and that is why I rate it as a seven out of ten. 

At this moment, we don't see a use case for implementing AI, but it is definitely in our roadmap. We will definitely try to find a use case to implement any new features that get announced.