content_image/1014352.jpg
<img src='content_image/1014352.jpg'>

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. 

## 7.2.7 Shared lifecycle 

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. 

