Why the Network Is Now a Developer Concern

For most of software history, developers treated the network as a black box: packets went in, packets came out, and nobody wrote code to control what happened in between. That assumption no longer holds. Software-Defined Networking (SDN), Network Functions Virtualization (NFV), virtual appliances, and a growing catalog of REST APIs have made network configuration, policy, and monitoring as programmable as any other piece of infrastructure. At the same time, the DevOps movement has taught teams that infrastructure should be described in code, stored in version control, and deployed through automated pipelines. Those two trends are converging, and Cisco DevNet is one of the most visible attempts to build the bridge.

What Is Cisco DevNet?

Cisco DevNet (developer.cisco.com) is Cisco’s developer program and community, founded by Susie Wee. It targets three overlapping audiences:

• Application developers who need to understand how the network affects their cloud-native workloads.
• DevOps and infrastructure engineers who automate compute and are starting to automate the network layer as well.
• Network engineers (from CCNA associate level to CCIE expert level) who need to add software development skills to their existing networking expertise.

The platform provides free learning labs, Python and API tutorials, sandbox environments with access to real Cisco hardware, a code exchange backed by GitHub, and CI/CD integration guidance — all under one roof.

The Skill Gap: Network Engineers Learning to Code

The traditional network engineer skill set — deep protocol knowledge, hardware configuration, fault isolation — is still essential. But as Wee explains, it is no longer sufficient on its own:

“We’ve been really driving that whole portfolio of networking to not only be software and hardware, but to have both. The fact that the network has APIs, the fact that the network is programmable, means that there’s a fundamentally different way to leverage the network.”

— Susie Wee, Founder, SVP & CTO, Cisco DevNet

DevNet’s recommended starting point for network engineers is Python, chosen for its readability and its wide adoption in infrastructure tooling. Beyond the language itself, DevNet pushes engineers toward the standard toolchain that software teams already use:

• GitHub — not just for code, but for storing, versioning, and auditing network configurations.
• Postman — for exploring and testing REST APIs against Cisco controllers and devices.
• Ansible — for writing playbooks that enforce configuration standards across a fleet of devices.
• CI/CD pipelines — for automatically validating network changes before they reach production.

The insight here is practical: a network engineer who stores router configs in a Git repository and runs automated compliance checks via Ansible is already doing NetDevOps, even before touching a single line of Python that calls a network API.

The DevNet Sandbox: Hands-On Practice Without Physical Hardware

One persistent barrier to learning network automation is access to equipment. Lab kits are expensive, and production networks cannot be used for experimentation. The DevNet Sandbox solves this by letting registered users reserve time on real Cisco routers, switches, security appliances, and collaboration products hosted in Cisco’s labs. Engineers can write and test automation scripts against live hardware without any capital investment or risk to their employer’s infrastructure.

Automation Exchange: A Community Code Repository for Network Use Cases

Learning to code and having access to APIs are necessary steps, but they don’t immediately tell a network engineer what to automate first. To address this, Cisco announced the DevNet Automation Exchange at Cisco Live (June 2019). The Exchange is a curated collection of GitHub repositories — seeded with around 50 automation use cases at launch — organized around real operational problems: configuration auditing, SSID management, security policy enforcement, and application deployment.

Community members are invited to submit their own automation code, creating a shared library that grows alongside the industry’s experience with programmable networking.

A Framework for Getting Started: Walk, Run, Fly

Wee describes a practical three-stage model for adopting network automation in a live environment:

Walk — Read-Only Visibility

Start by using automation to observe the network without making changes. Examples include pulling device configurations into a Git repository for version tracking, running Ansible playbooks that compare running configs against a known-good golden template, and generating alerts when drift is detected. This stage builds confidence and familiarity with the toolchain without any risk of outage.

Run — Controlled Configuration Pushes

Once the team is comfortable reading from the network, they can begin writing to it in controlled, well-tested ways. Examples include automating guest Wi-Fi SSID lifecycle management (creating, resetting credentials, and shutting down SSIDs across many sites) or pushing standardized ACL updates through a tested playbook.

Fly — Full DevOps Workflow Integration

The mature state integrates network changes into the same CI/CD pipeline that deploys applications. An example Wee describes: deploying a new internal application that must access a financial database. The pipeline can automatically segment the network with VLANs, apply access-control policies, and wire up the application-centric infrastructure (Cisco ACI) to enforce that only authorized users and devices reach the new service — all without manual CLI work on individual devices.

The Cisco DevNet Certification

To validate these new skills, Cisco announced the DevNet certification track at Cisco Live in June 2019. The track runs parallel to the traditional Cisco networking certifications (CCNA, CCNP, CCIE) with a deliberate skill weighting:

The DevNet Associate certification covers topics such as consuming REST APIs, handling authentication and authorization securely, using Python for automation, and working with common developer tools. The Professional level goes deeper into automation architecture and software design. An Expert level was described as planned for future announcement at the time of this recording.

The 20% networking content in the DevNet track is intentional: it gives software engineers enough networking fluency to collaborate effectively with network operations teams without requiring them to pursue a full CCIE path.

Details and exam blueprints are available at developer.cisco.com/certification.

What This Means for DevOps and DevSecOps Engineers

Developers working in cloud-native environments — Kubernetes, microservices, containers — often assume the network is someone else’s problem. Wee argues the opposite: programmable networking is an underutilized capability that strengthens both security and reliability for cloud workloads.

Specifically, DevOps engineers can use network APIs to:

• Enforce network-layer access control in addition to application-layer controls, creating defence-in-depth.
• Define policy-based segmentation that automatically restricts which users and devices can reach which services.
• Automate virtual firewall and load balancer provisioning using the same Terraform or Ansible workflows used for compute infrastructure.
• Integrate network compliance checks into CI/CD pipelines so that infrastructure drift is caught before deployment rather than during an incident.

Software engineers already familiar with infrastructure-as-code, GitOps, and automated testing have a significant head start: the concepts transfer directly; only the API endpoints and domain vocabulary are new.

Getting Started

• Explore the platform: developer.cisco.com
• Beginner entry point: developer.cisco.com/startnow
• DevNet certifications: developer.cisco.com/certification
• Sandbox environments: developer.cisco.com/site/sandbox
• Automation Exchange: developer.cisco.com/network-automation

Full Transcript

Mitch Ashley: Hi, everyone. This is Mitch Ashley with DevOps.com, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Susie Wee, founder, SVP and CTO of Cisco DevNet. Our topic today is a really interesting one — DevOps within a programmable network. Now that we can program the network, what does that mean to the DevOps world? Susie, welcome to DevOps Chat.

Susie Wee: Hey there, Mitch, it’s great to be here. Thanks for having me.

Ashley: Would you start out and introduce yourself to our audience — tell us a little bit about what you do at Cisco DevNet?

Wee: I’m at Cisco, and as you said, I founded DevNet, which is Cisco’s developer community. You might be wondering, “Why does Cisco have a developer community?” It’s because the network has become programmable, and we’ve been really driving that whole portfolio of networking to not only be software and hardware, but to have both. The fact that the network has APIs, the fact that the network is programmable, means that there’s a fundamentally different way to leverage the network. What we recognized more than five years ago is that we were going to be pushing our technology portfolio towards software, towards programmability, towards having APIs — but what that also means is that the people who operate networks and interface with them need to learn about that. So, in addition to building our products in a programmable way, we had to bring our community along as well.

Ashley: A network engineer asked me for career advice maybe nine years ago, and the first thing I said was, “I think you need to learn Python.” He wasn’t familiar with it, went to a Cisco Live event, heard about the programmability of the network, and came back excited. But I didn’t have much to hand him other than a Python book. Things have, of course, evolved greatly since then. How would you describe where we are today?

Wee: You were visionary to give him that advice. And now you would have somewhere to send him — to DevNet. If you go to developer.cisco.com, everything in DevNet is there. We have free coding resources, learning resources, learning about APIs. Python is fundamental to what we’re teaching — we recommend it as the base language, though people can use any language they want. In addition to Python, there are all the standard software development tools we want people to use: GitHub, Postman, your favourite code editor. We want networkers to understand software practices — code sharing, using GitHub repos not just for code but for sharing and checking network configs, and using those configs in CI/CD pipelines.

Wee (continued): At developer.cisco.com, we have learning labs and a StartNow path — developer.cisco.com/startnow — which is a place for that networker to get started with software and our APIs. We also have material for advanced software developers who want to get in and start programming a network, doing automation, using advanced security services. And we have the DevNet Sandbox: if you want to experiment but don’t have physical gear, you can make reservations to real networking hardware, real security products, real collaboration products — things you can get hands-on with right away to test advanced coding and networking scenarios.

Ashley: It sounds like you’re really marrying two disciplines — the way software folks think about tools with the way a CCIE or CCNA engineer approaches a sandbox lab. You’ve combined those two worlds.

Wee: We have, and it’s super interesting. When we talk about who will run the IT system or the DevOps platform of the future — will it be the CCIE networker who keeps mission-critical networks running with many nines of reliability, or the software developer who can ship hundreds of lines of code a day? What we’ve found, watching teams move to automation, is that it’s a combination of both. You’ll want someone who deeply understands networks and someone who can code. You might find a unicorn who does both at an expert level, but more often you’ll have a team working together. And you want networking tools simplified enough, and automation extensive enough, that the bar for entry is lower. That’s what we’ve tried to hit with DevNet.

Ashley: What does the NetOps or NetDevOps world look like as you’re helping people move from separate networking and software disciplines into a blended practice?

Wee: The importance is doing the blending so you take the best from both worlds. One of the new things we announced at Cisco Live in June was the Cisco DevNet certification. There are 1.7 million Cisco-certified professionals in the world — people who’ve earned CCNA, CCNP, or CCIE credentials. Now we’ve created the Cisco DevNet certification: a DevNet Associate level, a Professional level, and an Expert level announced in the future. This brings the software skill set to networking. If you go to developer.cisco.com/certification, you’ll see it covers all the software tools you’d need to learn — using REST APIs, using APIs securely, authentication, and progressively more advanced software topics.

Wee (continued): The way we designed it: our traditional networking certifications are 80% networking, 20% software. Our DevNet software certifications are 80% software and 20% networking. We did that so the two groups can work together effectively. There’s enough networking for a software engineer to be productive in an infrastructure context, enough to write automation software for DevOps pipelines that leverage programmable networking.

Ashley: You’ve focused on automation as a core use case. How would someone get started with automation on a live network they’re currently managing?

Wee: That’s a great question, because while we all strive for full automation, the question is how you get there — especially with a live system running 24/7. What we’ve done in the DevNet Automation Exchange is categorize use cases into a walk, run, fly approach.

Walk means starting with read-only access. Get visibility and insights into what’s going on. Run analytics. As a concrete example: one thing you always have to do on a large network is continuously audit configurations. If someone reconfigured a device, added hardware, or changed a setting that now creates a security risk — you need to know. Moving this into a software workflow means storing your network configs in GitHub, using version control, running Ansible playbooks to check continuously that you haven’t deviated from a golden template, and alerting your ops team when something is off. That’s read-only, low-risk, and already dramatically better than most teams’ current state.

Run is when you’re ready to push control or policy to a live system. For example: if you’re managing wireless networks across many retail locations, you can automate SSID creation, shutdown, and guest-password resets through an API call rather than touching each controller manually.

Fly is the full DevOps workflow: proactive monitoring, analytics, automated remediation, and closed-loop deployment. An example: you want to deploy a new application that must access a financial database, available only to a specific set of employees. You can write a pipeline that segments the network with VLANs, sets access-control policies, and maps application requirements down to network configuration using Cisco ACI (Application Centric Infrastructure) — all through a CI/CD pipeline with no manual CLI work. We have code in the Automation Exchange for all of these scenarios so teams can jump in, get started, and customize for their own environment.

Ashley: Usually these are totally separate worlds. Now you’re integrating them into a CI/CD workflow — a toolchain that manages not just software DevOps but network operations.

Wee: Exactly. And the network world doesn’t always realize how much has already been worked through in the DevOps world — toolchains, workflow pipelines, patterns for managing change at scale. Those practices don’t lift-and-shift perfectly into a network paradigm, but they come very close. Network engineers have a bigger head start than they realize.

Wee: And it goes both ways. We’re not claiming to do rocket science in terms of something entirely new. What we’re doing is connecting two worlds so the best practices from both can come together.

Ashley: What’s the invitation to the DevOps community specifically?

Wee: Please come to DevNet. DevNet is not only for networkers. It provides a way for DevOps and DevSecOps engineers to interact with networkers, access programmable network APIs, and share what you know about software workflows and pipelines. I would love to have the DevOps community join and give us feedback on how we can make the programmable network even more useful to what you’re building.

Ashley: Susie, thank you so much. I’d like to thank my guest, Susie Wee, SVP and CTO of Cisco DevNet, for joining us today.

What Is Blockchain?

A blockchain is an append-only, distributed data structure made up of cryptographically linked blocks. Each block contains a set of records (transactions, events, or any structured data) along with a cryptographic hash of the previous block, which is what creates the immutable chain. Because the full chain is replicated across many independent nodes, no single participant can silently alter historical records without the rest of the network detecting the change.

Key characteristics of blockchain technology include:

• Decentralization: No central authority owns or controls the ledger. Consensus is reached across network participants according to a defined protocol.
• Immutability: Once a block is confirmed and added to the chain, altering it requires re-computing every subsequent block and gaining majority consensus — computationally and socially prohibitive in a large network.
• Transparency: All participants with access to the network can inspect the full history of recorded transactions.
• Security through cryptography: Each block is signed and chained using cryptographic hashes (commonly SHA-256 or similar), making tampering immediately detectable.
• Trustless operation: Parties that do not inherently trust each other can transact without requiring a mutually trusted intermediary.

What Is DevOps?

DevOps is a set of practices, cultural principles, and tooling patterns that aim to shorten the software development lifecycle and deliver high-quality software continuously. It bridges the historically siloed worlds of software development (Dev) and IT operations (Ops), encouraging shared ownership of the entire delivery pipeline — from code commit to production deployment.

Core DevOps practices include:

• Continuous Integration (CI): Developers merge code into a shared repository frequently, with automated builds and tests validating every change.
• Continuous Delivery/Deployment (CD): Validated builds are automatically promoted through staging environments toward production, reducing manual handoffs and deployment risk.
• Infrastructure as Code (IaC): Infrastructure is defined, versioned, and managed using the same tools and practices applied to application code.
• Monitoring and Observability: Production systems are instrumented so that teams detect and respond to issues quickly.
• Collaboration and Shared Responsibility: Development, QA, security, and operations teams work together rather than throwing work over the wall.

Where Blockchain and DevOps Intersect

At first glance, blockchain looks like a data-storage concern and DevOps looks like a delivery-process concern. But several real integration points exist:

1. Immutable Audit Trails for Software Pipelines

A DevOps pipeline generates a large number of events: who triggered a build, which tests passed, which artifact was promoted, who approved a deployment, and what configuration was applied. In regulated industries — finance, healthcare, defense — these records must be tamper-evident and available for audit. Recording pipeline events on a blockchain ledger produces an audit trail that no single administrator can retroactively modify.

2. Supply Chain Security for Software Artifacts

Modern applications depend on hundreds of open-source libraries and container base images. A blockchain-based software supply chain registry can record the provenance of each dependency — who built it, when, from which source commit, and with which signing key. Downstream consumers can verify that the artifact they are pulling has not been tampered with since it was published. This directly addresses supply chain attack scenarios, such as dependency confusion or compromised package registries.

3. Cross-Organization Collaboration and Smart Contracts

Many DevOps pipelines span organizational boundaries — vendors, contractors, regulated partners. When multiple independent organizations contribute to a shared delivery chain, smart contracts on a permissioned blockchain can enforce gates: a deployment cannot proceed to the next environment unless all required sign-offs from all parties are recorded on-chain. This removes the need for a central coordinator that all parties must trust.

4. Configuration and Secrets Integrity

Infrastructure configuration drift is a persistent operational risk. Storing cryptographic hashes of known-good configuration states on a blockchain allows automated compliance tools to detect any deviation from the approved baseline in real time, providing a verifiable reference that survives even administrative credential compromise.

5. Cost-Efficient Decentralized Testing Environments

Blockchain applications by their nature require networks of nodes rather than a single server, which makes spinning up test environments complex. DevOps practices — particularly IaC and container orchestration — make it straightforward to provision multi-node blockchain test networks on demand, run integration tests against them, and tear them down, dramatically reducing the operational overhead of developing and testing blockchain-based systems.

Practical Advantages of Combining Blockchain and DevOps

• Transparent, auditable delivery chains: Every step from code commit to production can be cryptographically recorded and independently verified.
• Reduced fraud and insider risk: Immutable logs constrain the ability of any single actor — including privileged administrators — to tamper with deployment history.
• Easier compliance reporting: Regulated organizations can generate audit evidence directly from on-chain records rather than assembling it manually from disparate logs.
• Faster onboarding of external partners: Smart contract–enforced gates replace slow, email-driven approval workflows in multi-organization pipelines.
• Better software supply chain trust: Artifact provenance recorded on a shared ledger makes it possible for consumers to verify integrity without relying solely on the publisher.

Challenges and Honest Trade-offs

Combining these two disciplines is not without cost. Blockchain infrastructure adds operational complexity, storage overhead, and latency that are inappropriate for many use cases. Before introducing a blockchain ledger into a DevOps pipeline, teams should ask:

• Do we actually have multiple mutually distrustful parties who need a shared, tamper-evident record? If not, a traditional append-only log (e.g., a write-once object store) may suffice.
• Can we absorb the governance overhead of managing a permissioned blockchain network, including node operation, key management, and smart contract upgrades?
• Have we modeled the latency impact on pipeline throughput, particularly for high-frequency CI pipelines that run hundreds of builds per day?

Where the answer to the first question is yes — especially in regulated, multi-party contexts — blockchain can add genuine value that simpler logging solutions cannot match.

Summary

Blockchain and DevOps address different layers of the software delivery problem, which is precisely why they complement each other. DevOps supplies the automation, speed, and cultural framework for delivering software reliably. Blockchain supplies the cryptographic guarantees that what was delivered is what was agreed upon, by whom, and when — with a record that no single party can unilaterally erase. For teams building blockchain-based applications, DevOps practices make the development lifecycle manageable. For teams that need verifiable, auditable delivery pipelines, blockchain provides a trust anchor that traditional logging cannot. The intersection is narrow today, but it is growing as software supply chain security and regulatory compliance requirements intensify.

This article draws on concepts originally discussed by Aditya S on JAXenter (jaxenter.com).