Hello – why aren't you getting started with network automation?
Network automation should be standard by now. Yet, many are lagging. Here's the architecture we build upon – and why it works.

Why hasn't network automation become standard? Year after year, voices emphasize its importance, but many are still behind. It's time to do something about it.
An architecture in six blocks
We divide an automation solution into six distinct blocks, each with clear objectives:
- Source of Truth – CMDB / IPAM.
- Orchestration – NSO, Ansible, Terraform.
- Device abstraction – drivers for actual equipment.
- Service model – what needs to be delivered?
- API layer – how does one order?
- Observability – do you know if it works?
Modular design means you can start with two or three blocks and grow from there.
Overcome initial resistance
- Choose a service you frequently perform manually.
- Automate the entire flow – not just half.
- Measure lead time before and after.
The hardest part is starting. The rest is iteration.

Network automation, Cisco NSO or monitoring? I'll connect you with our network specialists.
Related articles

Mapping 120,000 devices: how we built a network discovery platform that keeps up
How we built a network discovery platform tracking over 120,000 devices: DNS zone transfers, Temporal, SNMP templates, MongoDB, topology from MAC tables, Jaeger, and a versioned FastAPI.

From Git to VM – how we build self-service with Proxmox and Crossplane
Proxmox, Crossplane and GitOps as the foundation for self-service on your own infrastructure. Read about Petter's PoC, what works today and the next steps.

Building a Kubernetes Platform Without Vendor Lock-In
How do you build a container platform that can evolve over time? Brian Levinsen discusses solution design, OpenShift, GitOps, and minimizing vendor dependencies.


