Authors: Aiden Gallagher (https://www.linkedin.com/in/aiden-gallagher-a5a698b7/), Phil Bareham (https://www.linkedin.com/in/phil-bareham-83a16136/)

Thanks to Martin Evans and Tim Quigly for their thoughts and comments.

Introduction

Typically, when deploying IBM MQ, you will want it close to the applications it is servicing or in the organisations mandated strategic platform. However, when given freedom to decide the form factor there are multiple systems to choose from: physical machines, virtual machines, and containers. But choosing which form factor to deploy to can be difficult.

This article aims to detail the differences between the form factors and the pros and cons of each approach and a decision flow to understand which form factor might be right for you.

Deployment Options

MQ Appliance

The IBM MQ Appliance is a purpose-built hardware device that provides a pre-configured messaging solution.

Mainframe

A z/OS installation of IBM MQ makes use of the features of the z/OS platform in terms of performance, scalability, and reliability. It offers unique features such as queue sharing groups and specific adapters such as CICS, IMS and RRS Batch.

IBM i (AS/400)

An IBM i (AS/400) specific build that is different to all other types of deployments. This is a less common use case and therefore a niche deployment and skill set.

Virtual Machine

IBM MQ running on HyperVisor systems such as VMWare, KVM, AWS ESX, Azure Virtual Machines enabling multiple operating systems such as Windows, RedHat and AIX. These virtualised deployments can be deployed almost anywhere on cloud or on-premise in a uniform way.

OpenShift (and CP4I)

Deploying IBM MQ Queue Managers as part of a CP4I deployment on OpenShift

Containers

IBM MQ running on a container platform such as AKS, Rancher or as a custom-built container orchestration platform (though we haven’t seen this in the field). Makes use of out of the box container platform tooling such as deployment scheduling, upgrade management e.g., rolling upgrades, scaling and deployment facilities such as custom resources and operators.

SaaS

IBM MQ running on IBM Cloud (or from IBM Cloud to AWS), managed by an IBM team who look after the Operating System, MQ version, MQ infrastructure, logging and infrastructure monitoring.

Decision Influencing Factors

Deployment Strategy

MQ is a message queueing system meaning it holds state securely whilst waiting for services and applications to collect messages from its queues. Having MQ close to where the messages originate allows greater message assurance which leads decision making, for example, to service IBM i or IBM z applications, IBM MQ would be deployed on the same machines.  Similarly, if applications are deployed on IBM Cloud this opens the option for SaaS, Virtual Machines or Container based deployments.

Additionally, knowing where other MQ deployments are today can help make the decision. Creating new Queue Managers in the same way that exists today reduces process stumbling blocks and it is possible that automation, support mechanisms and day two activities are already understood. However, many organisations may find there is a mixture of approaches across disparate groups and parts of the business.

There may also be a drive to simplify the IT estate and MQ’s place within it. This could include consolidating multiple deployments today into a common deployment approach in all locations making supportability easier and deployment simpler e.g., VMs everywhere using the same automation scripts.

Storage

One of the primary decisions an architect will have for MQ is what storage is available and whether it meets the installation and configuration requirements. For example, there are three types of high availability types in MQ (Replicated Data Queue Managers, Native-HA and multi-instance) which each have specific storage needs.

After making a preliminary deployment target decision, an architect would need to validate that the storage requirements are met, that replication needs can be satisfied (how do you replicate stateful data to a secondary site), how do you maintain state in event of a failure / DR? This might preclude a favoured deployment target.

Performance

Performance depends on CPU, Memory and connections available. A dedicated machine or partition can provide more predictable outcomes as there is no contention of resources, as a result, for example, the MQ Appliance tested in the Lab will achieve the same performance in the field. A container for example might have other resources deployed to the same worker node which can impact availability of resources within the constraints of the worker node.

Scalability to achieve performance can be dependent on the platform or the environment, for example containers can scale relatively easy if there’s available worker nodes but a new appliance would be more difficult to install.

Knowing what type of performance is needed can influence the selection too. The MQ Appliance has the best performance for an equivalent size as the raw compute to MQ running on the appliance (or machine).

Customisation

There are multiple settings to configure within IBM MQ such as the number of LogFilePages, logging type, max initiators, heartbeat intervals etc. Other customisations include additional binaries e.g., channel exits. This can help improve performance, customise output and meet functional and non-functional requirements. This precludes SaaS services and some elements of MQ Appliance.

Ease of Upgrade

Which form factor best allows upgrades is important if the organisation is fast moving, an early adopter of new features or a need to keep up with security patches. How easily upgrades can be performed might sway the decision, for example, SaaS stays up to date with minimal skill requirement, but if an organisation has the skills, then container deployments enable more control.

Organisation Skills

The easiest factor to judge is whether or not there are skills in the organisation to build, manage and support an MQ estate. If the answer is no, SaaS or the MQ appliance might be the best choice. If these options are not possible than the secondary skills can be considered, for example is there a container orchestration platform team who are able to pick up IBM MQ deployment skills or is there a z/OS team who can pick up the relevant skills.

Can the skills be maintained, is there high turnover that would mean a constant cycle of skilling up and can the team make the best use of the MQ features or would they only have the basic skills for installation?

In contrast, if a team has the relevant MQ skills this might determine the deployment target especially when shared across the organisation as supporting multiple operating systems for the same product can also have added cost

Security

We have already discussed some security aspects that impact deployment targets, such as ease of security patch installation through upgrades or out of the box security with MQ Appliance. Other security factors may play a part, for example, if the messages on MQ cannot pass through a cloud system then on-premise strategic deployments should be considered which might be different to the cloud-based strategy.

Deciding the Form Factor