GLYPH<SM590000> Isolation : Any changes that affect the running server, whether fix pack upgrades, introduction of new integrations, changes to existing integrations, or configuration changes to the server, carry risk as they affect all integrations that run on the shared servers. We must either carry that risk or mitigate it with potentially significant amounts of regression testing across our integrations. 

GLYPH<SM590000> Scalability : The topology can be extended only through manual configuration. More CPU could be added to server HA1 and HA2. But it would likely still require careful scheduling, and there is clearly a physical limit to the amount of CPU that can be added. Adding a “server HA3” would typically be a manual exer cise, as would removing it when the extra load is no longer present. 

GLYPH<SM590000> High availability : There is a significant amount of the topology to be built beyond that of the installation of runtimes and much of this relates to high availability. Consider how much of the preceding diagram is dark blue (labeled “Product component” in the key), which means it needs to be explicitly installed and configured. This includes setting up of load-balancing within and across nodes, enabling high availability and disaster recovery. 

This must be repeated for each environment such as development, test, production. Significant custom work to create each environment. But also, there is also a genuine risk that configurations in each environment become out of synch. Certainly, there are ways to automate and patternize installations, but this in itself is additional work. 

It is worth recognizing that even with this traditional topology it is possible to make some moves towards the benefits of agile integration. For example, it is already possible to split a large installation into a number of separate Integration Servers, each containing a subset of the integrations and administered via a single Integration Node. Many large installations are likely to be already using this method of grouping. This provides some level of isolation between sets of integrations, but not the deep decoupling that would be offered by containers described later in Path B. They also enable some degree of independent scaling of integrations, but not to the extent of automatically and elastically provisioning new hardware resources that you would get in a container orchestration framework. 

Perhaps the most striking point is that in this traditional installation, administration and deployment all require specialist skills. Container-based environments aim to standardize those skills and make those skills transferable across technologies such that the only specialist skill required, is the one that matters: how to build artifacts . In our case that would mean the building of integration flows. Everything else should be done by using common tools and capabilities that are common across all the technologies. 

We now look at the cloud-native path. And we take a deeper look at what benefits a more fine-grained deployment on containers might bring if we adhere to a true cloud-native deployment style. 

## Path B: Cloud-native deployment (including runtime upgrade) 

On this path, we switch completely to a container platform, but more than that, we embrace true cloud-native style with associated benefits. Figure 7-4 on page 439 is a simplistic example of the key elements of a cloud-native topology: 

