Senior DevOps Engineer Darian Vance explains why “big tech” often moves beyond CLI-based tools like Netmiko, exploring the critical shift towards API-driven network automation, IaC principles, and custom-built tooling for hyperscale environments.

So, Do “Big Tech” Engineers Actually Use Netmiko? A View from the Trenches

I still remember the 2 AM page. A routine deployment had knocked over half of our e-commerce checkout service. The culprit? A tiny firmware patch on a legacy load balancer. The patch changed the output of a show health command from “Status: Active” to “State: Active”. Our Python deployment script, which used a library just like Netmiko to scrape that CLI output, was looking for the word “Status”. It didn’t find it, assumed the node was dead, and yanked a perfectly healthy, traffic-serving appliance out of the pool. That night, I learned a visceral lesson about the fragility of building automation on top of interfaces designed for humans, not machines. This whole debate isn’t about one library being ‘good’ or ‘bad’; it’s about managing risk at scale.

The Core of the Problem: Human vs. Machine Interfaces

Let’s be blunt. Tools like Netmiko and Paramiko are brilliant pieces of engineering. They solve a very real problem: how do you automate a device whose primary interface is a command-line interface (CLI)? They act as a robotic sysadmin, logging in via SSH, typing commands, and then “scraping” the text output to figure out what happened. For years, this was the only way.

The fundamental issue is that CLIs are a user interface (UI), not an application programming interface (API). They are designed for a human to read. Their output can change between firmware versions, they lack structured data (good luck parsing a BGP table with regex), and ensuring a command is truly idempotent (running it twice has the same effect as running it once) can be a nightmare. At big tech scale, where you have tens of thousands of devices, “nightmare” scenarios become statistical certainties. You can’t build a reliable, self-healing system on a foundation of parsing text.

Three Tiers of Network Automation

So, what’s the reality in a modern tech company? It’s not a simple “yes” or “no”. We operate in layers, and you choose the tool that fits the layer you’re working in. Here’s how I see it.

Solution 1: The Pragmatist’s Toolkit – Embrace the Shim

This is the “get it done” approach. Do we use Netmiko or similar libraries? Absolutely. I have a legacy firewall, prod-fw-cluster-01, that’s critical to the business but has a laughable REST API. Its most reliable interface is the CLI. For a task like pulling a specific NAT rule to verify a change, a simple Netmiko script is the fastest, most reliable way to get what I need.

It’s a “shim”—a layer of compatibility that bridges the old world with the new. It’s not the future, but it’s a necessary tool for dealing with the present and the past. You use it when you have no other choice.

# Quick and dirty, but it works for that old ASA
from netmiko import ConnectHandler

device = {
    'device_type': 'cisco_asa',
    'host':   '10.1.1.254',
    'username': 'darian',
    'password': 'your_secure_password',
}

with ConnectHandler(**device) as net_connect:
    # CLI command is the source of truth here
    output = net_connect.send_command('show running-config object id my-nat-object')
    print(output)

Pro Tip: When you’re forced to use CLI scraping, keep it simple. Don’t build complex application logic around it. Use it for data gathering or simple, well-understood commands. The more complex your parsing, the more likely a firmware update will break your night.

Solution 2: The Architect’s Choice – Treat Your Network as Code (IaC)

This is where “big tech” wants to live. Modern network devices from vendors like Arista, Juniper, and even modern Cisco gear have robust, first-class APIs like NETCONF, RESTCONF, or gNMI. These are true APIs. You send structured data (like XML or JSON), and you get structured data back. The operations are transactional and idempotent.

Here, we don’t use Netmiko. We use tools like Ansible (with vendor-supported modules), Terraform, or our own internal Go/Python services that speak directly to these APIs. The goal is a declarative state. We define *what* we want the network to look like in a YAML or HCL file, and the tooling makes it so. This is how we manage thousands of switches in our data centers.

# A declarative Ansible approach - no CLI scraping!
- name: Configure VLANs on our datacenter switches
  hosts: dc1-leaf-switches
  tasks:
    - name: Ensure desired VLANs are present
      cisco.nxos.nxos_vlans:
        config:
          - vlan_id: 100
            name: WEB_TIER
          - vlan_id: 101
            name: APP_TIER
        state: merged # Idempotent - only adds if missing

Solution 3: The Hyperscaler’s Reality – If It Doesn’t Exist, Build It

This is the ‘FAANG’ option. When you operate at the scale of a Google, Meta, or Amazon, you often find that off-the-shelf hardware and software can’t meet your needs. These companies design their own network hardware (white-box switches) and their own network operating systems (like Facebook’s FBOSS). Naturally, off-the-shelf automation libraries won’t work.

In this world, teams build their own highly-customized, internal configuration management and telemetry platforms from the ground up. These systems are deeply integrated with the custom network OS. An engineer doesn’t SSH to a box; they make a change in a git repo, which triggers a CI/CD pipeline that calls an internal API to safely deploy the new configuration across an entire global fabric. Netmiko doesn’t enter the picture because the CLI is an emergency fallback, not a management interface.

Comparison Table

So, What’s the Verdict?

Do big tech engineers use libraries like Netmiko? Yes, but only when we have to. It’s a tool in the toolbox, but it’s the wrench we reach for when the fancy API-driven power drill won’t fit the bolt on that rusty old piece of equipment in the corner. Our goal, our architectural direction, is always to move up the ladder toward fully declarative, API-driven systems. Because nobody wants their service to go down at 2 AM over a single word change in a log file.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions