A few years ago, I wrote about common objections to infrastructure-as-code (IaC) and how stability comes from making changes. If your leadership is no

Principles and patterns - A tale of infrastructure as code

submited by

Style Pass

2022-05-13 02:30:02

A few years ago, I wrote about common objections to infrastructure-as-code (IaC) and how stability comes from making changes. If your leadership is now convinced to adopt IaC, how do you implement this in your organization? In the second part of the IaC blog series, I will discuss the principles and patterns of IaC. For reference, the following table lists things found on a server:

The first principle is that systems can be easily reproduced. Your IaC tooling/scripts should handle the build/rebuild of systems, and your engineers should not waste time arguing about how to choose a hostname.

The next principle states systems are disposable which is related to the common expression cattles, not pets. In large-scale cloud infrastructure, the failure of underlying hardware is not a matter of if but when. Software should continue running even if some of the underlying hardware is modified. Service continuity in the cloud era depends on embracing disposable infrastructure.

In order to trust your automation, the third principle is systems are consistent. If your test environment and the production environment differ (in terms of vCPU, memory, or network performance), you cannot predict the reliability of your applications. Inconsistent infrastructure leads to configuration drift and vice versa.