content_image/1008691.jpg
<img src='content_image/1008691.jpg'>

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. 

## 9.1.4 Fine - grained queue manager deployment 

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: 

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. 

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 . 

