7.2.7 Shared lifecycle Figure 7-15 Zones It certainly makes sense to isolate those integrations that have significantly higher availability  requirements such that they can have a separate replication policy. However, we should  recognize that there are diminishing returns on grouping too many integrations together in  this situation. Let’s consider th at each integration has some probability that it could cause an  outage of the whole container and all the integrations within it. The overall probability of an  outage is then potentially greater than the integrations would have faced if they were deployed  on their own. The more integrations in the group, the worse the availability. Ultimately for very  specific high-availability requirements, a separate runtime (and therefore container, and  indeed pod) for each integration is probably required. Do we have a set of integrations that always get maintained together, and released into  production in synchronization with one another? These might be a good candidate to be  grouped together in the same container. This might indeed make ensuring a consistent  release across the set easier. Often, this can occur where integrations use shared data models (Figure 7-16). By this we  mean that they all use a single data model that must remain in step across these integrations.  This sometimes happens because of data model that implements a particular versioned  industry standard. Integrations that are locked in step on the same data model often have the  same release cycle for major changes that accompany changes to the underlying data model  version.  Chapter 7. Field notes on modernization for application integration  449