the integrations are always deployed onto a topology that suites their needs. Helm Charts are currently the most common mechanism for providing the logical definition of the requirements from the deployment topology. For example, they define how it should respond to changes in workload, then leave the orchestration framework to work out how to build that out and keep it running. 

GLYPH<SM590000> Cross-environment consistency (image-based deployment, declarative configuration) : Containers enable us to draw together the operating system, product binaries, configuration and the (integration) code into a single immutable image. Furthermore, we can combine that with the infrastructure-as-code to define the topology. We are then assured that we are deploying exactly the same thing to every environment from development right through to production. 

GLYPH<SM590000> Pipeline automation (file system-based runtime installation and artifact deployment) : The IBM App Connect integration runtime can be installed, and integration flows deployed simply by laying their files on the file system. This significantly reduces the specialism required in creation and maintenance of an automated build pipeline to create container images, and significantly improves the image preparation time. 

GLYPH<SM590000> Operational consistency (common platform administration) : A broader benefit of container platforms is that the skills required for operation of the environment are the same across all product and language runtimes – not just integration runtimes such as IBM App Connect. One of the aims of containers is encapsulation: that they should all look essentially the same from the outside. This allows their deployment, scaling, monitoring, and administration in general to be done by using standard container platform capabilities with little need for knowledge of what’s insi de the container. This encourages consistent practices on operations across the landscape and reduces the number of skill sets that need to be maintained. 

GLYPH<SM590000> Portability (standards-based container technology) : It could be argued that the level of standardization around container technology makes it simpler to move components between platforms, and indeed between your own infrastructure and other cloud infrastructure. However, this is a rapidly changing technology space, and careful choices are required so that components remain portable. Based on those careful choices, OpenShift allows you clear portability across various cloud and on-premises environment choices. 

GLYPH<SM590000> Decentralization (technical autonomy to business teams) : A truly cloud-native approach allows developers to focus on the creation of artifacts by simplifying build and deployment, and standardizing the surrounding administration and operational needs. This in turn makes it possible for teams to get up to speed on new languages and technology more quickly. In the past, we tended to have centralized teams, specialized on specific technologies. Relying on more standardization of the surrounding platform, it is now reasonable to allow teams to become multi-skilled across a range of build technologies rather than relying solely on centralized teams. 

GLYPH<SM590000> Shift-left (automated, production aligned testing) : Thanks to immutable containers and the consistency of topology build, developers can build tests and environments that more closely resemble the non-functional aspects of the production environment. As a result, these qualities of service are built in and tested right from the start. 

## 7.1.3 Conclusion 

Containerization is not mandatory for moving to v11 of IBM App Connect. You can upgrade the runtime only. In the new version, you retain the existing Integration Node/Integration Server topology, and benefit from many fundamental enhancements. 

