Breaking up an ESB into more modular fine-grained integration components might seem like it adds more complexity to your infrastructure. You can now see that much of the creation and management of these discrete topologies for each integration is done for us by K8s, so it no longer seems so daunting. Furthermore, adopting container orchestration reduces the deployment and administration skills operational teams need because they largely are consistent across any solution that sits on a container-based platform. This operational consistency  becomes all more important in the decentralized ownership of integration. 

## 3.2.7 Lightweight run times: How the modern integration run time has changed 

K8s can perform deployments, create resilient topologies, self-heal, and scale elastically, but your runtimes must be lightweight, that is, they ideally must be a single process that pulls everything it needs from the file system on start and requires no further online configuration. 

For this reason, integration run times have evolved in recent years. Let’s have look at some of the key improvements that enable the characteristics we discussed: 

GLYPH<SM590000> Rapid start-up: The run times are a single process that runs in containers such as Docker. They are lightweight enough that they can be started and stopped in seconds, and can be easily administered by orchestration frameworks such as K8s. 

GLYPH<SM590000> Dependency free :  The run times no longer have hard dependencies on databases or message queues that must be installed alongside them, although they are still adept at connecting to them remotely. 

GLYPH<SM590000> File system installation, configuration, and deployment: The run times can be installed and configured by laying their binary and configuration files on a file system and starting them. Furthermore, there is no longer a need to deploy integrations to a live running integration server. The integrations artifacts (maps, flows, configuration, and others) can be laid down on the file system. This situation is ideal for the layered file systems of Docker images and the automated pipelines that are essential for CI/CD. 

For more information, see 5.5, “Application integration: IBM App Connect” on page 155. 

Now, we continue with a few more cloud-native characteristics and see how they are handled by modern integration run times. 

## 3.2.8 Log-based monitoring 

You should not be connecting dire ctly to individual containers , so monitoring cannot be done by direct connection. Instead, the integration run times are enabled to report their status by using standardized logging, which can then be aggregated by a monitoring stack on the container. 

## 3.2.9 API intra-application communication 

Cloud-native components should communicate by using runtime-neutral protocols, the most common of which is RESTful APIs. Exposing and calling APIs is part of an integration’s basic function. 

