The difficulty in sharing my automation
Hidden assumptions, and no owner.
autocon6-naf-framework-do-over.automate-the.net · AutoCon 6
A Network Automation Do-Over with the NAF Framework
Let's rewind. Four of my early automation projects, looked at again through the lens of the NAF Framework: what I used, what I skipped, and what I would do differently.
Claudia de Luna · Scroll to begin · Press → to begin
The NAF Framework
Network Automation 2.0
Let's rewind
Why a do-over?
First-generation automation is shaped by the task, the devices, and the tools I knew at the time. That is not a failure, but it turns into operational debt.
First-generation automationSolves the problem in front of you. Shaped by the task, the devices and the time.
Good automationCan be consumed and shared easily, is easier to maintain and improve, and builds a base for re-use and new capabilities.
Why a do-over?
Could I have avoided
The level of effort in maintenance
No tests, no data model, credentials in code.
Confusing state and intent
What the network is, mixed up with what I want it to be.
Manual and clumsy handoffs
Every manual step becomes technical debt, friction, and/or risk.
As I look back
The world with the NAF Framework
Through the lens of the NAF Framework
Four early automation projects
What did I use?
Which building blocks were there, even if I never named them.
What did I skip?
Which building blocks were missing.
What would have been different?
How I would have done it then, with the framework in hand. Not how I would do it now.
What technical debt did I introduce?
What it cost later.
01
Chapter 01 · Wrong! We needed network state (actually Observability)
Project 1: Pull show commands
01.A
The project
Python, a text file of IPs and FQDNs, and raw ("semi-structured") text output.
01.B
What got used (but not named)
Used: Collector/Executor. Skipped: everything else.
01.C
What got skipped
Presentation, Intent, Orchestration and Observability.
01.D
The do-over
Parsed and normalized data, a front end, intent by vendor and OS, a real inventory, and a schedule.
01.E
Technical debt
Assume every manual step you execute will become technical debt, friction, and/or risk.
02
Chapter 02 · Merge current state, new template & exceptions into a new device configuration
Project 2: New brownfield configs
02.A
The project
Python and Jinja2, a spreadsheet as the data model, and parsed current configuration.
02.B
What got used
Used: Intent, Executor. Skipped: everything else.
02.C
What got skipped
Presentation (again), Observability, part of Intent, and Orchestration.
02.D
The do-over
Intent that is not a spreadsheet, a front end, and orchestration with testing, triggers and file logistics.
02.E
Technical debt
Intent in state, in code and in a spreadsheet, with no revision control. Don't underestimate file logistics.
03
Chapter 03 · Cabling check, most recent configuration, endpoint survival and identification
Project 3: Pre/post refresh QA
03.A
The project
Project 1 snapshots, parsed to JSON, with a TUI.
03.B
What got used
Intent (disguised as Observability), Collector, Orchestrator and Presentation.
03.C
What got skipped
Executor, Intent and Observability.
03.D
The do-over
Intent separated from state, with programmatic access and a change and transaction log.
03.E
Technical debt
Poor traceability and logging, local output, and a task where we needed a workflow.
04
Chapter 04 · User self-service, on-demand M/A/C
Project 4: User self-service
04.A
The project
A GUI with AAA, observability, a network configuration tool, an intent system, automated change requests and transaction logs.
04.B
What got used
Used: everything.
04.C
What got skipped
<Intentionally left blank>
04.D
The do-over
The client would have rolled it out globally.
04.E
Technical debt
We won't find out.
The building blocks
The NAF Framework
Your turn
What's next
What is your "Do Over"?
Understand your scale
How much more than 1?
Don't overthink it
Knowing which questions to ask is the goal, not enterprise-scale everything.
How will you…
Essential framework questions
Presentation
How will users access your automation?
Intent
How will you define intent?
Observability
How will you track network state over time?
Collector
How will you collect network data?
Executor
How will you execute commands and changes?
Orchestration
How will you orchestrate workflow tasks?
Keep going
Resources
01
This presentation
02
NAF reference docs
The NAF Framework: tinyurl.com/naffdoc
03
NAF Framework deep dive
Christian Adell & Damien Garros, AutoCon 5: tinyurl.com/naffdeepdive
04
Design Solution Wizard
05
Join the Slack channel
#wg-network-automation-framework
Questions?
This presentation
autocon6-naf-framework-do-over.automate-the.net NAF reference docs
tinyurl.com/naffdoc Enterprise Infrastructure Acceleration
eianow.com
autocon6-naf-framework-do-over.automate-the.net NAF reference docs
tinyurl.com/naffdoc Enterprise Infrastructure Acceleration
eianow.com
With gratitude
Thank you
This talk would not be what it is without the people who helped me get it to the stage.
01
The NAF team
For the public speaking and presentation coaching, and for building the framework this talk stands on.
02
Dan Farley
For the public speaking and presentation coaching. Practical Development Solutions: practicaldev.com
Chapter 01 · 01.A
The project
We set out to pull show commands. Wrong! We needed network state, which is actually Observability.
Solution
- Python
- Text file of IPs, FQDNs
- Raw ("semi-structured") text output
- Parsing (at a later time)
Tags
- Python
- Show commands
Chapter 01 · 01.B
What got used (but not named)
Collection and execution were there, without the names.
Used
- Collector/Executor
Skipped
- Everything else
CollectorThe show commands.
Tags
- Collector
- Executor
Chapter 01 · 01.C
What got skipped
Presentation
- Who, how, should
Intent
- Devices & commands
Orchestration
- Incomplete output
- Failed connections
Observability
- Collection is not observability
Collection is not observabilityAsk what happens to the data after it is collected. Treat the output as data to keep, not text to read.
Tags
- Presentation
- Intent
- Orchestration
- Observability
Chapter 01 · 01.D
The do-over
Collector
- Parsed and normalized data
Presentation
- GUI
- API
- Authentication/Authorization
Intent
- Commands (by vendor/OS)
- Inventory
Executor
- cron
IntentAsk where the inventory lives and who owns it.
Tags
- What would be different
Chapter 01 · 01.E
Technical debt
In my eagerness to get something working, a hand-maintained inventory file; credentials in or near the code; unstructured output that needed new regex for every new question; silent failures; no history.
Operational environment
- Virtual environment
Inventory
- Continual & manual true up
- No change tracking
LessonAssume every manual step you execute will become technical debt, friction, and/or risk.
Tags
- Technical debt
Chapter 02 · 02.A
The project
Goal
- Merge current state, new template & exceptions into a new device configuration
Solution
- Python & Jinja2
- Spreadsheet (data model)
- Parsed current configuration/show commands
- New config text output and alert reminders
Tags
- Python
- Jinja2
Chapter 02 · 02.B
What got used
Used
- Intent
- Executor
Skipped
- Everything else
IntentA spreadsheet, standing in for a data model.
Tags
- Intent
- Executor
Chapter 02 · 02.C
What got skipped
Presentation (again)
Observability
- Part of Intent in this scenario
Orchestration
- What is an Event?
- Validation
What was missingA real Intent model with validation; a defined Executor step; Observability to confirm what was applied; version control as a dependency.
Tags
- Presentation
- Observability
- Intent
- Orchestration
Chapter 02 · 02.D
The do-over
Define the data model before the template. Separate generating a config from deploying it. Ask how I would know the result matched the intent.
Intent
- Not a spreadsheet
Presentation
- GUI
- Usage (1 … all)
Orchestration
- Testing
- Trigger
- File logistics
Tags
- What would be different
Chapter 02 · 02.E
Technical debt
Why did a value change in Excel? Why did it come out that way in the config? I missed that every step of the way.
Intent
- Intent in state
- Intent in code
- Intent in a spreadsheet
Revision control
- Log of decisions
- Partial testing
- Transferring files
LessonDon't underestimate file logistics. Versioned intent vs state: separate what I want from how a platform expresses it.
Tags
- Technical debt
Chapter 03 · 03.A
The project
Goal
- Cabling check
- Most recent configuration
- Endpoint survival and identification
Solution
- Project 1 snapshots
- Parsing to JSON
- TUI
Tags
- Snapshots
- JSON
- TUI
Chapter 03 · 03.B
What got used
Collector (the show commands); rough Observability (before-and-after snapshots); rough Presentation (the TUI).
Used
- Intent (disguised as Observability)
- Collector
- Orchestrator
- Presentation
PresentationA TUI.
Tags
- Intent
- Collector
- Orchestrator
- Presentation
Chapter 03 · 03.C
What got skipped
A real Intent model; full Observability; an Orchestrator to sequence capture, wait for convergence, and compare; a proper report as the Presentation layer.
Skipped
- Executor: we pushed the fixes by hand
- Intent
- Observability
LessonDon't obfuscate your system of record.
Tags
- Executor
- Intent
- Observability
Chapter 03 · 03.D
The do-over
Treat the expected state as data. Make the output a report.
Intent
- Separated state from intent
- Provide programmatic access
- Change and transaction log
Tags
- What would be different
Chapter 03 · 03.E
Technical debt
Did we fix it? We needed a report non-engineers could read.
Technical debt
- Poor traceability and logging
- Local output
- Task vs workflow
LessonObservability vs Intent.
Tags
- Technical debt
Chapter 04 · 04.A
The project
Goal
- User self-service, on-demand M/A/C
Solution
- GUI + AAA
- Observability
- Network configuration tool
- Intent system
- Automated change request
- Transaction logs
Tags
- Self-service
- M/A/C
Chapter 04 · 04.B
What got used
Used
- Presentation
- Intent
- Observability
- Orchestration
- Collector
- Executor
UsedEverything.
Tags
- All six building blocks
Chapter 04 · 04.C
What got skipped
<Intentionally left blank>
Tags
- Nothing
Chapter 04 · 04.D
The do-over
The client would have rolled it out globally.
Tags
- What would be different
Chapter 04 · 04.E
Technical debt
We won't find out. One gap: no administrative capability to search and analyze logs for changes.
Tags
- Technical debt