Immutable infrastructure

The general concept of immutable infrastructure is that there is only one way to introduce change into a system, and that way is to destroy and recreate that system. The main benefit of this approach is that changes are introduced in a very controlled way, minimizing drifts and misconfiguration. Also, having a single method for introducing change allows more focus on automation and optimization. Infrastructure as code is a common approach used to achieve immutable infrastructure (this topic is out of scope for this document).

Systems and infrastructure can be rapidly destroyed and recreated. Therefore, immutability should not be interpreted as rigidity, but rather as a very prescriptive rule about how change can be introduced. For the lifetime of a given instance of a system, it is immutable.

The concept of immutable infrastructure can be applied to container-based solutions and deployment pipelines with the idea of progressively locking the infrastructure:

Pieces of the infrastructure are locked down in different phases and each infrastructure piece becomes immutable after being locked down.

The Code Build phase locks the business logic. This is about creating a deployable artifact starting from our code. We have always done this step.

The Image Build phase locks the binary execution environment and creates a container image. After the container image is created, the business logic can be executed anywhere with no drift (for binaries and other runtime dependencies).

The Topology Definition phase locks the topology of the solution. Assuming the deployment involves a solution comprised of several components, this phase creates and locks the topology that describes which components must be deployed and their dependencies. The declarative API is leveraged to create a manifest of the compute, networking, and storage resources that are needed.

Notice that we have already locked down most of the infrastructure and we haven’t deployed anything yet.

The last phase performs the deployment to an environment. During deployment, environment-dependent properties are injected, including public properties as well as confidential credentials.

To comply with the principle of immutable infrastructure after deployment, the only way to introduce a new change in the environment is to repeat the previous processes. This is true regardless of the nature of the change that we want to introduce, which might include:

Code release

Runtime updates

Security Patches

Configuration changes

In traditional environments, the last three items are usually the responsibility of the operations team, and the developer team is not necessarily involved when they are performed. With immutable infrastructure and containers, deployment processes need to be radically rethought and need to involve the developer teams.

The phases of the progressing locking process that we have described can implement in a CI/CD pipeline. The following sections discuss the types of pipelines and the types of steps that are part of a pipeline.