If you were talking to someone whose organization is considering IBM MQ, what would you say?
How would you rate it and why? Any other tips or advice?
It's expandable but it will add costs that should be taken into consideration. I would rate it an eight out of ten. In the next release, I would like for there to be easier monitoring. The UI should be easier for non-technical users to set up appliances and servers.
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.
It's a good product but I think it's too costly. That's one disadvantage because there are already many open-source products, like RabbitMQ, Kafka, and ActiveMQ. If you really need a solid MQ solution then go with IBM MQ. If you don't need such a robust solution then you can go with any of the other solutions. I would rate IBM MQ at seven out of 10. It has less throughput.
I would recommend it to other people. When somebody wants to do colocation with us, we force them to buy IBM MQ.
If you use it for evaluation purposes, it's good but if you're using it for freeware, it's not so good. Multiple fault tolerance and partition tolerance are great. I would rate it a seven out of ten.
If you have mission-critical applications that rely on an exchange of data, and the data is very valuable, then I would suggest using MQ. We have a team of people of 50 to 60 people using it, in middleware admin.
We are happy with it. I would give it an eight (out of 10). We are not using containers.
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.
If you have a lot of money then I would, of course, recommend IBM MQ.
I would recommend the solution, but it is very costly.
I would rate it an eight out of ten. Not a ten because of the pricing.
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).
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.
If you want high availability with little maintenance, choose this solution. We don't use containers yet. I would rate the solution as a nine (out of 10) because it is not perfect.
I would rate the product as a seven (out of 10).
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.
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.
I would recommend it. If you're looking for a traditional queuing system, IBM MQ is the right choice because of the stability and the performance. And from the support perspective, it's enough to have a really small team. It depends on the number of instances, of course. But MQ is not difficult to support. It's mostly to solve communication issues for applications and to determine what type of communication you prefer: the traditional MQ or via JMS, where you have to put it into the headers. But if you pass it, it is very stable after that and has very good performance.
Apart from IBM MQ, we are using IBM Integration processor. We are pretty satisfied with the product. I would strongly recommend the solution, depending on the elements and architecture you're using. If you want to keep your data safe, I would definitely recommend using IBM MQ. We are satisfied with the service provided by IBM MQ. We don't have any issues. I would rate it at 10 out 10. It's the best.
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.
I would definitely recommend IBM MQ to other people who are looking to implement this solution. They are going in the right direction. Everything is really in place and can be fully obtained. For me, the solution is a perfect product. I would rate this solution overall as a nine (out of 10).
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.
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.
We also considered Apache Kafka as a solution. The main difference is that Kafka is an open-source platform.
IBM MQ is one of the oldest, most underrated products in history.