The idea
Setting up IT infrastructure by hand usually means logging in somewhere and clicking: create a server, attach storage, open a port, add a network. It works, but it leaves no record of exactly what was done, and the next person who builds a similar environment will do it slightly differently.
Infrastructure as code (often shortened to IaC) takes a different approach. Instead of performing the steps yourself, you write a description of what you want in a text file. A tool reads the file and makes the real world match it. The servers, networks, storage and permissions are all created from the written definition.
The word “code” can sound intimidating. In practice many of these files look more like structured lists of settings than like programs. You can often read one and understand what it builds without being a programmer.
A simple analogy
Think of a recipe versus cooking from memory. If you cook from memory, the result varies, and if someone else wants the same dish, they must ask you. If you write the recipe down, anyone can follow it and get a similar result, you can adjust it deliberately, and you can see how it has changed over time.
Infrastructure as code is the written recipe for your systems. And like a recipe, it can be shared, reviewed and improved.
Declarative and step-by-step styles
There are two broad ways to write definitions.
Declarative. You describe the end result: “there should be two servers of this size, on this network, with this port open.” The tool compares that with what currently exists and works out what to create, change or remove. Most popular tools lean this way.
Procedural or imperative. You list the steps to perform in order: “create a network, then create a server, then attach it.” This gives fine control but puts more burden on you to handle the case where something already exists.
Declarative definitions have a handy property: you can run them again and again. If everything already matches, nothing changes. This is closely related to the desired-state idea in configuration management.
What is gained
Repeatability. The same definition can create the same environment many times. A team can build a test environment that matches production closely, and a new region or customer environment becomes a matter of running the definition again.
Speed. Once written, an environment can be created in minutes instead of days of manual setup, although the actual time depends on the services involved.
A written record. The files document how the system is built. You do not need to rely on someone’s memory or an out-of-date diagram.
Review and history. Because the files live in version control, changes can be reviewed before they are applied and compared afterward. If something breaks, you can look at what changed recently.
Easier recovery. If an environment is lost, the definition makes it far quicker to rebuild. This supports a disaster recovery plan, although the data itself still needs a sound backup strategy, since code can recreate empty servers but not the information that was on them.
Less drift. When all changes go through the definition, systems do not slowly diverge through unrecorded manual tweaks.
Where it is commonly used
IaC is especially common with cloud computing, where infrastructure is created through programming interfaces and can be requested on demand. If you are unfamiliar with that setting, cloud computing basics are a helpful background, and the way different cloud service models divide responsibility affects what you would actually write in a definition. The approach also works for virtual machines, networks, firewall rules, storage, user accounts and permissions, and for on-premises systems that have suitable interfaces.
Typical workflow
- Write or change the definition in a file.
- Have a teammate review the change.
- Run a preview, which shows what the tool would create, change or destroy without doing it.
- Read the preview carefully.
- Apply the change.
- Check that the result is what you expected.
Step 4 deserves emphasis. A preview that shows an important database being destroyed and recreated is exactly the kind of thing you want to notice before it happens.
Things to be careful about
Tracking state. Many tools keep a record of what they have created so they can compare it with the definition. That record can contain sensitive information, and it needs to be stored securely, backed up and protected against two people changing it at once.
Secrets. Passwords and keys should not be written directly into definition files, especially if the files are shared widely. Use the secret storage features available in your environment.
Powerful credentials. The account that applies changes often has broad permissions. Limit it as far as practical, in line with least privilege, and protect it with multi-factor authentication where it is used by people.
Accidental destruction. A small edit can cause a resource to be replaced instead of updated. Reading previews, keeping environments separate and using protections for critical resources all help.
Manual changes outside the code. If people continue to change things through consoles, the definition and the real system fall out of step. Agree that changes go through the files, and have a process for emergencies.
Cost. Because environments are easy to create, they are also easy to forget. Unused resources keep accruing cloud costs, so tag them, set expiry dates where possible and clean up regularly.
Where to begin
You do not need to convert everything at once. A reasonable start is to choose one small, self-contained piece, such as a test network or a single server, and define it in a file. Learn the preview and apply workflow with something low-risk. A home lab is a good place to practice without any consequences for real users.
Over time, bring in more of the environment, add review for changes and consider automated checks that test definitions before they are applied. The aim is not to write more files for their own sake, but to make your systems understandable and reproducible.