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. 

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. 

