Infrastructure Architecture: Containers Creating Fourth Plane

But there's another kind of orchestration at work that's under the hood and largely unseen by operators. It has nothing to do with management except that it's appropriating some responsibilities from human operators.

The distinction here is that the actions are triggered automatically by changes to the environment during execution rather than as a deployment event. But the information about what has changed is vital, and that means it has to be obtained somewhere.

In a traditional operational model that information usually comes from change tickets or requests. In the case of modern operational models and, specifically, containers this information comes from service registries via a discovery mechanism.

Service Registries and Discovery

The nature of container environments includes the assumption that IP addresses effectively don't matter to the application environment. But they do matter to infrastructure because data still has to be routed and forwarded from device to device in order to traverse the path between the client and the application. In modern environments, those IP addresses often exist for short periods of time (the lifetime of a container/service).

Consider these findings from DataDog (emphasis added):

The rapid adoption of orchestrators (see fact 4) appears to be driving containers toward even shorter lifetimes, as the automated starting and stopping of containers leads to a higher churn rate. In organizations running an orchestrator, the typical lifetime of a container is about 12 hours. At organizations without orchestration, the average container lives for six days.

_{From <https://www.datadoghq.com/docker-adoption>}

Imagine if you, as an operator, had to update the routing tables or load balancing pools every six days, let alone every twelve hours. You would do little else. The potential for misconfiguration would be significant and likely grow the longer you were forced to operate in manual mode to manage the changes in a container cluster.

A service registry - like Consul - becomes a critical component of your container deployment. Service registries keep track of instances and services and their associated IP addresses. In this respect, they can be likened to a 'DNS for containers and services'.

So the service registry tracks the current characteristics of containers in the cluster. Discovery is the process of connecting to the service registry (via API or by subscribing to a message queue) of matching instances to IP addresses.

This means that for infrastructure that needs to route traffic to a specific service or instance inside a container cluster, it must be able to retrieve an IP address. Because as much as containers hide the network from the application, they still rely on it to get data from one place to another.

The Fourth Plane: Orchestration

What that does is introduce a new architectural layer into infrastructure that interacts with container orchestration environments. This layer - the orchestration layer - integrates with the container environment and makes use of capabilities like service discovery to automate the discovery of services and instances. That means that a load balancer can automatically discover the members of a pool and continuously update it based on changes in the environment. This alleviates the burden on operations to update load balancing pools manually - and increasingly tedious task when containers are living on average less than one week.