Why your network operating system needs a new architecture
Today we are launching the industry’s first Cloud Native Network Operating System. CN-NOS is built from the ground up on a fully containerized microservices architecture – to accelerate application time to service, assure security compliance at all times and simplify run time operations. SnapRoute is delivering disruptive innovation for the Cloud Native era with the first meaningful advancement in network operating system architecture in over 30 years.
One could say that networking has undergone many radical and revolutionary changes over the course of the last 30+ years, since the initial development of the first network operating systems in the mid-to-late 1980s. But has it? If you wind the clock back to the time of miniskirts and muscle shirts – you will find an experience that would not be out-of-place in most network teams today.
Early network operating systems were:
- monolithic – meaning that they are packaged and delivered to the user as a single binary “blob” – with code updates and features delivered all-at-once
- proprietary – each vendor has their own way of configuring and managing the device – with no portability of configuration
- obfuscated – there is no insight to the underlying operating system or kernel that resides below the user interface
- unique – requiring users to treat network devices as appliances – since the operating principles from compute teams could not be leveraged
- difficult to automate – with total reliance on a CLI, automation is limited to the abilities of a script to run commands and parse the output – commonly known as “screen scraping”
All of this is still true today!
Even though some advancements have been made to ease the operational pain of managing networks assembled from these single-purpose appliances, running archaic monolithic architectures – innovation is still stagnant. Most of the focus over the last several decades have been on either improving the speed and convergence of the underlying protocols that make up the network, the bolting on of network-centric management plug-ins, or the adoption of complex overlays to get around the inflexible nature of the network.
These advancements are fine in their own right, but they do not address the core issues that cause operational pain for the brave souls that actually have to run a network. These network engineers do care about the number of milliseconds that it takes for BGP to converge or the delay introduced by hundreds-of-thousands of routes being programmed into hardware – but only to a point!
As an industry we have finally arrived at the point where the focus can shift from rewriting the core protocols, bolting on more plug-ins to proprietary management tools, and using overlays as an enabler for letting NetOps and DevOps give each other the silent treatment.
There is a better way!
At SnapRoute, we believe the only way that you are going to solve the operational issues that are faced by today’s operators, is with an entirely new approach to the network operating system – one that is built on the principles of microservices and containerization, leveraging the latest advancements in DevOps trends and Cloud Native tools. The monolithic approach to networking is flawed and a new architecture is needed.
Today we are proud to launch the Cloud Native Network OS or CN-NOS into the world. CN-NOS is the culmination of everything that we, the SnapRoute founders, have learned from our operational experience running hyperscale networks.
With CN-NOS we have incorporated three key tenants into the modern Cloud Native architecture:
- Fully containerized OS using Docker
- Kubernetes core for orchestration
- Integration of 3rd party protocol stacks
Why use Docker? Because it is currently the de facto standard for container run-time environments, with a strong ecosystem of community support and engagement. With all of the system processes, protocols, and hardware abstraction layers microserviced – it became critical for us to standardize on a way to manage all of these containers. For this, the choice was clear in Kubernetes.
With ever wider adoption and the strong backing of hyperscale operators Kubernetes is a tidal wave in the DevOps and Cloud Native spheres – leading to its adoption as the gold standard for deploying distributed systems, in the same way that Linux is the standard operating system for hyperscalers and enterprises alike.
With CN-NOS we have taken the very best of Kubernetes and integrated it directly and natively into the infrastructure core of the network operating system. Kubernetes fully optimized for managing network primitives on an embedded system is used as the orchestration core that manages all of the underlying containers. Using Kubernetes in this way – on an embedded system, with no need for an external controller and representing and controlling network devices natively are key innovations that SnapRoute has built atop Kubernetes.
The benefits of such a Cloud Native approach are felt by both DevOps and NetOps team in meaningful ways.
DevOps team gets to interact with the network in a way that has never been possible before:
- with the direct usage of kubeapi – with no need of an abstraction layer to configure and automate the network
- use the same tools and best-practices that have been built around Cloud Native deployments to manage the network
- treat the network the same as they would any other piece of the infrastructure.
This is, of course, a big deal – and the importance of elevating networking to the same level of operational efficiency as compute and storage cannot be overstated.
Enabling DevOps to take control of the network needn’t leave the NetOps teams out in the cold – they too can experience the benefits of a network OS that is built from the ground up with Cloud Native principles baked in.
With CN-NOS, NetOps team can build credibility with their DevOps teams by:
- deploying only the microservices that they require – leaving unnecessary features off the device – limiting feature bloat, simplifying troubleshooting, reducing blast radius, and limiting security vulnerability attack vectors
- performing true hitless upgrades by embracing the immutable infrastructure of microservices and containerization…need a new version of BGP? – load the new container and swap it out – leaving the full data plane and other system components unchanged and unaffected
- leveraging a well-known and comfortable industry-standard CLI that abstracts away the necessity of speaking the Kubernetes and Cloud Native languages to benefit from an architecture that isn’t a monolithic binary blob
Finally, with CN-NOS we are doubling down on the notion that the problems faced by modern NetOps teams are not going to be solved by rewriting the routing protocols that make up the core of their infrastructure. Shaving milliseconds off of the convergence time for a handful of prefixes is great – but it doesn’t solve the day 2 operational challenges that folks face. We know from experience, in both running hyperscale environments and in speaking to countless operators – that most users consider the network protocol stack to be a commodity. At this point, investing more time in rewriting the control plane will have diminished returns.
This core belief has enabled us, at SnapRoute, to adopt the model of the network operating system as a platform. With CN-NOS we containerized and sandbox the control plane stack – giving ultimate control and flexibility to the operator. With our initial GA release, we are standardizing on a well-respected commercial supplier of routing software. In future releases, we are going to integrate more control plane stacks – both commercially available and open source options – allowing operators to choose the stack with the scale and features that best meet their needs.
Run only what you need, where you need it, using APIs and CLIs where appropriate are the key take-aways to understand what we are making possible with CN-NOS.