Core: Automation

Infrastructure as Code - declarative, idempotent, source of truth

Miro Kosut

Miro Kosut

— 2 min read
Share

Requirement / business driver

Manage network configuration the way software is managed - versioned, reviewed, tested, and reproducible - so changes are safe and the network never drifts from intent.

The principles

  • Source of truth in Git - the repo defines desired state; devices are reconciled to it (not the other way round).
  • Declarative + idempotent - describe the end state; re-running converges, it doesn't stack changes.
  • Peer review (pull requests) - changes are reviewed before merge - the audit trail and the safety net.
  • Test before deploy - lint/validate, then test against a virtual/lab topology; drift detection flags out-of-band changes and remediates back to intent.
  • Dry-run / plan - preview the change set before applying.

Design that enables automation

The design properties that make a network good are exactly what make it automatable: standardization/templating (a "templateable" design), hierarchy (the smallest number of standard building blocks), and modularity (Network Design). Snowflake, one-off configurations resist IaC; standardized modular building blocks become reusable templates and reduce CAPEX/OPEX. Treat "is this design templateable?" as a design question, not just an operations one.

Recommendation / justification

Adopt IaC with Git as the single source of truth, declarative+idempotent definitions, mandatory review, and automated validation before deploy - feeding a pipeline (CI-CD pipelines for networks (NetDevOps)). This is the discipline that makes automation safe at scale; the tooling (Automation tooling - Ansible vs Terraform and orchestration) is secondary to the practice. Justify by change safety, auditability, and drift elimination.

What would change this (mid-scenario twist)

  • Audit/compliance pressure -> Git source of truth + review + drift detection front and centre.
  • Frequent out-of-band CLI changes causing drift -> enforce reconcile-to-intent.

Validation checks

  • Is there a single source of truth with review and automated validation before deploy?
  • Is drift detected and remediated (not just pushed once and forgotten)?

IPv6 / dual-stack note

Encode v4 and v6 in the same models/templates so both are covered by review, testing, and drift detection.

Spaced repetition

In IaC, where does desired state live and which direction does reconciliation go?

In Git (the source of truth); the network is reconciled to the repo, not the repo updated from devices.

Why does declarative + idempotent matter for IaC?

You describe the end state and re-running converges to it safely (no stacking/duplicating changes).

Drift detection's job is to [...].

Drift detection's job is to flag out-of-band changes and remediate the device back to the intended state.

Why do modular/hierarchical/standardized designs matter for automation?

Those same good-design properties make the network templateable - reusable building blocks become IaC templates - whereas snowflake one-off configs resist automation.

Sources

  • Cisco Press, Network Programmability and Automation; IaC best-practice references.

domain: Core · blueprint-ref: Core 8.2 Infrastructure as Code (when to use) · type: design-decision · status: complete · tags: [core, core/automation, tradeoff/operability, tradeoff/complexity]

Read more