Adding an API to networking hardware doesn’t solve management challenges
A former Cisco engineer turned SDN pioneer, writing in The Register, argues that simply bolting an API onto networking hardware fails to solve the underlying difficulty of managing large networks, because the real obstacle is inconsistency between devices rather than a lack of programmatic access. The piece stems from feedback on a draft of the seventh edition of the textbook "Computer Networks: A Systems Approach," which prompted the authors to acknowledge that their view of network operations had been shaped mainly by cloud-operator practices rather than those of traditional network operators.
The author draws on personal experience, including a 2011 move from Cisco to SDN startup Nicira, to illustrate how feature sets vary wildly not just between vendors but across a single vendor's own product lines. As evidence, they point to the NAPALM automation project, which supports five vendor operating systems (three from Cisco alone), yet even devices sharing the same OS can implement identical features differently. Efforts at Cisco to standardise features such as QoS and MPLS achieved only moderate success, hampered by product teams' incentives to differentiate their offerings — an example of Conway's Law, whereby a company's products mirror its internal organisational structure.
In short
- APIs alone don't fix networking hardware's inconsistent management challenges.
- NAPALM tool highlights huge feature variation across and within vendors.
- Cisco's QoS/MPLS standardisation efforts were only moderately successful.
Steelman: both sides, in good faith
The strongest fair case each way — we don't pick a winner.
The case for
Programmatic access through APIs is foundational to any modern management approach, and whilst consistency across vendors would be ideal, APIs enable intermediate solutions in the real world. Tools like NAPALM exist precisely because APIs allow abstraction layers to be built atop inconsistent implementations, hiding vendor differences from operators. Without APIs, management cannot scale or automate at all; with them, operators can deploy orchestration frameworks and standardised workflows despite underlying device variation. This represents meaningful practical progress even if not a complete solution.
The case against
APIs are merely a technical conduit and do not address the genuine obstacle: inconsistent device behaviour driven by vendor incentives for product differentiation. An API to an inconsistently-behaving device is functionally less valuable than consistent implementation across devices, since operators must still understand each device's unique quirks and limitations. The burden of managing inconsistency simply shifts from network configuration to API consumption, and tools like NAPALM reveal how much extra work is required to abstract over these differences. Until vendors align on consistent feature implementation rather than racing to differentiate, APIs remain a partial solution leaving operators wrestling with unnecessary complexity.
Explained simply
Software-defined networking (SDN) uses software to configure and manage network equipment, while an application programming interface (API) lets software communicate with a device. These tools can automate routine tasks, but network equipment has often been built in separate product lines, each with its own capabilities and ways of working.
Cisco is a major maker of networking equipment, and Nicira was an early SDN company. Network automation projects such as NAPALM try to manage equipment from different vendors through common software, but the same feature may behave differently across models, even within one vendor’s range. This makes it harder to manage a large network consistently.
The issue matters because large organisations need their networks to work reliably across many devices. Differences in how products are designed and developed can limit what software control can achieve, so adding a way for software to reach a device does not by itself make the devices behave alike.