Why Network Ops Remains the Unsung Hero: Pain Points and the Future of SDN

1. Persistent Pain Points in Network Operations

1.1 Operations Are Not Trivial

Network operations have long been marginalized, often labeled as "back‑log" work and considered a low‑productivity role within both industry and large‑scale ops teams.

Discrimination manifests as jokes about "network not strong enough" and a hierarchy where application developers look down on product engineers, who look down on system administrators, who look down on network engineers, and so on.

Key questions arise: What does a network engineer actually do in an internet company, and what are the enduring challenges of the profession?

Architects must constantly balance scale, efficiency, and cost, while staying aware of trends in IDC, structured cabling, chips, CPUs, and storage.

Possible outcomes of a full regional network outage in Beijing: Earthquake Network engineer made a change

Human‑induced network incidents are always significant, and hiring "reliable" engineers does not eliminate bugs; all software and all human actions eventually fail.

Repeating tasks should be automated, but automation must not devolve engineers into mere script writers.

2. Data‑Center Network (DCN) Pain Points

From an ops perspective, DCN complexity stems from the scale‑effect of massive device fleets.

Core issues include ensuring safe daily changes, large‑scale deployments, rapid fault isolation, and effective traffic isolation.

Current problems: network visibility is limited to switch ports, while NICs and kernel behavior remain opaque, and silent packet loss persists.

Fault‑pre‑plan templates become philosophical dilemmas when massive alerts arrive, making it hard to decide which plan to execute.

Ops engineers should prioritize isolating faults and restoring services over lengthy root‑cause troubleshooting; mature companies should even eliminate the role of a "Chief Troubleshooting Officer".

Cost debates often ignore the hidden operational expense of non‑standard architectures; savings in hardware must be weighed against increased ops overhead.

Legacy issues such as TCP incast buffer sizing have become pseudo‑problems as software tuning reduces their impact.

DCN now faces a rigid demand for network virtualization, driving new technical requirements.

3. Data‑Center Interconnect (DCI) Pain Points

DCI challenges revolve around change management, cost, and skill‑set barriers.

Unlike application A/B testing, backbone networks lack shadow environments for safe testing, making large‑scale changes risky.

Attempts to visualize network‑wide data via big‑data analytics often prove superficial; alarm fatigue does not guarantee predictive accuracy.

Core‑network ops are high‑risk; high‑impact changes are frequently delegated to junior staff or vendors, leading to configuration bloat (e.g., excessive ACLs or BGP communities).

4. Inherent Network Limitations

Historical design choices have left the network with many "original sins": static routing, lack of plug‑and‑play, and limited visibility into business‑level traffic.

Attempting to align the network too closely with business workloads, especially for DCI backbones, is misguided.

Internet backbone and DCI backbone have fundamentally different characteristics; applying DPI‑style monitoring from the Internet to DCN/DCI is ineffective.

Routing protocols have seen little breakthrough in two decades, making them a lagging productivity factor.

New distributed self‑routing, self‑converging protocols have reached their limits.

Future network architectures must move beyond traditional Internet routing models.

5. Reflections on SDN

After reviewing network protocol shortcomings and operational pain points, the author asks whether a solution exists.

5.1 What Does the "S" in SDN Stand For?

Software : forwarding decisions driven by users rather than RFC routing protocols.

Service : business‑driven network definitions.

SLA : focus on business continuity instead of merely achieving "nine‑nine" availability.

Infrastructure reliability cannot be achieved solely by redundancy; the goal should be continuous business service.

5.2 What Does SD‑WAN Bring to Users?

Raw connectivity

Rapid connectivity

Customizable rapid connectivity

Visibly managed, customizable connectivity

Seamless, ubiquitous connectivity akin to oxygen

SD‑WAN also enables carriers to evolve legacy services (MPLS/VPN, VPLS) into software‑defined, on‑demand, API‑driven offerings.

5.3 What Does SD‑WAN Offer Infrastructure Operators?

The author's company, Dahe Cloud, offers a proprietary SD‑WAN solution built on the CanalOS platform, shifting WAN optimization from isolated, manual processes to a globally coordinated, algorithm‑driven control plane.

5.4 From Traditional Networks to SD‑WAN

Commercializing SD‑WAN is challenging: open‑source stacks can be opaque, development effort is high, and operational transformation is painful.

Beyond technology, a community of passionate network engineers strives for "Network for you, not you for network", pushing SDN as the catalyst for cloud‑computing evolution.

In this rapidly evolving era, the network community awaits the next breakthroughs.