IBM MQ Reviews

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

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.

In our company, it's the main hub for our whole CRM solution. MQ manages things through the Broker.

I like the whole idea. But the first things are its simplicity and its robustness. Compared to any other product, it's the most robust I've worked with. And it's extremely easy to manage.

The worst part is the monitoring or admin, especially in the ACE or Broker. There is always a problem of transparency. In MQ you can observe any process and you know exactly what's going on behind the scenes, but with the ACE or Broker, it's a problem monitoring the HTTP inputs. It's like a black box.

The reason that I'm emphasizing monitoring is that I used to work for the company that produced the administration and monitoring tools for IBM. There was a lot of competition and a lot of confusion in the market. When I moved to this company I actually used my previous experience and wrote my own tools. I am not much of a C# programmer, so I was struggling a bit. I know the concepts, but I was missing some straightforward support from IBM. They were selling it as a part of Tivoli, but you needed to implement the whole Tivoli infrastructure. If you had some other monitoring provider it was a bit of a pain. That is my concern here.

I've been certified as an MQ specialist since 1997 so I have about 23 years' experience in this field. I've been using it since version 2.0. Currently, I'm in production support and supporting version 9, mainly.

It's stable. I'm working for a FT 500 company, a global company employing about 60,000 people, and we've been using this product ever since I joined the company in 2003. We haven't had a single major performance issue or crash.

It's scalable. We have gradually increased our usage over time.

I am satisfied with the support from IBM. To be honest, I used to be an IBM trainer for this product, so I know people there. The only issue I have is that if the product goes out of service, it's difficult to get PMR (Problem Management Report) for it. In production, a lot of businesses tend to stick with the older versions.

I've been doing it for over 20 years, so it's straightforward to me. Beginners might struggle with the initial settings, like user rights and the basic stuff, but setting up MQ is fine.

Before joining this company I was mainly consulting for various companies in Germany, and I noticed the core problem was always that in projects where MQ was implemented, they were targeting too low on the management food chain. You need that to go as high as possible because it changes the whole paradigm, your ways of thinking. A lot of the implementations were bad because they were partially patching some problems at the bottom level. The whole strategy was never oriented to messaging. My suggestion would be to be aware of that. Go global from the start. Don't address things partially.

There is a team of four people who supervise all MQ activities here.

I would rate IBM MQ at 10 out of 10, but ACE or Broker are between eight and nine, because of the lack of transparency.

Our use cases include ATM transactions where a customer, for example, inquires about balances. Transactions go from an ATM at a branch, using a Java application to take the information, and it connects into our mainframe, gets the balances, and goes back. 

We also use it for when customers go online using the internet itself for things like pre-approved home loans. We take the customers' information from the front-end and pop it into MQ to look up the customer's data in the bank itself — all of the databases — and then come back to the customer. 

It is also used in our mobile banking. MQ is connected to SAP in the background. MQ is in between, passing information to SAP and SAP will give the reply back on the mobile banking app, like when a customer asks for a one-time password.

We initially went with a single server or two servers. We used a lot of the mainframe and we used it on the one server. Then we realized that we were down to a single point of failure. What we did was we enabled something called queue sharing where you have multiple landing platforms, which lets you execute multiple applications in the background. And we're now able to use our HA failover quite extensively. It previously required one server to be down and there would be an effect on customer business. Now it requires at least three servers to be down before we start feeling the workload. And even then, we're hardly ever down because we have now spread the load using the queue shared clusters.

In terms of the solution helping to reduce the cost of integration, we're using what is called the MQ Appliance. Because the appliance connects multiple solutions in our bank to this platform, we don't need to procure more licenses or more servers or more infrastructure. So at the moment, we're using a very cost-effective model, compared to two to three years ago, which is when we started to consolidate servers. We had about 400 servers but we've reduced their number by moving them to the appliance. We've consolidated all of those server licenses and server infrastructures.

For example, we took a server that was front-end, using Java, and connected to the mainframe. We have that entire server's application queue, entry queue, and all the objects moved onto the appliance. And there is no cost to it. It's just a box. There's no operating system on it. We have MQ on it and MQ then connects things to the rest of the bank, so we save on the infrastructure, on server licenses, and MQ licenses. We've created a setup like that a few times already in our bank.

This process of integration has saved us a lot of time. Previously our projects would take at least three to four weeks. Now, once we have firewalls and security in place, and once we have an acceptable solution design in front of us, they take three to four days. From the time we design the solution until things are connected to the appliance, it takes a week. It's only fast because most of it is scripted. It's almost like a container.

What we find most valuable is the fact that we can decouple it from the application. If one side is down, but someone in the bank is serving a customer and needs to connect to an account, he can put in the information and wait. When the remote system comes up and connects, we can push messages with the push function. So what is quite useful is the asynchronous function which means we don't lose everything in the bank. Although we use a lot of things synchronously, asynch is the best thing so that no banking information is ever lost, even when the network goes down and comes up.

We can also expand it across many servers with the cluster, using load balancing and failover. We use that extensively as well. The load balancing works absolutely wonderfully.

Overall, it makes us very flexible in the architecture we can use at the moment. When someone comes to us and says, "I need ABC," we can put together the correct solution for him with all our flexibility.

We use Red Hat from a server point of view. With our Linux box, MQ is on the box itself. We use that quite extensively as well. Inside of that, we find the shared HA function quite useful. It allows us to do HA really quickly, compared to how things were before.

At the moment we're very limited in the way we can interface with the cloud. 

I have been using it for 20 years now. I've been at the bank for 17 years and I used it before that as well.

The stability of the solution is very good. I would give it a nine out of 10. The main features are its reliability and availability and, as a messaging platform, it's very good in those areas.

The scalability is the one area where IBM has fallen behind. As much as it is used, there is a limit to the number of people who are skilled in MQ. That is definitely an issue. Places have kept their MQ-skilled people and other places have really struggled to get MQ skills. It's not a widely-known skillset.

In terms of the number of business areas using it in our bank, there are about 15. A lot of the major ones use it, such as credit, operations/finance, home loans, and ATMs. 

The bank has been very good in getting good technical resources to help us. There is a specific couple of people in IBM who know our architecture itself. We have what is called a value-add program where, when we have a problem or a service request, it will go through IBM but it will automatically land in the box of one of the experts who knows our architecture very well. We reach the same two people each time. We don't have to explain things to them.

We did not have a previous solution. Early on, we didn't have many options to choose from. A procurement person came along and told us that this is the best solution for us.

The setup was very complex in the beginning: how we had to put it in, how we had to tune it, and how we had to fix it. There were so many parameters. It wasn't just a simple drop-in, deploy, and go. In addition, because certain applications work in a certain manner, it required a lot of tuning.

My team, on average, has 10 years of experience on MQ so at this stage we've come to the point where we can tune it fairly quickly. So while the initial setup wasn't simple and quick, it has become very quick.

The initial setup took us several weeks, if not a few months. We had to get IBM to help with things in the beginning. We had system issues then, but it has been stable since then.

The IBM consultants we worked with were very good.

MQ's features are very extensive compared to SQS on Amazon or messaging from Microsoft. Those solutions have basic features in there. They say, "This is what 90 percent of the use cases will use," whereas MQ is very robust in the way it's set up, in the way it works, and in the way it can be tuned. You have a lot of connections where you can connect thousands of users to the bank and thousands out of the bank as well.

It is definitely way ahead of all the other messaging platforms. It's like the "BMW" or "Mercedes" of messaging. The others will still do the work, but they're fairly average in what they do. They're very basic compared to what we do. Because we are a major bank, we have many different platforms and many languages, so we use it very extensively.

You must be careful in that it must fit what you want it to do. A few years ago, we had a silo approach where everybody had their own IBM MQ and their own application support with their own teams. That got out of control. In the last few years we realized that you need to be careful about the deployment model you're using. And you need to make sure it's used for the proper use cases.

That's really the biggest lesson I've learned from using IBM MQ: You need to be very sure about what you want it to do.

I would advise that you talk to someone who knows about the solution and who is not biased. Set up a call with someone like me to look at the solution before you decide to go down this path and, similarly, before you decide to throw it out. Talk to someone who has at least seven years of experience with it and who can give you an unbiased opinion about how it works, and then make up your mind. People have come to us and we have said, "Based on what you are doing, we don't think MQ is the best solution for you. You should be looking at other solutions." And other times, we'll tell them that this is the perfect solution. 

The way MQ works is very good from a messaging point of view. There is very little that needs improving. MQ is very flexible and very tunable. We use it to transport hundreds of thousands of messages every day with absolutely no problems.

At the moment the solution is on-premise. But in the last two years, the bank has decided that it needs to go with the public cloud. So in the last two years, most of our development has gone towards decoupling MQ because a lot of the vendor applications were on the box where MQ was. We're working on the solution and decoupling everything so we can push toward the cloud itself. The solution's built-in connectors are more applicable to when we talk about cloud solutions. 

As for containerization, eventually we will go for it but, at the moment, we don't use it. It's difficult to work on a mainframe because of the way it's set up. But it's definitely something the guys will be using when we look at the Unix servers and other boxes.

For deployment and maintenance we have a team of eight people. We have three people on the mainframe and another three to four people for the appliance. They work with each other as well. On the Unix solution, which includes Linux, AIX, etc., we have another team of four, but all these teams overlap. The average upgrade won't take less than two people, but on the Unix box, upgrades are straightforward and someone can do it on his own.

We have a core banking application. If any system or application wants to talk to the core banking application, the request and the response will go through the MQ servers. The requests and responses are in the form of XML.

We have a VMware environment with Windows and Linux. 

We have clients spread all over Africa and they have to process different types of requests, such as credit requests and debit requests. We use the Queue Manager to handle these requests. Our MQ server will accept the request and send it on to our core banking application.

If you imagine the order from left to right, the application is on the left, then the enqueue server is in the middle, and the core banking is on the right. In between the queue server and the banking application, we have APIs and systems in place to understand the XML files.

The most valuable feature is the Queue Manager, which lies in the middle between our application and our core banking server.

Managing this solution is not difficult.

IBM MQ is very stable, which is important for our core banking application.

The memory management is very poor and it consumes too much memory. We have 24 gigabytes of RAM and almost every day, we had to free up processes so that it can run.

Some of our messages were not being transmitted so we had to manually look at the MQ server to cut and paste them. That is supposed to be fully automated. The problem is normally a routing issue but it is compounded if there are connectivity troubles. For example, if 3,000 messages are supposed to be sent but 1,000 were not then you have to do it manually.

The solution is not very lightweight and if it could be decentralized, then put into three or four containers, it may be an improvement in this regard.

I have been using IBM MQ since 2015.

The MQ service has never gone down and has never failed us. It is only offline when the VM is offline.

This is a scalable solution. We scale by adding another VM to our cluster.

We have eight engineers who are using MQ, but in terms of end-users, or people who are consuming the services, there are thousands or millions. It is an enterprise-level organization and each application has a user base, so the scale depends on the application.

I have never had support for this solution.

As far as I understand, we did not use another solution prior to IBM MQ. Our old strategy did not use this type of technology.

The initial setup is very straightforward. I have done it both on Linux and on Windows. With Windows, it is just a case of hitting the "next" button. I would say that within ten minutes, you should be finished with the installation.

Prior to the installation, you have to make sure that you have Java installed.

I deployed this solution for the company.

The number of people required for maintenance depends on the environment. We used to have one person manage each application that was connected to the MQ server, which meant that we had four people maintaining it.

It is difficult to assess the ROI for this type of solution.

IBM MQ is expensive and they charge based on the CPU.

I am familiar with a couple of similar solutions, including Red Hat AMQ. In fact, I am trying to migrate to Red Hat. It is very easy to install and get it running. All you have to do is get your API and you're done. Stability-wise, however, with Red Hat AMQ, I have seen cases where some of the messages were lost. IBM MQ is definitely more stable.

For the most part, this solution serves our purpose. It is not difficult to manage and the only challenges we have really had were to deal with some of the messages manually.

My advice to anybody who is researching this solution is to consider costs first. It is expensive and you have to ask what value you are going to get from it. You need to consider factors like how many messages you are sending per day. If your budget is sufficient then IBM MQ is your choice, otherwise, you should look into a cheaper option. Also, if stability is the most important thing to you then IBM MQ is the choice that you want to make.

I would rate this solution an eight out of ten.

The most valuable feature of this product is that it provides guaranteed message delivery. This is important for us because we want to have guaranteed message delivery and integrity; we cannot lose that message.

The reliability that it provides is the most beneficial aspect of this product for our organization.

One thing that I'd like to see is that queue-sharing should not depend on DB2. It should have this feature by itself, instead of depending on DB2.

In order to set up IBM MQ queue-sharing, DB2 data sharing is required in multiple LPARs. Thus, to make the implementation easy and straightforward, it will be nice if DB2 is not required for queue-sharing.

In regards to the stability of the product itself, it's pretty good. However, it depends on the configuration as well. Overall, the stability is good.

Scalability is pretty good as well and on the mainframe, we can expand it. That way, we're looking to carry out queue sharing, on the mainframe as well.

The technical support is fine. MQ is very predictable product and it's good.

I was involved in the initial setup, but not in this company; at a different company. I found that it was easy to install.

This product is from IBM which is a very well-known company.

MQ is a reliable, easy to understand and install solution.

The most important criteria while selecting a vendor are that they should be well-known and the product's reliability. These are the main reasons as to why we chose IBM MQ.

I use the solution in my company since our clients always go for a middleware solution. IBM MQ is a part of the middleware solution category. When I design a middleware solution for our clients, I use IBM MQ to basically store the message.

The most valuable feature of the solution stems from the fact that it offers guaranteed delivery of messages to users. One good thing about the product is the guaranteed delivery since it guarantees that the message won't get lost. My company uses IBM MQ since we handle a lot of asynchronous modes of the design flow, and that is why we choose to use the solution to host the message before we proceed with the other sub-processes. The tool is effective in areas like message delivery and managing large message volumes. It is a very good solution.

In IBM MQ, the channel connection is an area where my company faces some limitations. At times, we hit limitations on the connection, meaning the connection is fully occupied.

I have been using IBM MQ for more than ten years. My company is a reseller of IBM tools.

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

Scalability-wise, I rate the solution an eight out of ten.

I rate the technical support a nine out of ten.

Positive

The product's initial setup phase is very easy.

The solution can be deployed in an hour.

The tool saves on development, implementation, and operation costs. The product is quite easy to maintain.

If one is cheap and ten is expensive, I rate the tool's price a seven. The product is expensive.

Maintenance is quite easy when there is an upgrade of any version. You just need to migrate the configuration to the other platform, and it is quite easy.

I rate the tool a nine out of ten.