IBM MQ Reviews

There are a couple of projects where we are using MQ heavily.

It is on-premises right now. We are looking to move to the cloud in the future.

• Offers better reliability and monitoring compared to other tools.
• Integrates well with other IBM solutions. Therefore, it makes sense to use this product when a company has a large IBM solutions portfolio.

I would like IBM to improve the performance. Right now, it is lacking and can be bulky.

We have been using it for three to four years.

It is a stable product. The reliability is better than open source software solutions. MQ performs even in extreme conditions.

Scalability is lacking compared to the cloud native products coming into the market. However, IBM is working to move their products into the cloud.

The software is more suited for medium to large businesses.

The support is good. They try to resolve problems as quickly as possible.

The setup and configurations are very easy, not complex. I would give the product plus points for this. This is compared to readily available, open source products that make you scratch your head when you go to set them up because they don't have documentation.

It takes a couple days to deploy the product to production.

We are a software development firm working with medium to large businesses.

It is a very expensive product compared to the open source products in the market.

We are also using Kafka, which is an open source tool, extensively in our projects. 

This is a good product if you are looking for 100 percent stability and reliability, as opposed to implementing an open source solution.

I would rate the product as a seven (out of 10).

We work with an organization who has only one product and that works with IBM MQ. Combined with IBM MQ, this product is our primary data store.

There are many things that I like about IBM MQ, such as, its performance and reliability. 

I'm not sure that current version has event-driven mechanism requests that people go for. I would like the latest version to come with both type of event-driven mechanisms: an email server and a POP server. If that is not there, then that would be a great addition.

I have been with a company for the last three years who has been using IBM. I was with another organization before that who used it for four or five years.

For the last three years, I haven't faced any stability issues. I would rate the stability as a nine (out of 10).

Support is managed by the vendor management team. This is being taken care by some of the managers.

I was not involved in the pricing structure.

There are quite a lot of competitors of IBM MQ who have high capabilities.

I would rate the product as a seven (out of 10).

• Clustering
• Multi-instance

I have worked with IBM MQ for three to four years.

The stability and performance are good and our customers are happy with these aspects. In my years working with it I haven't seen many issues, and with the type of support IBM provides, it has been fine.

I have been in contact with IBM support many times. I am satisfied with the support.

The initial setup is straightforward. It's not very complex.

Most of our customers are quite happy with the solution but they have an issue with the cost. They want to move to cheaper solutions.

The best advice I can give is that it provides stability and performance and there's no loss of data. That is most important for our customers. The data will never be lost.

It is used by large enterprises.

All our applications run around MQ. We run a backend system working with a mainframe and we distribute records via MQ. We are using it daily.

From the time I joined this company I have been working with IBM MQ. Until now I haven't seen any severe issues related to it. Most of the time it's running. That is the advantage of IBM MQ.

It could be easier to use.

I have been working with IBM MQ for close to 14 years.

It is stable.

It can scale but sometimes, in terms of volume, it is not able to handle a huge volume. We also have limitations of queues related to IBM MQ. We often need to handle a very big volume, but currently we do have limitations. If those kinds of limitations could be relaxed, it would help us to work better.

I'm working on the development side. There is a setup team that is dedicated to working on implementations. I don't have enough hands-on in the configuration of MQ to comment on the setup.

If you're looking for stability I would recommend using IBM MQ. But people, these days, are starting to work with Kafka, which is an open system. I don't have enough knowledge about Kafka to comment on it. I just work with MQ.

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.

We are mainly using it for communication, for connecting to multiple systems. Applications are putting their messages on MQ and, from MQ, we are reading them using IBM Integration Bus. We then process them and send back the response.

The MQ protocol is widely used across multiple applications and it's so simple for connectivity. 

Other valuable features include the 

• messaging format
• message persistence
• security features, including several connection channels and name-based and user-based authentication.

I had some issues earlier, two, three years back. I don't exactly remember them now.

I have been working with IBM MQ for eight years. We are currently trying to implement IBM MQ on OpenShift and cp4i. We have MQ on-premises and we are trying to migrate it to OpenShift, a container platform.

Stability-wise, it's very good. People have been using it for 15 to 20 years. MQ and IIB are the most stable products from IBM.

We can scale up and down anytime. There are no issues there. We have 20 to 30 internal applications connecting to middleware and all of them are connecting using the MQ protocol.

We haven't had major issues, but whenever we have had an issue we have written to IBM and they have gotten back to us on a timely basis.

The setup is straightforward. There is not much to create, it's a one-time setup, including configuring the high-availability. That is the main thing. The parameters create the queues. It takes about 10 to 15 seconds for each queue.

In addition, we had IIB, the IBM Integration Bus deployment, including message flows and DB scripts, etc. So the deployment was not only MQ. In deploying IIB flows, we had some queue creation, server connections, and channel creation. Overall, it was about 80 percent IIB deployment and 20 percent MQ deployment.

We had two people involved: one guy from the support team and one guy from admin. For maintenance, in the sense of the application support, we have four team members but we are handling multiple applications, not only MQ.

We deployed it ourselves.

Although I'm not involved with costs in our company, IBM products, in general, have high licensing costs and support costs are too high. A lot of people have started using open-source, like Kubernetes and microservices. There is also Apache ActiveMQ. There are many other products out there.

I would tell people to use this, except that the pricing and support costs are too high.

I would rate MQ at eight out of 10. 

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.

For 90 percent of our applications, we are using IBM MQ for a point-to-point setup, from one application to another application. It is like a passage between them. For the other 10 percent of our applications, we are using topic subscriptions.

It's deployed on-premises. We have tried it on Docker Containers as well, where we have an instance. We haven't done a cluster setup using Docker and Kubernetes. 

It is very stable. We haven't seen any failures.

You should be able to increase the message size. It should be dynamic. Each queue has a limitation of 5,000. Also, the maximum message length defaults to 4 MB. If it is more than that it should be able to increase and allow whatever the particular size of the message is into the queue.

In terms of additional features, I would like to see it be lightweight and go to the cloud easily, and dynamic scaling should be added.

I have been using IBM MQ for the last five years at my current company but I also used it in different agencies, so overall I have used it for about seven years.

It is scalable but we have to do it manually. There is no automation for scaling it.

Support is very good. It is very fast. If an issue is Priority 1 they will respond very quickly and call you.

It is pretty easy to set up. The installation takes less than five minutes for each server. People can learn IBM MQ in one week.

Even a version upgrade can be done easily. Including doing backups and installation, it can be completed in 10 to 15 minutes. Even RabbitMQ and Kafka require more steps for setup than IBM MQ. Installation of the IBM product is very simple. 

For individual projects, IBM MQ may cost more. Here, we are using it globally. It is distributed around the world for our operations, so cost-wise it is less for us. But if you go with individual licenses, the cost of IBM is much more.

We are also slowly moving forward into using Kafka.

We calculated the costs for our total environment of going with RabbitMQ, and if we went with priority support for RabbitMQ versus the cost of IBM MQ, there was almost no difference in the costs. Unless we went fully open-source, we would not save anything with RabbitMQ.

My advice to someone who is looking into using IBM MQ would depend on their budget, the application criticality, etc. If applications are less critical, you can go with open-source products. 

Apache Kafka is growing quickly. People are using it on almost every project. The future will be Apache Kafka only and there might be some RabbitMQ use as well. But I see that Kafka is gaining the most. IBM MQ won’t support large streams of data but Kafka will support large streams of data. For example, for Big Data projects, will only go with Kafka.