Figure 7-4 Example of a cloud native deployment Chapter 7. Field notes on modernization for application integration  439 Compare this diagram with the diagram for the traditional topology from Path A. The first thing  to notice is the smaller amount of dark-blue product-specific components. This is possible  because much of their role is now performed in a standardized way by the container  orchestration platform. Indeed the remaining dark-blue boxes are simply references to  standardized container image templates (and Helm Chart templates) from which they were  built. This demonstrates the level of consistency that a containerized approach provides. Let’s begin by comparing those same three aspects we discussed at the end of the previous  section, then we look more broadly at other benefits of a cloud native approach. GLYPH<SM590000> Isolation (fine grained deployment) : Containers are truly isolated from one another,  almost as if they were separate operating system instances. The integrations can be split  across multiple containers so that changes to the integration flows — and also changes to  fix pack versions of the IBM App Connect runtime — affect only a very small number of  integrations within a given container. GLYPH<SM590000> Scalability (policy-based elastic auto-scaling) : Container orchestration frameworks  provide elastic scaling capabilities out-of-the-box in a standardized way. They enable  automated dynamic changes to the number of replicas of containers based on defined  workload policies. GLYPH<SM590000> High availability (auto reinstatement) : 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 customized through  standard configuration. GLYPH<SM590000> Visibility (platform-based monitoring):  With fine-grained deployment comes a larger  number of components deployed. Container orchestration systems offer a single way to  view the health of components across all types of runtime deployed (in other words,not  just integration). Furthermore, common standards such as ELK stacks and Prometheus  are coming to the surface as effective ways to add deeper monitoring capabilities. These  are often built into commercial container orchestration offerings such as OpenShift. GLYPH<SM590000> Repeatable, rapid topology creation (infrastructure as code):  In a container  orchestration environment, you don’t build topologies yourself. The topology requirements  are defined declaratively in files that can be stored alongside the code. This ensures that 