N100FN100F
Published on

What you inherited comes in too

Almost nobody starts from scratch. There are years of hand-built infrastructure that also has to come into the code. It is not done in one go and nothing is rebuilt: it is brought in piece by piece, starting with whatever carries the most risk.

Service line Automation and IaC

The elephant in the console

Reading about infrastructure as code from scratch is easy. Reality is different: an environment with hundreds of resources created over years, by hand, by people who are no longer around. Rewriting it all at once is unworkable; leaving it out means the most critical part will never get the benefits of code.

Bring in, do not rebuild

Bringing it in, in wavesThe percentage of infrastructure managed as code over ten months, in waves, up to 87%.IAC · WHAT YOU INHERITEDBringing it in, in waves0%25%50%75%100%month 0month 2month 4month 6month 8month 10Network and identitiesDataCompute87 %The rule of importing: after importing, the plan comes out empty.What stays out (13%) is identified: it is retired or has an exception.Illustrative data; they do not correspond to any real caseN100F · n100f.com

Most tools allow existing resources to be imported: you write the code describing a resource that already exists and tell the tool 'this one here is that one there'. Without destroying or recreating anything.

The work is organised in waves:

  1. Inventory first. Know what actually exists, as in before fixing, know what is there.
  2. Start with the highest risk and the least change: network, identities and access. Mistakes there are serious and these resources change rarely, so the code stays stable.
  3. Carry on with the data: databases and storage, taking great care not to trigger recreations.
  4. Finish with compute, which changes most and is the easiest to replace with new versions created from code in the first place.

The golden rule of importing

After importing a resource, the plan has to come out empty. If the plan proposes changes, the code does not faithfully describe what exists and applying it would modify something that works. You adjust the code until the plan has nothing to do, and only then is it considered brought in.

What stays out

Not everything deserves to come in. Resources about to be retired, or unused experiments, are documented as exceptions and deleted rather than imported. The goal is not 100%, but that what matters is in code and the rest is identified.

With the infrastructure in code, the natural next step is for daily operations to stop depending on somebody remembering the steps too.

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