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.
|
Pros
|
Cons
|
|
· Turnkey solution – built in HA, DR and security solutions
· Once deployed there are no changes required to the operating system
· Optimised high Performance machine
|
· Requires dedicated hardware
· Needs a datacentre for it to be deployed to
· Upgrades and maintenance might be required on the physical machine
|
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.
|
Pros
|
Cons
|
|
· High performance messaging within the mainframe environment
· Mainframe specific technologies and features
· Close integration with other mainframe applications e.g., CICS
· Provides shared queues across a z/OS sysplex which limits the chance of messages getting ‘stuck/marooned’ on a Queue Manager
|
· z/OS specific deployment
· In many organisations, mainframes are more access restricted which could make connecting more time-consuming
· Requires z/OS skills
|
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.
|
Pros
|
Cons
|
|
· IBM i native MQ installation which allows usage by system on IBM i close to those applications
|
· Specific to IBM i
· Needs skills specifically for IBM i and IBM MQ on i which can be niche
|
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.
|
Pros
|
Cons
|
|
· Can run almost anywhere, on Cloud or on-premise
· Offers a choice of hosted operating system
· Additional resources can be provided relatively quickly within the boundaries of the virtualisation infrastructure
· When combined with compatible external storage, multi-Instance queue managers can be configured
· Enables consolidation and efficient resource utilization
· Can implement scripted ‘pre-canned’ consistent deployment via pipeline
|
· Requires provisioning and management of virtual machines and associated resources
· May have limitations in terms of scalability and performance compared to physical deployments
· Availability is tied to the virtualisation platform
· Virtualisation teams do not have application specific knowledge and are generally decoupled teams making support more difficult
|
OpenShift (and CP4I)
Deploying IBM MQ Queue Managers as part of a CP4I deployment on OpenShift
|
Pros
|
Cons
|
|
· Comes with IBM pre-built Operators for ease of deployment, maintenance and upgrades
· Operators configure additional elements of the platform such as service and routes
· Platform Navigator allows you to view all your Queue Managers in an easy to view out of the box deployment (CP4I)
· Other IBM Integration products using operators available for simpler integration
· Very flexible way of deploying
· Very scalable tied only to available worker nodes
· OpenShift is available on Azure, AWS, On-premise and anywhere with RHEL deployments
· More portable and consistent across deployments e.g., environments or clouds
· Platform makes implementing HA straight-forward
|
· CP4I has to be deployed on OpenShift and a even version number e.g., v4.10 or v4.12
· Requires container platform knowledge and skills
· Need to be aware of state management in the container orchestration platform (which by default assumes ephemeral deployments)
|
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.
|
Pros
|
Cons
|
|
· Very flexible way of deploying
· Very scalable tied only to available worker nodes
· Simplified deployment method as everything is in a configuration file managed by the container orchestration platform (YAML or Image)
· More portable and consistent across deployments e.g., environments or clouds
· Platform makes implementing HA straight-forward
|
· Requires container platform knowledge and skills
· Need to be aware of state management in the container orchestration platform (which by default assumes ephemeral deployments)
|
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.
|
Pros
|
Cons
|
|
· Standards based deployment using lab based good practice
· Reduced knowledge requirement
· Managed service
· Product issues resolved by the SaaS team
· Fix pack and upgrade application managed for you
|
· Cannot customise and use all features
· Multi-tenanted
· No control of upgrade cycles and versions
· Primarily UI based although runmqsc is available to be run
· Only available on IBM Cloud or in AWS with management via IBM Cloud using IBM IAM
|
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
