Pipelines & Packets

I've spent most of my engineering career living inside the application stack. APIs, backends, microservices, internal developer platforms — the kind of work where a good pipeline is a point of pride and "shift left" is spoken like scripture.

Then I joined a corporate networking organisation.

And I had to quietly unlearn a few assumptions I didn't realise I'd been carrying.

The Pipeline I Thought I Knew

In the application world, CI/CD has a comfortable shape. You write code. Tests run. Something gets built. An artefact lands somewhere. A deploy happens. If you've done it long enough, you develop opinions about it — about feedback loop length, about test pyramid ratios, about whether your staging environment is actually a lie you're telling yourself.

The tooling is rich and deeply integrated into the developer experience. Hosted runners. Managed pipelines. Test frameworks across the stack. You can spin up an environment in seconds — not just for CI, but for every open pull request. Preview environments, ephemeral and disposable, each one a full-stack replica standing up on demand and tearing itself down when the branch merges. You can test a feature branch against a real database, a real message queue, a real HTTP dependency — or a mocked version of it if you're moving fast and feeling confident.

The feedback is fast. The blast radius, while not trivial, is usually bounded — and the tooling is designed to bound it further. Canary deployments that shift a small slice of traffic to the new version before committing. A/B testing baked into the release process, where "which version performs better" is a question the pipeline answers rather than a question engineering debates in a meeting. Rollbacks exist. Feature flags exist. Progressive delivery exists. You have time to breathe, and when things go wrong, you have options.

None of that quite maps onto networking.

A Different Kind of Blast Radius

In network engineering, the "environment" is not a container. It is not a cloud account you can tear down and recreate. It is, in many cases, physical infrastructure that has been running — sometimes for years — under real traffic, underpinning real business operations.

There is no "spin it up locally and test it" equivalent for a core routing layer. And from what I've observed, there's no "spin up a new version alongside the old one" equivalent for a physical access switch either. When a firmware upgrade goes out and the device reboots, the team is committed. If it comes back cleanly, great. If it doesn't — wrong config, unexpected edge case, device hanging mid-boot — remote access is gone. Someone goes to it physically. I don't fully understand yet how that scenario gets resolved on the ops side. But even imagining one of those maintenance windows — the preparation, the risk, the commitment point — makes the stakes feel real in a way that's hard to appreciate from the application world.

Testing is not impossible in the networking world — config analysis and validation tooling has made real inroads — but the model is fundamentally different. You are testing intent: does this configuration, when applied, produce the behaviour I expect? Pre-checks establish that the network's current state actually matches what your automation believes before you touch anything. Post-checks confirm the change produced the intended outcome — not just that it completed without error. A task can succeed and still leave the network in a state you didn't intend. The verification happens before, during, and after. Because after is expensive.

This flipped something in my mental model. In application CI/CD, I'd often thought of testing as a gate before production. In network automation, testing is more like proof of correctness before you touch anything. The pipeline is less "run fast and validate continuously" and more "validate exhaustively, then execute carefully."

Traffic shifting exists in networking too — routing changes, failover paths, load distribution across links — but it carries a different weight. In application deployments, gradually shifting a slice of traffic to a new version is a safety primitive, something you reach for to limit blast radius. In network automation, a routing change that moves traffic is the event. There is no partial rollout to a subset of users. When the change takes effect, it takes effect for everyone on that path.

The andon cord instinct — stop the line the moment something looks wrong — is still right in principle. But in a network change, a mid-flight halt can leave you in a partially-applied state that is harder to reason about than either completing or reverting. This is why rollback procedures are designed and tested before the change window opens, not reached for reactively. In application CI/CD, rollback is a feature you build in and pull when needed. In network automation, rollback is a planned procedure with known steps, verified in advance — because 2am with production traffic affected is not the moment to improvise.

Change Advisory Boards. Maintenance windows. Rollback procedures documented in advance. This isn't bureaucracy for its own sake — when a change can affect network reachability for thousands of users or bring down a core segment, the overhead is proportionate to the risk.

The pipeline exists. It just moves at a different cadence, and with different stakes.

What Carried Over

Not everything is foreign. The instinct to automate repetitive configuration is the same instinct I had writing deployment scripts. The frustration with undocumented tribal knowledge is the same. The desire to make infrastructure reproducible, auditable, and version-controlled — absolutely the same.

The first time I saw the code that builds the config, something clicked. It looked like infrastructure as code. The same principle that had us defining cloud resources in declarative templates — version-controlled, reviewable, a single source of truth for what the environment should look like — applied here too. Except the resource wasn't a compute instance or a load balancer. It was a routing policy. A VLAN assignment. A firewall rule. Configuration as code, not just infrastructure as code. The abstraction had moved down a layer, but the source of truth model was identical.

The parallels go further. Anyone who has worked with declarative infrastructure tooling knows drift — the moment when actual state quietly diverges from declared state. Someone made a manual change outside the pipeline. A temporary fix got applied directly and never reverted. The code says one thing; reality says another.

Network configuration drift is exactly the same problem. A device gets a manual CLI change during an incident. A workaround outlives its context. Over time, the gap between what's in version control and what's actually running widens — silently, until something breaks and nobody can quite explain why.

The answer is the same in both worlds: make the declared state the source of truth, detect drift continuously, and treat any deviation as a signal. The tooling differs. The discipline is identical.

The network-as-code movement has been making this case for years: treat network configuration like code. Use version control. Use templates. Use structured data. Don't rely on a single engineer who knows the right CLI incantation by heart.

That resonates with me deeply. The difference is just the material. Configuration playbooks instead of package manifests. Network data models instead of API schemas. Inventory files instead of service registries.

The principles hold. The implementations diverge.

Still Calibrating

I'm early in this context. There are things I reach for that don't exist yet — fast feedback loops, ephemeral test environments, the confidence to merge without a maintenance window — and things that exist here that I don't yet fully understand.

What I'm finding is that the gap between application CI/CD and network automation isn't really a gap in maturity. It's a gap in assumptions about the system you're operating on. Application pipelines assume your environment is ephemeral and reproducible. Network automation assumes your environment is stateful, persistent, and consequential.

Neither is wrong. They're just different problems wearing similar names.