9.1 Modernizing your messaging topology with containers IBM MQ first provided support for containers in 2015, and rapidly embraced container  orchestration technologies such as Kubernetes and OpenShift to allow managed production  grade deployments. IBM MQ has continuously innovated over the years such that today it is  just as at home in traditional deployments as it is in cloud native environments. Runtimes  start-up in seconds and are arguably the most performant on the market. Container  orchestration provides high availability as standard. When this is combined with cloud native  features recently added to IBM MQ such as  uniform clusters , scaling is simple and natural  within a container environment.  However, as we made clear in Chapter 4, “ Cloud-native concepts and technology” on  page 85, there is much more to moving to containers than simply a change in infrastructure.  For each technical area there are different subtleties to be considered as we move towards  containerization. In this section we explore the typical stages that customers go through as  they progressively modernize their IBM MQ environment.  As summarized in Figure 9-1 this section describes how an IBM MQ estate can be  modernized by using containers across three discrete stages. GLYPH<SM590000> Remove local connections : Ensuring that IBM MQ is running separately of the  applications it serves such that its availability and scaling is independent.  GLYPH<SM590000> Containerized queue managers : Move the queue managers into containers to gain  greater standardization, and consistency on an operational level, especially if applications  are also moving to containers.  GLYPH<SM590000> Fine grained queue managers : Reducing the dependencies between sets of queues by  separating them into discrete queue managers and potentially allowing application teams  greater ownership.  Traditional Deployment Remote connections Containerized Fine-grained Technical change:  Remove local  connections Potential benefits: Independent  availability and scalability Technical change:  Move to  container platform Potential benefits: Portability Operational consistency Infrastructure optimization Technical change:  Fine-grained Pipeline/build automation Potential benefits: Agility Evergreening Environment Integrity Application Virtual  Machine Remote Queue Manager Container Local  Queue Manager Figure 9-1 Modernizing an IBM MQ infrastructure using containers across three discrete stages 570  Accelerating Modernization with Agile Integration