IBM MQ Reviews

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.

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.

For MQ, the most valuable feature is our ability to connect our distributed systems back to the mainframe, and pull our legacy data out of the mainframe and bring it down into a modern Java front end.

It's easy to install and it's bulletproof. We never have an issue with it. The upgrades are easy and IBM support is fantastic.

Honestly, the features they just recently released are what I wanted to see. Like I mentioned elsewhere, the appliance device was fantastic. It's MQ in a box, and you just plug it right into the network. I'd like to see improvements around that area, so we can take our z/OS systems into our distributed environments even easier.

We are very happy with the stability.

We are very happy with the scalability. It's easy to scale, easy to cluster, it's highly available, and we love the fact that IBM is now making appliance devices out of MQ, so you can buy them and just rack them right into your data center.

We are very happy with IBM support. Also, their professional services; if you need consulting, they're fantastic.

We used this product to solve our initial development solution about 15 years ago. We were coming on with Java, and we needed to connect our distributed front-end Java to our back-end legacy business intelligence code that's all written in COBOL on the mainframe. MQ was just the perfect way to connect.

I was involved in the setup. It's straightforward, but I had done this before.

We looked at a couple others, such as RabbitMQ and Sonic. They just didn't have IBM’s weight behind them. I love it.

When looking for a vendor, I look at their reputation, reliability, and a recommendation from the industry like a Gartner report. The Magic Quadrant is huge for us. We look at quadrant leaders all the time when we're taking solutions.

Don't hesitate. Call IBM and get them in there tomorrow.

It can do messaging throughout multiple platforms. That's the major benefit for MQ. At the same time, we use it quite extensively to do messages between the iSeries and the mainframe.

The amount of transactions: You don't have to send a file down. You just send the messages; whatever the transaction is. It's going to be much more effective and more trackable.

It's pretty good right now the way it is.

I don't know whether it is available with the new features, but in the older versions, I remember, to test a queue, you actually had to call an API to send messages back and forth. If that would be a one-command scenario like on the iSeries, instead of me calling the API, sending a message and receiving it, I would like to have something like that. I don't know if MQ’s new features support something like this.

Stability’s pretty good. I haven't had any issues. Although, in clustering, you have to know exactly what you're doing. Otherwise, your cluster will be out of whack a little bit. Otherwise, it's stable. It's very stable.

You can scale it anywhere.

I have not really used technical support in the last year.

When I did, I've had experiences with channels not starting up, either due to connectivity issues which turned out to be either network-related. The messages are really clearly defined and errors are logged, so we referenced that and based on that, we took action.

When we do contact technical support, they're excellent; 5/5.

Because I had worked with it before, initial setup wasn't that bad. If I look at myself at the beginning, when we wanted to set it up, I actually went and took a course before setting it up. Especially on the iSeries side and all the communications, you have to get familiar with all the terms and terminology that are being used on the application. Once you know that, then setting it up is not a big deal.

It's very easy to set up, it's very stable and it's trackable. MQ is a really good tool to be able to send messages back and forth between multiple platforms. If they're looking for a solution for sending files across, they can actually use MQ to send the messages across.

I haven’t given it a perfect rating because there's always room for improvement.

The most important criteria for me when selecting a vendor to work with is being strong and supporting it, and being there for a number of years, so I don't have to worry about an unsupported product.

We use it mainly on iSeries and mainframe, so I’m not really involved in using MQ to connect across cloud, mobile, and devices as part of the intranet of things.

Scalability and guaranteed delivery are the most valuable features. It's pretty straightforward to scale out. We use MQ to back our enterprise service bus. Guaranteed delivery is very important for most of the data that we send. Having a product that enables that is very valuable to us.

My organization has used MQ for a long time. It is a very scalable, common platform that we can use for sending messages. We use MQ in terms of messaging, MQTT, and MQ FTE for file transfers. It's versatile; it's very functional; and it provides us with a common messaging platform. It eases our integration.

With the introduction of MQ FTE, we've been moving away from other file transfer options, and standardizing the actual large file transfers with MQ FTE versus the previous product that we had. We've standardized on MQ FTE, in terms of shutting down basic transfers like FTP and other basic ways of transferring large files. Adding the MQ FTE functionality, on top of the MQ backbone, has been nice.

The product itself is not difficult to use. I guess you could always ask for a little bit better GUI admin console. All in all, it's not hard to use.

In a large organization like ours, sometimes we have a large MQ installation base; lots of connection points. If there was a more graphical representation, in terms of looking at the overall landscape of where we have MQ implemented, that you could drill in and out; that would be nice. A picture’s worth a thousand words, a lot of the time; if it was more graphical in terms of displaying the overall topology and layout of the MQ infrastructure we have; just from a high-level, admin-type view; just an easier way of looking at things.

It's very stable. It's been around forever. They have functions and features that are useful. Core-wise, it's a very stable product.

I'd probably recommend going with MQ. Don’t waste time with some of the other products out there. We constantly re-evaluate our portfolio and solutions; test things; and do comparative work. We've had other vendors come in, and we've run tests with them or even done limited deployments. Sometimes we buy a package and it comes with either Oracle's OSB, webMethods, or another integration platform, if you will, with their own version of their bus and messaging. Those mostly stay point-contained solutions, and that's for a reason. For the cost and everything you factor in, MQ is a pretty good product.

It's a great product. The only bad thing I could ever say about MQ is sometimes finding the right talent to administer it. It's a bit of a specialized skill set. Sometimes you can have challenges finding somebody that's really a competent admin. Other than that, it's a great product.

The most important criteria for me when selecting a vendor to work with depends on the product. The company's financial stability, their ability to scale to an organization of our size, is very important. Depending on the project, when you're reaching into new territory, sometimes it is looking at and evaluating who does have the best or most innovative approach to solving a problem.

We use MQTT, which is an open standard but works with MQ for the smaller messaging, for a lot of our messaging across the enterprise service bus that connects our digital or customer-facing activities back to our older, more legacy-based systems. It gives us a good interface.

We don't really have any barrier to success; we're pretty successful with it.

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.