N100FN100F
Published on

Infrastructure you can rebuild

If the whole environment disappeared tomorrow, how long would it take to have it exactly as it is today? That answer measures the maturity of an infrastructure better than any other.

Service line Automation and IaC

An uncomfortable question

Imagine that tomorrow somebody deletes an entire environment by mistake: networks, servers, databases, access rules. The data is safe in its backups, but the infrastructure around it no longer exists. How long does it take to have it back exactly as it was?

In many organisations the honest answer is 'we do not know', followed by 'days, and it would not be the same'. Nobody remembers all the network rules, the sizes chosen, the adjustments made by hand over the years.

Rebuilding a lost environmentBy hand, days of steps from memory with gaps; from code, a few minutes and an identical result.IAC · REBUILDIf the environment disappears tomorrowBY HAND, FROM MEMORYNetworkRulesServersSizes?DatabaseAccess?CertificatesSettings?3 to 5 days · and the result is not the same as the originalFROM CODEClonethe repositoryPlanreview changesApplyone commandA few minutes · and it is identical, because it comes from the same descriptionTIME TO HAVE THE ENVIRONMENT BACKBy hand · ~4 daysFrom code · ~20 minutesThe question measures the maturity of the infrastructure:how long would it take to have it as it is today?Illustrative data; they do not correspond to any real caseN100F · n100f.com

Infrastructure as code

The alternative is to describe the whole infrastructure in text files: which networks exist, which servers, at what size, which rules protect them. Those files are kept in a repository, reviewed like an application's code, and a tool takes care of making reality match the description.

With that, rebuilding stops being a feat and becomes a command. And along the way you gain everything else:

  • History: every change has an author, a date and a reason.
  • Review: a network change is reviewed before being applied, just like a code change.
  • Repetition: development, acceptance and production all come from the same code, with different parameters.
  • Documentation that does not lie: the code is the description of what exists.

What this series covers

From the problem of clicks to declaring the desired state; from the infrastructure's code (its state, its modules, the plan before applying and its cost) to keeping every server as it should be and detecting when it drifts; from how to change without fear (rollback, rules as code, bringing in what you inherited) to automating daily operations. And, at the end, what is best not automated.

Let us start at the origin of the problem: clicks.

How we apply it: Automation and IaC.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk