IBM MQ Reviews

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

We use MQ for guaranteed delivery and once only delivery of important business to business transactions.

We use persistence messaging to ensure messages are not lost in case machine is restarted.

We have implemented business to business transactions over MQ messaging. The guaranteed and once only delivery ensures business integrity.

Reliability of message transmissions and ability to replay messages in case message ends up in backout queues.

It needs a User Interface which is better than the aging MQ Explorer. The existing solution MQ Explorer is outdated.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

The technical support is good.

We have always used MQ.

The setup was straightforward for simple usage. Load balancing is more complex.

I think the pricing is reasonable, especially with IIB as a part of it.

We did not evaluate any alternative solutions.

Get a good MQ expert to get it right from the beginning.

The integration between applications is the most valuable feature. We can use it with multiple applications.

It provides faster interaction between the applications. It makes it easier to integrate the applications.

So we're on MQ version 8, and I was at a recent event for MQ 9 and it looks like they've already added some of the features I was looking. For example, a better monitoring system, and a GUI to display messages, which I think they've already done.

MQ is very stable. It's a very simple application to set up, and once it is set you don't have to really configure or monitor it so much.

Since it is very lightweight, the only thing you have to really scale is hardware. So, migrating is very simple as well. It supports HA, so we have it set up with just an active/passive type set up. And we don't have to scale it as much. So far, its been working out great.

We haven't had to use support yet.

Our first time using a message queue system was MQ, so we went with the IBM MQ product.

Being with a state agency, we actually go through what's called a hub that has a relationship with IBM. We can't directly purchase from IBM, so we have to go send bids. But, since we have quite a few IBM applications, we always you know target IBM since we already have the support that we need and our relationship with our sales person is really great. So, we always choose IBM.

I was involved in the initial setup. It was fairly straightforward. Once you start creating the queue managers, there's some configuration involved, which our developers take care of. I just take care of the basic installation of the product, which is very simple.

I don't know the names of any alternative vendors.

MQ is awesome.

It's good for messaging, very reliable, and forward compatible, so it makes our life easy when it comes to upgrades.

It's reliability really enables us to do our interfaces. Additionally, it scales really well, so when our needs grow, it grows with us.

We would like to see more capabilities with MQ over the internet. It would be very helpful to us to expose our API and web services. We want to see that a little bit more and we want to continue to see that it's a secure means for us to protect our data.

We are absolutely happy with the stability.

We are absolutely happy with the scalability.

We did use technical support mostly when doing upgrades. I would say that we have used this solution for about 15 years already. We only encountered production problems two or three times. It is a very reliable, very solid solution.

I've been involved with integration for a long time. When we first talked about our need to do queue messaging, MQ was the first one that came up. It proves itself.

I was involved in the initial setup. It was straightforward.

I don't recall whether we evaluated alternatives. I think IBM was the first and the last one we reviewed a solution with.

Do the same thing we did. Make sure that you give it a small test first to make sure the solution really works well. Then, make sure it scales.

I've used other solutions, but the most valuable features of this solution are the search capabilities, consolidating the data and searching through the data. I think that these are some of the key things.

For this organization, it was the first log management solution. So, it definitely gave us the ability to search through the data when we had events. We could search based on the identity of the person, or the machine, or the IP address. We could do a lot of different searches.

We could also do payload searches and depending on how much capacity you have, you can do quite a lot with it.

I want to see a three-dimensional perspective to the data. I don't want to see just an event perspective to the data. I want to be able to identify a user and within clicks, know the whole activity of the user. I don't want to see it in events. I want to see it in the relevant information.

There needs to be a little bit more of investment for enhancing the user interface. That is the main thing, i.e., to make it represent the state of the actual incident response and how you would troubleshoot an incident. It was a major position by IBM when they bought it. But, we see a lot of things being done around the Cognitive side, around the Watson side, but what we're not seeing growth in, is the actual tools interface and usability.

We wanted to be able to see seamless identification of log sources, seamless categorization, normalizing of log sources and seamless alerts. All those things that are required for solution maturing, it has to be able to take data and make sense of it by itself, without a lot of input. Those are the areas that they can really improve it.

It's been stable. Stability hasn't been a problem, as long as you have enough capacity. It's all about sizing it right for the size of your environment.

We drop packets every day. So depending on how our log volume increases or reduces, you see the impact on the packets being dropped.

We've used it and it hasn't been great. It didn't seem like we could get the answers we needed without having to use professional services. For a solution like this, there are little things like, how to tune it, how to upgrade it and that as a customer we don't feel the need to use professional services for. We want to be able to just find a document on how to upgrade and that has been difficult to find.

We didn't have a previous solution. We inherited it as part of another acquisition, of another purchase from IBM and then we scaled it up to meet our capacity.

I was involved in the setup process. We got the basic functionality working, which is not difficult. It's getting the full value out of this solution that was harder.

From an analytics perspective, it's a good tool but you have to have the resources to own it. It's not only about buying it, nor is it about the capacity, but somebody has to care and feed it. It's not one of those you put it in and you can walk away and just consume the data. If you don't care and feed it, you won't get what you need out of it.

The most valuable feature is the ability to connect our different systems fairly seamlessly. Without it, I don't know how we would have connected our mainframe Intel-based systems and Power Systems together. It's the tool that we utilize to make it happen.

It's the transport tier that connects our systems. Without it, we would be very disconnected.

We're using it entirely for our transactional systems right now.

We're not really using MQ to better connect across cloud, mobile and devices, and the internet of things. I imagine that will be the tool that we will utilize that will help bring that next level in. Right now, we're not utilizing it.

Maybe the administration interface could be improved. Right now, it's very command-line driven. My guess is that if the GUI interface was a little bit better, with more of a singular interface across platforms, that would be helpful.

Like most of the IBM products, it's pretty stable. We haven't really had any real challenges. We run it on the mainframe as well as open systems and both are incredibly stable.

It is very scalable; we use it all the time.

I have not personally used technical support for MQ, but my team has. It has been very responsive.

I did not previously use a different solution.

I was involved in the initial set up at my organization from an infrastructure standpoint. We provide the infrastructure tier. On the open-system side, we helped with it and helped the implementation out on the mainframe.

The actual installation is straightforward. The configuration and the implementation of enabling MQ to talk and communicate between the systems can be complicated.

Before choosing this product, I did not evaluate other options.

From our experience with the functionality and the stability of the product, it's going to be difficult to find something that rivals it in the industry right now.

My rating reflects its functionality and its ability to allow our systems, our enterprise, to run the way it does right now. It's purely a function of MQ's ability to allow the systems to talk to each other.

Support and supportability are the most important criteria for me when selecting a vendor to work with. The ability to handle challenges quickly and responsively.

The solution has many use cases from the middleware like IBM WebSphere, Message Broker, and payments.

All the features are valuable.

When comparing the solution to the new age of streaming in messaging technology it is so large, that there are complexities dealing with multi-cloud, multi-deployment, or high availability models. The use cases and APIs can also use some simplification.

I would like to see a dashboard that shows the application's performance.

I have been using the solution for ten to fifteen years.

The solution is rock-solid and stable. 

The solution is scalable in a vertical sense however when considering the available modern cloud technology, horizontal scalability is not a viable solution. It is not worth the additional resources, time, and cost required.

Customer support is good but there is room for improvement in their process. Their support is 24 hours so if you are dealing with support in the U.S. and it is passed over to a support person in the UK for example the person in the UK will not be provided with a detailed log of what has transpired. A lot of time is wasted waiting for them to catch up by reviewing the information each time the case is passed to a support person in a different country.

Neutral

If it is a standalone implementation, it is straightforward. If the implementation is the higher availability mode, XM mode, it becomes a complicated process because it comes with a shared disk resource where one instance goes down, and another instance comes up. This means it can not always be an Active mode, you require an Active-Passive mode all the time. This can increase the setup cost and complexity.

Implementation was done in-house and it took a couple of hours.

Within the first two years, you will see the initial cost returned. 

The fee for this solution is on the higher end of the scale. The licensing fee is high.

I rate the solution nine out of ten.

We currently use the solution with 30 to 40 applications across the organization. It requires four to five people to maintain the solution including engineers, application support, an architect, and integration engineers.

For all the cases where IBM MQ is no longer required, we are migrating to a different solution (Kafka). 

The solution requires a lot of work to implement and maintain. I would suggest looking at other more modern solutions depending on what your organization requires.