The current generation of network operating systems are general purpose, multi-function and non-specific. Customers routinely deploy the same vendor operating system for the campus, data centre and WAN hardware to have a consistent experience.
In a strange quirk of human nature, this is often regarded as a “feature” because vendors software CLI is badly designed & implemented. Everything operates in a continuous quirks mode and needs years of specialist training to understand obscure syntax, design logic. A great deal of operational time is wasted on pointless CLI tasks and consistency becomes a critical issue while ignoring the underlying problem.
When the Network Operating System (NOS) becomes independent of the hardware, we can expect to see specialist NOS for specific markets in the same way that other software companies do. This is already happening today with Arista EOS, Cumulus Linux and Big Switch Lite targeting data centre.
Possible Use Cases:
- Campus-centric NOS could be a cut-down software image that has only the functions needed to run a simple Ethernet backbone using 802.1BR and ECMP.
- Advanced Campus-Centric NOS includes User Authentication e.g. EAP, Flow Monitoring (sFlow, NetFlow)
- Data Centre NOS customised for ECMP L3 Backbone removing all legacy software for reliability, reduce CPU/Memory footprint.
- WAN NOS that implements SD-WAN functionality inside containers. Comprehensive WAN features with support for containers and VMs for NFV functions such as branch IDS/Proxy/Firewall and telephony services.
Problems of General Purpose NOS
- Bigger software simply has more bugs
- bloated code has complex interaction bugs that are hard to find and fix.
- more testing is needed to attempt to find bugs which increases cost of software to customers. Alternately, some vendors transfer bug finding to their “tech support” to keep profits high.
- Large code bases means the release schedule is slow & ponderous requires all features to be complete and tested. This created longer lead times on releases (which then creates big releases, internal politics on which features should and creates buggy releases)
- Architectural defects by attempting to achieve everything.
- limited features is less bugs.
- replace the NOS to have different or more features. This is hard with custom NOS because of low quality boot software and variety. Its not hard with ONIE.
- less CPU/Memory – either cheaper hardware or capacity for on-board applications.
cost factors – a limited feature set should be cheaper to develop and cost savings should flow to the customer
The EtherealMind View
Looking at the current market for networking products its clear that multiple operating systems is successful. For example, Cisco has many different operating systems on active support. There IOS Classsic, IOS-SX, IOS-XE, IOS-XR, NX-OS are just a few and there are many variants inside each one. Juniper has a consistent interface around Junos and common core but the operating systems vary a great deal (but all based on NetBSD)