When is MQ Appliance verses MQ Server a better choice, considering cost/maintenance and upgrades?

That is a very good question that is very difficult to answer... If you just count TCO then the Appliance would probably "win" in an environment with a few Queue Managers...

If you have a centralized architecture or a "message hub" zone in a segmented network topology then the Appliance is also a very good fit but if you have MQ servers spread out in various zones throughout your environment then you'd probably be better off with servers.

The Appliance is great but also note that you don't (yet anyway) have the option for MFT on it which is a drawback (if you need it).

Upgrades of a MQ server is always a bit arduous (despite what the IBM sales-rep claims...) and you also need to upgrade the OS running on the server of course as well as keep track of anti-virus, malwares, port-openings and network security for the server. An Appliance, not so much, just stick it in there open ONE port and off you go... An upgrade will take you about 5 minutes and you have cluster management for HA with a few clicks and typing in an IP address. Setting up MQ HA on a server infrastructure... well, you can do it, but... sigh...

So, from a TCO, security and "stability" POV the choice (if you have it) is a no-brainer, go for the Appliance.

Weighing in a more complex network infrastructure and a need for MFT the choice is not so clear anymore…

Hi Shawna - I work on the Appliance, so I'm obviously a little biased :)

But as Anders says it is about choosing the best fit for your environment. If you are likely to want a lot of 'customization' a software MQ installation may allow more flexibility, for example no user exit code can run on the MQ Appliance.  You are also restricted to client connections from your applications rather than running them on the same host as the messaging infrastructure.  On the other hand these restrictions bring all the benefits Anders notes in terms of standardization, stability, ease of use.

One take on this topic can be found in this report: Building a case for the IBM MQ Appliance

Note that if file transfer is a requirement, you can actually use the appliance(s) as the backbone of an MFT infrastructure  - the only restriction requiring a software installation is the connection for a particular component of MFT, the 'logger', if you are using it.  Lifting that restriction is a known requirement under consideration.

I'd not take the "customization" parts so much into consideration unless you are doing something very "special"... What I have found is mostly done is to "tap" the queue for messages, e.g. for development logging or for fetching error messages or to encrypt/decrypt sensitive data.

Well, with AMS added to MQ the encrypt/decrypt is no longer an issue as it is supported out of the box. As for "tapping" messages we do have the MQ Bridge for HTTP or the MQIPT that we can use to get a "HTTP Service" running and "tap" messages instead of using quite complex MQ exits...

The MQ Bridge for HTTP is not (yet anyway) on the Appliance box (IMHO it should be added as a HTTP REST interface though!) but I see no reason why MQIPT shouldn't work against the MQ Appliance...

Here's a great presentation from this years InterConnect: https://www-304.ibm.com/events/tools/interconnect/2016ems/REST/presentations/PDF/InterConnect2016_2275.pdf

Anders Wasén, Sr. Solutions Architect

IBM Champion, IBM DataPower Gateways, IBM Transformation Extender

Hi Shawna - I'm in agreement with others in this thread, that there are certainly technical considerations to keep in mind; though, the MQ Appliance has reached a point in maturity where nearly all of the feature/function and flexibility available in server based MQ is now available in the appliance. 

Some additional considerations that are key to decision making revolve around skills and licensing considerations. Small enterprises typically find the appliance to be a great option for them because of the simplicity of it (especially if they lack internal MQ skills) - but they struggle with the cost benefit of such a robust investment. When a single core or two dedicated to a Queue Manager meets their needs, it's hard to justify jumping up to the appliance (although the release of the M2000B model has closed the gap a bit). 

On the flip side, large organizations - even those which have solid in-house MQ skills - still see benefit to the appliance when they consider the time, effort and coordination required for version upgrades and similar projects at the server level, versus a simple firmware update on their MQ Appliances. 

One of the challenges that nearly all MQ customers face in considering a move to the Appliance has to do with license transfers. If you already own MQ, your licenses don't transfer over to an appliance purchase - it's not a renewal, nor an upgrade, it's a net-new buy. IBM will always take into consideration a customer who is looking to make a change to the appliance model, by creating incentives and discounts to support a transition if that is what's best foryou, but the license consideration is still a factor.

As a leader in IBM MQ technology solutions and support, TxMQ works with our customers regularly to determine the best route for each of them - taking into account technical, business, and budget considerations. Our MQ Virtual Appliance is a unique TxMQ offering that meets the needs of many customers by bridging the skills and budget gaps some companies face when it comes to your question: "Is MQ Appliance or MQ Server a Better Choice?"

(A shameless plug, I know) - The truth is, neither choice is wrong. IBM MQ, in whatever form factor, remains the gold standard in enterprise messaging.

Miles Roty
VP of Services & Support

Office: (716) - 636 - 0070 x228
Mobile: (415) - 535 - 3960
Linkedin • Twitter • Facebook

TxMQ, Inc.
Imagine, Transform, Engage
TxMQ.com • TxMQStaffing.com

TxMQ is a Premier IBM Business Partner.