As you move towards modernizing your Integrations, you might find that the larger number of  your Integrations do not need a local Queue Manager. So you can move them to the  horizontal elastically-scaling domain. 7.7.3 High Availability One of the foundational assumptions about an application’s production readiness is that it  must meet the requirements for availability. Although designing applications for high  availability is out-of-scope for this book, one aspect of availability (the ability to handle  dynamic demand or scalability) is particularly relevant to cloud native applications.  With the ability to run IBM App Connect in Docker and Kubernetes environments we can take  advantage of one of the main benefits of the Kubernetes container orchestration engine, for  example how it brings greater reliability and stability to distributed applications, through the  use of dynamic container scheduling. In a containerized world there are standardized ways to declaratively define an HA topology  (Helm Charts). Furthermore, the components that enable the high availability such as load  balancers and service registries do not need to be installed or configured because they are a  fundamental part of the platform. High-availability policies are built into Kubernetes, and  these can be further customized by using standard configuration techniques. At the application level it is the pods that provide high availability. Kubernetes allows you to  run multiple pods (redundancy) and in the event of one of the pods or containers failing,  Kubernetes will spin up a replacement pod. This way you can ensure the availability of your  services at all times. When configuring an IBM App Connect helm chart, we can define the values for the  configurable parameters of your helm chart. Along with various Integration Server related  parameters, you will find an option called  ‘Replica Count’ . This is the count that represents  the number of pods of your application will have running all the time. You can set this value to  1 or more. By defining the number of replicas for your IBM App Connect deployment,  Kubernetes platform ensures that the defined number of pods are always running. 7.8 Migrating centralized ESB to IBM App Connect on  containers In this section, we discuss the practical considerations for migrating your centralized ESB  topology into more cloud native style deployment by using containers. 7.8.1 Overview A centralized ESB can simplify consistency and governance of implementation. However,  many organizations have more fluid and dynamic requirements to manage. And one part of  the organization might be under pressure to implement integration based on cloud-native  technologies and agile methods that are being used in other parts of the organization. 492  Accelerating Modernization with Agile Integration GLYPH<SM590000> The last topology on the right shows an advanced use case where you might want to scale  up your underlying MQ, for example, to increase the throughput. By using Stateful sets,  each instance will have its own IP address and we can load-balance between them.  However, more manual scaling of the environment will be needed because this scenario  requires a local Queue Manager.