Why Adding an API to Switches Won’t Fix Network Ops Headaches

The authors argue that simply exposing an API on networking gear does not resolve the deeper management problems that stem from inconsistent device features and legacy CLI reliance.

In a recent commentary, the authors reflect on feedback to their textbook chapter about network operations, noting that their cloud-focused perspective differs from conventional networking practices. Their time at Cisco revealed how varied feature sets and inconsistent implementations across even a single vendor’s products hinder automation tools like NAPALM. An effort in the late 1990s to add a programmable API to routers collapsed because every new feature still had to be exposed via the CLI, which product teams were reluctant to support.

The piece cites Scott Shenker’s call for better network abstractions and describes how Nicira’s virtual-switch model, paired with a central SDN controller, sidestepped many physical-device issues. However, adoption was limited by the immaturity of cloud management platforms such as OpenStack at the time. The authors now emphasize open standards like OpenConfig and YANG, which align more closely with hyperscale operators, while acknowledging that traditional operators need broader guidance.