Why Ansible Works Well for Network Automation

Two properties make Ansible particularly attractive in a network context:

• Agentless operation. Ansible communicates with network devices over SSH (or a vendor API where available). There is nothing to install on the managed device — a major advantage when you are working with switches and routers that do not expose a general-purpose OS.
• Low barrier to entry. YAML playbooks read almost like plain English. Network engineers who are comfortable with incremental learning — picking up IOS features as needed, for example — adapt quickly to Ansible’s model.

Ansible runs on a control node (a Linux host or WSL instance) and issues commands to one or many network devices simultaneously. Its behaviour is governed by plain-text configuration files, making it easy to version-control your automation alongside your other infrastructure code.

Key Concepts Before You Start

• Inventory — a list of the devices Ansible manages, organised into groups.
• Playbook — a YAML file describing one or more plays, each containing one or more tasks.
• Module — a reusable unit of work. Network modules such as ios_command, eos_command, and the vendor-agnostic cli_command handle interaction with specific platforms.
• Variables — stored in group_vars and host_vars directories and merged at run time, giving you fine-grained control over per-device or per-group settings.

Recommended Directory Structure

You can run Ansible with a single flat file, but that quickly becomes unmanageable. A structured layout separates concerns and scales cleanly as your device count grows. The following layout is used in the examples below:

.
├── ansible.cfg
├── group_vars
│   └── IOS_switches.yml
├── host_vars
│   └── test_sw.yml
├── inventory.yml
└── sh_arp.yml

ansible.cfg

This INI-format file overrides Ansible defaults. The most important settings for network automation are disabling fact gathering (which is designed for Linux hosts, not network devices) and pointing Ansible at your inventory file.

[defaults]
gathering = explicit
inventory = inventory.yml
retry_files_enabled = False

group_vars/IOS_switches.yml

Variables in group_vars apply to every host in the named group. Here we set the connection type to network_cli, declare the OS as ios, and supply credentials. In production, use Ansible Vault or SSH keys rather than plain-text passwords.

---
# IOS_switches variables
ansible_connection: network_cli
ansible_network_os: ios
ansible_become: yes
ansible_become_method: enable
ansible_become_password: "foobar"

ansible_user: tester
ansible_ssh_pass: foobar

host_vars/test_sw.yml

Host-level variables override group variables for a specific device. A management IP address and hostname are the minimum useful entries.

---
# test_sw variables
ipaddr: 192.168.1.108
hostname: test_sw

inventory.yml

The inventory file lists your devices and organises them into groups. A single device can belong to multiple groups, which is useful when you want to target switches by both vendor OS and network role.

---
all:
  children:
    IOS_switches:
      hosts:
        test_sw:
    IOS_routers:
      hosts:
        router1:
    access:
      hosts:
        test_sw:
    core:
      hosts:
        router1:

Writing Your First Playbook: Collecting the ARP Table

A good first automation task is read-only data collection — it is safe, immediately useful, and gives you a baseline to compare against. The playbook below, sh_arp.yml, issues show arp to every host in the IOS_switches group and prints the output.

---
- name: Gather ARP data
  hosts: IOS_switches
  tasks:
    - name: "Task 1: Get output of show arp on IOS"
      ios_command:
        commands: "show arp"
      register: cli_result

    - name: "Task 2: Display stdout_lines[0]"
      debug:
        msg: "{{ cli_result.stdout_lines[0] }}"

Key points about the playbook structure:

• ios_command sends a CLI command to an IOS device and returns the output as a string.
• register: cli_result saves the module’s return value into a variable for use in later tasks.
• The debug module prints the value of cli_result.stdout_lines[0] — a list of output lines from the first (and only) command issued.

Running the Playbook

$ ansible-playbook sh_arp.yml

Expected output:

PLAY [Gather ARP data] ***************************************************

TASK [Task 1: Get output of show arp on IOS] *****************************
ok: [test_sw]

TASK [Task 2: Display stdout_lines[0]] ***********************************
ok: [test_sw] => {
    "msg": [
        "Protocol  Address     Age (min)  Hardware Addr   Type  Interface",
        "Internet  192.168.1.108       -  bcc4.933e.49c0  ARPA  Vlan1",
        "Internet  192.168.1.126       5  f894.c220.2177  ARPA  Vlan1",
        "Internet  192.168.1.133       1  88c2.55fb.9ce7  ARPA  Vlan1",
        "Internet  192.168.1.138       0  a860.b60a.7a3a  ARPA  Vlan1"
    ]
}

PLAY RECAP ***************************************************************
test_sw                    : ok=2    changed=0    unreachable=0    failed=0

The PLAY RECAP line confirms two tasks completed successfully with no changes and no failures — exactly what you want from a read-only operation.

Scaling Up: Running Across Many Devices

The real value of Ansible is not running a single command on one switch — it is running a set of tasks across dozens or hundreds of devices with a single command. Once your inventory is populated, the same playbook targets every matching host automatically.

Practical use cases that are well suited to this pattern include:

• Compliance auditing. Verify that device configurations match a known-good template — for example, that QoS policies or MPLS route targets are consistent across the fleet.
• Inventory and documentation. Collect show version output from every device and store it to disk. You immediately have a searchable record of firmware versions, model numbers, and serial numbers.
• MAC and IP address tracking. Save show arp and show mac address-table dynamic output, then use grep to locate any device on the network by its IP or MAC address across hundreds of output files.
• Configuration generation and deployment. Combine Ansible with the Jinja2 templating language to dynamically render device configurations and push them across the network.

Beyond the Basics

The example above covers a small fraction of what Ansible can do for network teams:

• Ad hoc mode. Run a single module against an inventory group without writing a playbook — useful for quick checks during troubleshooting.
• Ansible Vault. Encrypt sensitive files such as credential variables so that secrets are never stored in plain text.
• Filters and plugins. Parse structured output, transform data, and extend Ansible’s capabilities beyond its built-in modules.
• Jinja2 templating. Generate device-specific configuration files from a single template, replacing manual copy-paste workflows.
• Roles. Package related tasks, variables, and templates into a reusable unit that can be shared across projects or published to Ansible Galaxy.

Nick Russo’s tutorial, Automating Networks with Ansible the Right Way, is frequently cited as a useful resource for engineers who want to move beyond basic playbooks into areas such as maintaining MPLS configurations with Ansible.

Getting Started: Recommended Approach

1. Install Ansible on a Linux control node (or WSL on Windows).
2. Build the directory structure shown above with a single test device in your inventory.
3. Start with the read-only ARP collection playbook and confirm it works.
4. Expand to additional show commands and save results to files using the copy or template modules.
5. Once comfortable, explore write operations — start with non-production devices and always test with --check mode where supported.

Ansible’s official Ansible for Network Automation documentation section is the authoritative starting point. It links to a getting-started guide, an advanced topics guide, and a full list of network modules organised by vendor and platform.

Summary

Ansible is a practical choice for network automation: it is agentless, uses SSH, and its YAML-based playbooks are no harder to learn than many networking concepts you already know. Starting with simple read-only tasks — collecting ARP tables, documenting firmware versions, auditing configurations — gives you immediate value with minimal risk. As your confidence grows, the same tool scales to configuration deployment, compliance enforcement, and full network lifecycle management.

Two of the most widely used platforms built on top of Git are GitHub and GitLab. Both host repositories, manage pull/merge requests, and support team collaboration. However, they differ significantly in their approach to the broader software delivery lifecycle—particularly around CI/CD, deployment, and self-hosting. This article explains those differences so you can make an informed choice for your team.

GitHub: The Social Coding Platform

GitHub was launched in 2008, co-founded by Tom Preston-Werner, PJ Hyett, and Chris Wanstrath. It is a Git-based repository hosting service that has grown into one of the largest communities for open-source software in the world.

Key characteristics of GitHub include:

• Open-source community hub: Public repositories are free, making GitHub the default home for most open-source projects. Discoverability, forking, and community contributions are first-class features.
• GitHub Actions (CI/CD): GitHub’s built-in automation platform lets you define workflows in YAML to build, test, and deploy code. It became generally available in 2019 and has expanded significantly since.
• Access control and project management: GitHub provides issue tracking, project boards, milestones, and wikis alongside repository hosting.
• Large marketplace: A rich ecosystem of third-party Actions and integrations covers most CI/CD, security, and deployment scenarios.
• Microsoft ownership: Microsoft acquired GitHub in 2018, which has accelerated enterprise integration (Azure DevOps, VS Code, Copilot).

GitHub does not natively bundle deployment orchestration or application monitoring tools. Teams that need automated deployments typically integrate external services such as AWS CodeDeploy, Heroku, or Kubernetes operators via Actions workflows.

GitLab: The Integrated DevOps Platform

GitLab is also a Git-based repository manager, but its design philosophy is different: it aims to be a single application covering the entire DevOps lifecycle—from planning and source control through CI/CD, security scanning, deployment, and monitoring.

Key characteristics of GitLab include:

• Built-in CI/CD with GitLab Pipelines: GitLab CI/CD is deeply integrated and has been a core feature since 2012—predating GitHub Actions. Pipelines are defined in a .gitlab-ci.yml file at the repository root.
• Self-managed option: GitLab can be installed on your own infrastructure (Community Edition is open-source; Enterprise Edition is commercial). This is a critical differentiator for organisations with strict data-residency or air-gapped requirements.
• Kubernetes integration: GitLab provides native integration with Kubernetes clusters, enabling automated container deployment, scaling, and environment management directly from the platform.
• Security and compliance tooling: GitLab’s higher-tier plans include SAST, DAST, container scanning, dependency scanning, and license compliance—all surfaced inside merge request pipelines.
• Innersourcing support: GitLab supports internal visibility levels that let teams share repositories across an organisation without making them fully public—useful for enterprise innersourcing strategies.
• Application performance monitoring: GitLab integrates with monitoring tools to surface performance data alongside deployment activity.

Side-by-Side Feature Comparison

The table below summarises the most practically relevant differences for DevOps teams.

CI/CD: A Closer Look

CI/CD is often the deciding factor in the GitLab vs. GitHub decision.

GitLab Pipelines

GitLab’s pipeline system is mature and feature-rich. A minimal .gitlab-ci.yml looks like this:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Compiling the application..."

test-job:
  stage: test
  script:
    - echo "Running unit tests..."

deploy-job:
  stage: deploy
  script:
    - echo "Deploying to production..."
  environment:
    name: production

GitLab provides shared runners on its SaaS offering, and teams can register self-hosted runners with a single command—giving them full control over the build environment and no per-minute billing surprises.

GitHub Actions

GitHub Actions uses a workflow YAML stored under .github/workflows/. The Actions Marketplace offers thousands of pre-built steps for almost any task. An equivalent minimal workflow:

name: CI

on: [push]

jobs:
  build-test-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: echo "Compiling the application..."
      - name: Test
        run: echo "Running unit tests..."
      - name: Deploy
        run: echo "Deploying to production..."

GitHub Actions is tightly integrated with the GitHub ecosystem and benefits from Microsoft’s investment in tooling, including integration with Azure and GitHub Copilot.

When to Choose GitLab

GitLab tends to be the better choice when one or more of the following apply:

• You need to self-host: Compliance requirements, air-gapped networks, or data-sovereignty rules make on-premises hosting mandatory. GitLab’s Community Edition is free and open-source.
• You want an all-in-one DevOps platform: If your team wants planning, SCM, CI/CD, security scanning, and deployment observability under one roof without stitching together many third-party tools, GitLab’s integrated approach reduces operational overhead.
• Kubernetes-native deployments matter: GitLab’s native Kubernetes integration simplifies environment management and progressive delivery without requiring additional tooling.
• Innersourcing at enterprise scale: The internal repository visibility level makes it straightforward to share code across business units without opening it to the public.
• Built-in security scanning is a priority: GitLab’s higher-tier plans include SAST, DAST, and dependency scanning directly in the merge request pipeline, which can simplify compliance workflows.
• Mature CI/CD with self-hosted runners: GitLab Runner is lightweight, easy to configure, and supports Docker, Kubernetes, shell, and other executors out of the box.

When to Choose GitHub

GitHub tends to be the better choice when:

• Open-source visibility and community are important: GitHub is where the vast majority of open-source projects live. Discoverability, contributor onboarding, and community interaction are stronger here.
• Your team is already in the Microsoft / Azure ecosystem: Integration with Azure services, Visual Studio, and GitHub Copilot is seamless.
• You rely on a wide third-party integration marketplace: The Actions Marketplace and the breadth of existing integrations often means less custom scripting.
• Social coding and developer experience are top priorities: GitHub’s interface, pull request workflow, and Discussions feature are widely regarded as polished and developer-friendly.

Summary

Neither platform is universally superior. GitHub excels as a social coding and open-source collaboration hub with a rich integration ecosystem. GitLab excels as an integrated, self-hostable DevOps platform that covers more of the software delivery lifecycle out of the box.

The practical decision usually comes down to three questions:

1. Do you need to self-host? → GitLab Community Edition.
2. Is open-source community reach important? → GitHub.
3. Do you want a single platform for CI/CD, security, and deployment without heavy third-party integration? → GitLab.

Evaluate your team’s workflow, compliance requirements, and long-term DevOps maturity goals before committing to either platform. Both offer free tiers and trials that make hands-on evaluation practical before any purchase decision.

BlackBerry Brings Enterprise Security Portfolio to Azure Marketplace

BlackBerry Limited (NYSE: BB; TSX: BB) announced that a set of its enterprise cybersecurity and endpoint management solutions are now purchasable and deployable directly through the Microsoft Azure Marketplace. The move gives existing Azure customers a faster path to evaluating, procuring, and deploying BlackBerry software within an environment they already manage and trust.

The listing covers four distinct products spanning crisis communications, unified endpoint management, secure content collaboration, and embedded secure messaging. Each solution is certified to run on Azure, meaning organizations can consolidate procurement and billing within their existing Azure agreements.

Why This Matters for DevOps and Security Teams

For DevOps and IT operations teams already running workloads on Azure, marketplace availability removes several friction points:

• Consolidated billing: Azure Marketplace purchases can be rolled into existing Azure spend commitments and invoices.
• Pre-validated deployments: Solutions listed on the Azure Marketplace are tested and certified to run on the Azure platform, reducing integration risk.
• Faster provisioning: Teams can deploy directly from the marketplace rather than negotiating separate vendor contracts or configuring manual integrations.
• Zero-trust alignment: BlackBerry’s portfolio is positioned around zero-trust security principles, which map directly to modern enterprise security postures for hybrid and multi-cloud environments.

The Four BlackBerry Solutions on Azure Marketplace

BlackBerry AtHoc

A crisis communications platform designed to improve organizational coordination during emergencies. AtHoc enables targeted, multi-channel alerting across personnel groups, making it particularly relevant for government agencies, healthcare organizations, and large enterprises with distributed workforces.

BlackBerry UEM (Unified Endpoint Management)

BlackBerry UEM provides centralized policy control across an organization’s entire device and application fleet, including mobile phones, laptops, tablets, and IoT endpoints. For DevOps teams managing device fleets alongside cloud infrastructure, UEM offers a single control plane to enforce security policies without fragmenting tooling.

BlackBerry Workspaces

A secure content collaboration platform that applies file-level digital rights management (DRM) to protect sensitive documents and intellectual property. Unlike perimeter-based controls, file-level DRM keeps protections attached to the document itself regardless of where it travels, which is relevant for teams sharing data across organizational boundaries.

BlackBerry Spark Communications Services

A Communications Platform as a Service (CPaaS) offering that lets developers embed end-to-end encrypted messaging, voice, and collaboration capabilities directly into enterprise applications and smart devices. This is notable for teams building IoT-connected products or internal tooling that requires secure, auditable communication channels without building cryptographic infrastructure from scratch.

Partnership Context: BlackBerry as a Microsoft Gold Partner

BlackBerry holds Gold Partner status within the Microsoft Azure Partner Network, which reflects a validated level of technical competency and commitment to the Azure ecosystem. Richard McLeod, Global Vice President of Enterprise Software Channels at BlackBerry, framed the marketplace listing as part of a broader distribution strategy:

“We want to ensure that BlackBerry’s trusted solutions are available to customers wherever they choose to seek out our products. As a Gold Partner within the Microsoft Azure Partner Network, we are pleased to offer some of those solutions—key to navigating today’s zero trust environment—on the Microsoft Azure Marketplace.”

— Richard McLeod, Global Vice President, Enterprise Software Channels, BlackBerry

Sajan Parihar, Senior Director of Microsoft Azure Platform at Microsoft, confirmed the certification process behind the listing:

“Through Microsoft Azure Marketplace, customers around the world can easily find, buy, and deploy partner solutions they can trust, all certified and optimized to run on Azure. We’re happy to welcome BlackBerry’s cybersecurity solutions to the growing Azure Marketplace ecosystem.”

— Sajan Parihar, Senior Director, Microsoft Azure Platform, Microsoft Corp.

About the Microsoft Azure Marketplace

The Azure Marketplace is Microsoft’s online storefront for cloud solutions that are certified and optimized to run on Azure. It serves as a distribution channel connecting enterprises looking for ready-to-deploy software with independent software vendors (ISVs) and managed service providers. Solutions available through the marketplace span infrastructure, security, analytics, developer tools, and industry-specific applications.

About BlackBerry

BlackBerry (NYSE: BB; TSX: BB) is a security software and services company headquartered in Waterloo, Ontario, Canada. The company focuses on enterprise and government markets, with product lines covering endpoint security and management, encryption, embedded systems, and AI-assisted threat detection. BlackBerry has repositioned itself over the past decade from a hardware manufacturer to a software-centric cybersecurity vendor. More information is available at blackberry.com.

Trademarks, including but not limited to BLACKBERRY and EMBLEM Design, are the trademarks or registered trademarks of BlackBerry Limited. All other trademarks are the property of their respective owners.

The Push for Real-World Relevance in Certification

For years, technology certifications were criticised for testing rote memorisation rather than practical competence. Two major industry players—Cisco Systems and CompTIA—have independently moved to change that, redesigning their programmes around performance-based testing and real-world scenarios. For hiring managers and team leads building DevOps practices, this shift matters: certifications are increasingly becoming a more reliable signal of on-the-job capability.

Cisco’s DevNet Certifications: Bridging Networking and Software Development

Cisco announced a significant restructuring of its training and certification portfolio, introducing a dedicated DevNet Certification track. The goal is to validate an individual’s ability to apply software skills to modern network technologies—a combination that has historically been scarce in the industry.

Susie Wee, then Senior Vice President and CTO of DevNet at Cisco, framed the rationale clearly:

“Advances in network technologies have enabled new applications and business models—converged IP networks enabled voice over IP, 3G networks enabled mobile applications and 4G networks enabled mobile video. DevOps has become a key factor for bringing those new networked applications to life. Training and certifications for network professionals and software developers have become a must.”

Susie Wee, SVP & CTO of DevNet, Cisco Systems

The DevNet Certifications are structured to help network engineers learn software development practices, and to help application developers understand how to exploit network capabilities fully. According to Wee, this is essential because the only way to leverage modern network infrastructure effectively is to build DevOps teams that possess both networking and software skills—skills needed to navigate both software-defined networking (SDN) and traditional physical network solutions.

CompTIA’s Approach: Performance-Based Testing and Certification Pathways

CompTIA undertook a parallel revamp of its certification programmes. A notable example is the CompTIA Linux+ certification, which was redesigned to validate competencies expected of early-career IT professionals who support Linux environments.

James Stanger, CompTIA’s Chief Technology Evangelist, described the philosophy behind the change:

“For certifications to have real value today, people must immerse themselves in the technology. The new Linux+ certification uses performance-based testing that presents candidates with real-world scenarios, meaning that achieving certification demonstrates the ability to function in the real world.”

James Stanger, Chief Technology Evangelist, CompTIA

Stanger also outlined the broader skill set that DevOps team members need, going beyond a single specialisation:

• Project management methodologies — both Agile and Waterfall
• Operating system proficiency — deep familiarity with both Windows and Linux environments
• Database knowledge — covering relational databases and object-oriented databases
• Breadth with depth — the ability to specialise in one area while maintaining enough cross-functional understanding to collaborate effectively

CompTIA’s certification pathways are designed with team-building in mind, allowing organisations to map individual certifications to the collective skill requirements of a DevOps team rather than treating each certificate in isolation.

Cisco DevNet: Building a Community Around Network Automation

Beyond certifications, Cisco has invested in DevNet, a developer community and resource hub created to help network engineers and application developers adapt to rapidly changing network technologies. One of its flagship initiatives is the DevNet Automation Exchange—a community-based developer centre focused on network automation.

Cisco describes the Automation Exchange as helping practitioners progress through three stages of network automation maturity:

Walk: Visibility and Read-Only Insights

At the foundational level, teams gain visibility into their network infrastructure in a read-only capacity. Practical use cases include gathering telemetry data from running networks and conducting audits to verify ongoing security posture—valuable starting points for teams new to automation.

Run: Policy Activation Across Network Domains

At the intermediate level, teams can activate policy and intent across different network domains. This supports use cases such as self-service network operations that enforce security policies and comply with operational guidelines—reducing manual toil without requiring full automation maturity.

Fly: Full DevOps Workflow Integration

At the advanced level, teams proactively manage applications, users and devices using DevOps workflows. Key use cases include deploying applications through CI/CD pipelines while automatically configuring the network to conform to new application policies—representing true infrastructure-as-code practice at the network layer.

The Automation Exchange was seeded with more than 50 code repositories, many contributed by Cisco’s own engineering teams and systems engineers. Cisco has since opened the platform for community contributions, inviting DevNet members to submit code that addresses their specific use cases.

What This Means for DevOps Team Building

The moves by Cisco and CompTIA signal a broader industry maturation in how technical skills are validated. For DevOps practitioners and engineering managers, there are several practical takeaways:

• Certifications are becoming more meaningful. Performance-based testing and scenario-driven assessments make it easier to use certifications as a reliable hiring and skills-gap signal.
• Networking and software skills are converging. Teams that lack network automation skills are increasingly at a disadvantage as infrastructure becomes more programmable.
• Pathways matter as much as individual certifications. Mapping certification tracks to team roles—rather than requiring every team member to hold the same credential—allows for more efficient skills development.
• Community resources supplement formal training. Platforms like DevNet Automation Exchange provide hands-on code examples that bridge the gap between classroom learning and production implementation.

As organisations continue to automate infrastructure and adopt CI/CD practices, the demand for professionals who hold both deep and broad technical skills will only grow. Updated certification programmes that prioritise real-world competency are a step in the right direction for the industry.

The Convergence of DevOps and Networking

For years, networking was treated as a discipline apart from software development and systems operations. Network changes were manual, infrequent, and governed by change-management processes that stood in sharp contrast to the rapid iteration cycles championed by DevOps teams. That gap is closing. Practices from the DevOps world — automation, version control, continuous delivery, and observability — are being systematically adopted into the management of networking services, driven by better tooling, more programmable hardware, and the rise of software-defined networking.

Key DevOps Practices Being Adopted in Networking

Several DevOps disciplines translate directly into networking contexts:

• Networks-as-Code — Declaring desired network topology and behavior in version-controlled configuration files, then applying that state programmatically to physical or virtual devices.
• CI/CD Pipeline Integration — Treating network configuration changes as deployable artifacts, validated and promoted through automated pipelines before reaching production.
• Container-scale Network Functions — Decomposing network services into smaller, independently deployable units that can run in containers rather than on dedicated appliances.
• Chaos Engineering for Networks — Deliberately injecting network faults to validate resilience and expose hidden dependencies before they cause unplanned outages.
• Unified Monitoring and Observability — Extending the same monitoring stacks used for applications and infrastructure to cover network-specific metrics and events.

Networks-as-Code: Declaring Intent, Not Commands

The infrastructure-as-code (IaC) pattern — where the desired state of infrastructure is expressed in declarative files and enforced by automation tools — maps naturally to networking. With networks-as-code, engineers describe how a network should look and behave: which VLANs exist, how routing tables should be configured, what firewall rules apply. An automation tool then reconciles the live network against that declared state.

Historically, network device configuration has been standardized through protocols such as NETCONF (Network Configuration Protocol, RFC 6241), but adoption in automation toolchains was slow. That changed as mainstream DevOps tools added native networking support:

• Ansible introduced dedicated modules for networking device automation, covering hardware from multiple vendors including Cisco, Juniper, Arista, and others. These modules allow network configuration tasks to be expressed as Ansible playbooks alongside server and cloud automation.
• SaltStack provides similar networking modules, enabling event-driven and scheduled configuration management of network devices.
• NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support) is an open-source library that provides a vendor-neutral Python API for interacting with network devices. It integrates with both Ansible and Salt, allowing engineers to write automation that works across different vendors’ hardware without rewriting logic per platform.

Virtual Network Functions and Containers as Experimentation Platforms

One barrier to adopting automation in networking has been the risk of experimenting directly on production hardware. Virtual Network Functions (VNFs) — network capabilities such as firewalls, load balancers, or routers running as software on virtual machines rather than on dedicated physical appliances — lower that barrier considerably. Teams can test automation workflows against virtual instances before applying them to production hardware.

VNF adoption has been particularly pronounced in the telecommunications industry, where operators are under pressure to provision and reconfigure network services rapidly. Beyond virtual machines, some network functions are being containerized, enabling faster startup times and denser packing on commodity hardware. Not all network functions are well-suited to containerization — those with high throughput requirements or tight hardware integration may still require VMs or dedicated appliances — but the trend toward containerized network functions is growing.

Software-Defined Networking as an Automation Enabler

Software-Defined Networking (SDN) separates the control plane (decisions about where traffic goes) from the data plane (the actual forwarding of packets). By exposing the control plane through APIs and programmable interfaces, SDN makes network devices far more amenable to scripted and automated configuration. As more networking services are delivered through SDN architectures, the surface area available for DevOps-style automation expands correspondingly.

Chaos Engineering Applied to Network Reliability

Chaos engineering — the practice of deliberately introducing failures into a system to uncover weaknesses — is well established for application and infrastructure layers. Its application to networking is less mature. Network chaos experiments might include simulating link failures, injecting packet loss or latency, or partitioning network segments to observe how applications and failover mechanisms respond.

At the time of the original reporting, chaos engineering in the networking domain was still in early stages. The principles are sound: if you do not proactively test how your network behaves under failure conditions, you will discover those behaviors during an incident instead.

Monitoring and Observability for Networks

Networks are increasingly monitored using the same tooling that observes the rest of the stack — time-series databases, dashboards, alerting systems, and distributed tracing platforms. Some of these tools include network-specific extensions or integrations, such as SNMP polling, flow data collection (NetFlow, sFlow, IPFIX), and BGP/routing state monitoring. Unifying network observability with application and infrastructure observability gives teams a single plane of glass for diagnosing cross-layer issues, rather than requiring separate NOC and operations workflows.

The Human Factor

Automation does not eliminate the human element in network reliability — it changes it. Studies on network reliability have identified human error as a leading cause of outages, which motivates investment in automation to reduce manual, error-prone steps. At the same time, effective automation requires skilled engineers who understand both the networking domain and the software engineering practices needed to build and maintain reliable automation pipelines. Bridging this skill gap is one of the central challenges in the NetDevOps or Network Reliability Engineering space.

Summary

The application of DevOps principles to networking is not a distant aspiration — it is actively happening, driven by programmable hardware, open-source tooling like Ansible, SaltStack, and NAPALM, and architectural shifts toward SDN and VNFs. Teams looking to move in this direction can start by treating network configuration as code, integrating network change validation into CI/CD pipelines, and extending existing monitoring practices to cover the network layer.

The Infrastructure-as-Code Landscape Was Evolving Fast

By mid-2017, IT operations teams were leaning heavily on infrastructure-as-code (IaC) tools to keep pace with the demands of DevOps. But the tools themselves were advancing almost as quickly as the applications they were meant to support — bringing both capability improvements and painful breaking changes.

Established players Chef and Puppet had recently restructured their products to support containers and the underlying infrastructure changes that came with them. Chef refactored its codebase into three major open-source projects and introduced Habitat, which many users were still trying to understand. Puppet published a roadmap for improved container support and was working toward a container management API. AWS CloudFormation, released in 2011, had been receiving roughly monthly feature updates in the preceding year.

Among newer entrants, Ansible — launched around 2012 and acquired by Red Hat in 2015 — had added network automation integrations and Red Hat CloudForms support for multicloud environments. HashiCorp Terraform, first released in 2014, had gained momentum quickly but had not yet reached a stable 1.0 release, leaving users to absorb breaking changes with each pre-1.0 update.

“It’s a rapidly evolving area, and a lot of companies are just getting into this space. Most of the people working with these tools are sys admins who are trying to figure out how to scale, rather than developers.”

Brandon Cipes, Managing Director of DevOps, cPrime

Most Teams Mix and Match IaC Tools

Few organizations relied on a single IaC tool. Most combined two or more, which added its own layer of complexity. A common pattern was to start with AWS CloudFormation — a natural first choice for companies building on AWS — and then layer in additional tools as infrastructure needs grew more complex or extended to other cloud providers.

CloudFormation’s verbosity and configuration demands were a recurring complaint. Its JSON (and later YAML) templates require precise parameter configuration, and a misconfigured template will often fail entirely rather than partially recover.

“It’s just not the most friendly tool in the world. It doesn’t use an easy-to-read language, it requires a lot of parameters to be set, and all of those parameters and details have to be very particularly configured or it will break.”

Brandon Cipes, cPrime

Despite its friction, CloudFormation couldn’t simply be abandoned. Its ubiquity within the AWS ecosystem meant teams had to remain fluent in it to collaborate effectively with the broader AWS community.

“CloudFormation is the lingua franca to exchange ideas about infrastructure and AWS resources. We definitely need to know the technology to be able to exchange ideas with the rest of the community because of its ubiquity.”

Joaquin Menchaca, DevOps Engineer, goBalto Inc.

Ansible’s Appeal — and Its Gaps

Ansible’s YAML-based approach made it attractive to teams that wanted their infrastructure definitions to sit naturally alongside application code. Its agentless architecture and low barrier to entry made it popular with sysadmins transitioning into DevOps roles.

However, some practitioners felt that Ansible’s investment in new areas — particularly network automation — was coming at the expense of progress elsewhere. Container support, for example, was seen as underdeveloped. Ansible Container, a project intended to give operators a familiar interface for container workflows, saw limited adoption in practice.

“Their efforts with Docker have been disappointing, as they focus more on Ansible Container projects. It begs the question, ‘Why not just use shell?'”

Joaquin Menchaca, goBalto Inc.

Terraform: Easier to Use, Harder to Upgrade

HashiCorp Terraform had built a following among DevOps teams who found its HCL (HashiCorp Configuration Language) significantly more readable than CloudFormation’s verbose JSON templates. Its cross-cloud provider model was another major draw: teams could manage AWS resources, Google Cloud infrastructure, monitoring services like Datadog, and more — all from a single, consistent configuration language.

“Terraform is a general language for working across clouds and various resources so that we can work with things like Datadog alerts, AWS resources or potentially spin up parts of Google’s cloud infrastructure, all from one place with one uniform configuration language.”

Calvin French-Owen, Co-founder, Segment

“CloudFormation makes you want to poke your eyes out, whereas Terraform is much simpler to understand.”

Calvin French-Owen, Segment

The trade-off was instability in pre-1.0 releases. HashiCorp’s 0.9 release, for example, significantly changed how remote state was stored and managed — a change that was necessary for teams sharing infrastructure, but required substantial rework to adopt.

“We have to reimplement a few things on our side as far as our workflow and re-educate ourselves to move our state as it is now to the 0.9 version.”

Dale Ragan, Senior Software Engineer, SAP Concur Technologies

Teams using Terraform Enterprise also reported bugs in remote state management, leading some to prefer self-managed state stored in Amazon S3 rather than relying on the managed offering.

“In some cases, we’ve found it’s not quite a first-class citizen compared to when we were managing state ourselves and putting it on S3.”

Calvin French-Owen, Segment

The Stateful vs. Stateless Debate

Terraform’s use of state files to track real-world infrastructure was one of its defining characteristics — and one of its most polarizing. Tools like Ansible, Chef, and Puppet had traditionally taken a stateless, declarative approach: describe the desired state of the system and let the tool reconcile the difference. Terraform broke from this convention by maintaining a state file that records what infrastructure exists.

Proponents argued that state tracking was genuinely useful: it let teams know exactly what resources existed, enabled remote state sharing across teams, and allowed infrastructure to be built incrementally on top of resources managed by others.

“Knowing about the resources you have is important, and state gives you that. Also, remote state is tracked to allow teams to build on top of infrastructure they may not control.”

Dale Ragan, SAP Concur Technologies

Critics were more cautious. A corrupted or out-of-sync state file could lead to destructive outcomes — including accidental deletion of infrastructure with a single command.

“Terraform is scary, because if the state is incorrect, you can destroy your entire organization’s infrastructure with a single command. Stateless has always been the preferred way to manage configuration, from CFEngine to Puppet, to Chef and to Ansible; Terraform broke away from this and tries to sell it as a feature.”

Joaquin Menchaca, goBalto Inc.

The mitigation, according to practitioners who had adopted Terraform at scale, was modularization. A well-structured, modular Terraform configuration limits the blast radius of any single operation — a monolithic configuration is far more vulnerable than one broken into composable, independently managed modules.

Where Terraform Fits — and Where It Doesn’t

The consensus among practitioners at the time was that Terraform was not a wholesale replacement for Chef, Puppet, or Ansible — it occupied a different part of the stack. Terraform excelled at provisioning and managing cloud infrastructure: spinning up VPCs, compute instances, DNS records, load balancers, and similar resources. Configuration management tasks — installing packages, managing services, applying OS-level configuration — remained the domain of Chef, Puppet, and Ansible.

“You could call Terraform a subset of Chef, Puppet and Ansible. It’s a tool people like to get infrastructure up quickly, cloud-agnostically, without having to build out all the other stuff those other products necessitate.”

Brandon Cipes, cPrime

In practice, many teams used Terraform to provision infrastructure and then handed off to Ansible or Chef for configuration management — combining the strengths of each tool while accepting the overhead of maintaining expertise across multiple systems.

Key Takeaways for IaC Practitioners

• No single tool does everything. Most mature DevOps shops combine IaC tools, using each where it fits best. Plan for multi-tool complexity from the start.
• CloudFormation’s ubiquity matters. Even if your team prefers other tools, understanding CloudFormation remains important for communicating infrastructure intent within the AWS ecosystem.
• Ansible is approachable, but watch the gaps. Its YAML syntax integrates well with application code, but container support and specific integration areas may lag.
• Terraform’s pre-1.0 releases carry real risk. Breaking changes between minor releases require disciplined upgrade processes and thorough testing before applying to production state.
• Modularize Terraform configurations early. Monolithic configurations amplify the risk of state-related failures. Decompose infrastructure into small, independently managed modules.
• State management is a first-order concern. Whether you store Terraform state in S3, Terraform Cloud, or another backend, ensure it is versioned, locked, and backed up before operating at scale.