Question
What does "infrastructure automation" mean, and what are the two ways a platform can be automated?
Answer
Using code to configure, provision and manage applications together with the compute, storage and network they run on, either through automation tools (Ansible, Puppet, Chef) or by calling the platform's API directly.
The key word is code. Instead of an admin clicking through consoles or typing commands device by device, the desired setup is written down in a form a machine can execute, so it can be repeated, reviewed and versioned.
The scope covers the whole stack, not just servers:
- the applications themselves,
- the compute, storage and network infrastructure under them,
- the network services (DNS, load balancing, firewalls) that connect them.
A platform can be reached in two ways:
- Through a configuration-management tool such as Ansible, Puppet or Chef. The tool knows how to talk to many platforms and gives you one language for all of them.
- Through a direct API on programmable infrastructure. The device or cloud exposes a REST (or similar) interface, and your own script calls it.
The tools usually sit on top of those same APIs, so the choice is between convenience and uniformity on one side and full control on the other.
Go deeper:
Infrastructure as code — Wikipedia — declarative vs imperative approaches and the main tools side by side.- Configuration management — Wikipedia — the discipline that Ansible, Puppet and Chef automate.
Note saved — thanks!
Question
What are the three stages of the Walk-Run-Fly automation progression?
Answer
- Walk: read-only automation (collect and check configuration).
- Run: write changes through policies and self-service.
- Fly: deploy apps, infrastructure and network config through CI/CD, steered by telemetry.
* Each stage adds write power, and so risk; trust earned in one stage unlocks the next. *
The progression (from Cisco's DevNet Automation Exchange) describes how an organisation grows into automation safely, each stage building trust for the next:
| Stage | What the automation does | Typical use |
|---|---|---|
| Walk | Only reads: gathers configuration and state from devices | Audit configs, detect drift, find what is out of compliance |
| Run | Writes, but within guard rails: policies and self-service across domains | Users safely roll out their own infrastructure and network updates, onboarding workflows, daily config changes |
| Fly | Full pipeline: apps, infrastructure and network config deployed through CI/CD | Proactive management of users and devices, insights from telemetry |
Read-only comes first because it cannot break anything, yet it already pays off: once you can see that a config deviates from the standard, the next logical step is to bring it back in line, which is where Run begins.
Tip: You walk before you run, and you run before you fly. Each stage adds risk, so each needs the confidence earned in the one before.
Go deeper:
Cisco DevNet Automation Exchange — the catalogue of walk/run/fly automation solutions the progression comes from.
Note saved — thanks!