Figure 9-5 Basic, coarse-grained adoption of containers 9.1.4 Fine - grained queue manager deployment  Figure 9-5 deliberately does not show the detailed configuration of IBM MQ from an availability  and scalability viewpoint, as we will discuss the considerations here in more detail later. As noted, many enterprises have evolved to have centralized ,  shared IBM MQ deployment,  where one or more queue managers have been deployed together on highly available  infrastructure. This setup is often deliberately created to assure a central enforcement point for  the IBM MQ administrators to govern and maintain. Initially this might appear ideal ,  but there  are several issues: Applications want control over their IBM MQ resources, and this requires isolation to avoid  application teams from affecting each other. For instance, a team might want access to the  latest features of IBM MQ, while others do not. The use of a container orchestration platform  enables isolated fine - grained IBM MQ resources to be created and managed in a  standardized way. This is true, even though they ultimately run in completely separate  containers as shown in Figure 9-6 on page 575 .  GLYPH<SM590000> If multiple applications use the same queue manager, maintenance must be scheduled  across application teams. Dependencies across multiple teams are challenging to arrange  and often cause additional effort and delays. GLYPH<SM590000> If an application uses messaging resources on the same machine as other applications  there are limited amounts of isolation that can be provided. For instance ,  there is no easy  mechanism to limit the CPU that one application can use compared to another application. 574  Accelerating Modernization with Agile Integration Container Platform VM App. C VM App. D QM VM VM Application A QM QM Application B VM App. G VM App. E VM App. F VM App. H Network connection VM Virtual machine QM Queue manager in a container