A Cloud-Native NOS, at last!

It’s day 2 of #NFD20 here in San Jose (CA), and the weather outside is dreadful (not really the sunny California you usually picture).
Inside the meeting room where the magic of Networking Field Days happens, it’s a very sunny day.

After many months of mystery, Snaproute finally announced their CN-NOS (Cloud Native NOS) and gave the first public demo to the tough audience of NFD today.

Head over to this link to see the recorded session: https://techfieldday.com/appearance/snaproute-presents-at-networking-field-day-20/

I had the opportunity of seeing a preview of that a few months ago, but I had to keep my mouth shut, at least before the GA of their product, so here I am.

Firstly, let me say that Press Releases almost never do justice to what a product is really about, and I believe this is one of those occasions.

I will try to summarise that CN-NOS is about with some bullet points below:

• no re-invention of the network stack, but re-use of the Metaswitch network applications (powering several platforms sold by other ODMs);
• all-is-a-container, nothing revolutionary here, as this is where most of the NOS players seem to be steering towards;
• everything is Kubernetes-API-centric. Now this deserves an explanation.
  We’ve said that everything (all network daemons and functions) are containerised. Well, having containers means that a natural choice to manage the lifecycle of those is Kubernetes.
  What Snaproute did was brilliant, in that they extended the Kubernetes API with a very powerful feature of K8s: the so-called CRDs (Custom Resource Descriptors).
  The result is that you can operate a network device (configure/get data/etc.) using the Kubernetes API.
  For the CLI lovers out there, yes, you can have a CLI, which is nothing but a wrapper around the Kubernetes API, which is the king of the hill here.

Breaking the wall between NetOps and DevOps is the mission of Glenn, Adam and their crew, which is more a cultural problem rather than a technical one IMHO.
Certainly, what they did is a great step to draw network engineers towards a new “network language”.

Looking forward to putting my hands on the product and taking it for a spin.

I picked up an interesting tweet during the presentation:

Not FUD throwing, but does @snaproute expect network engineers to learn linux, Docker and k8s to manage the switch? #NFD20

— Pete Lumbis (@PeteCCDE) February 14, 2019

I really think this is the core of the problem of our times. I am not a traditional network guy, nor a DevOps/software guy. I don’t like labels to be honest 🙂

What I really believe though, is that I am sick and tired of this network vs. non-network debate. You either love technology or you don’t. And if you do, you are eager to learn new things, even though you don’t know if they don’t apply to your business. (you need to learn what those are about before you can actually tell)

Kubernetes, for me, was one of those things. And if you’re a network engineer, you cannot not love and be captivated by the complexity of K8s networking. So, yeah, K8s needs a lot of network love.

The next question for me would be: who will survive the fierce war of NOSs? There is at least a dozen of players out there, some new, some less. I believe that the market leftovers from the big 3 (Cisco/Arista/Juniper) are not enough to justify and keep all those ventures afloat.
The next 6 to 12 months are going to be REALLY interesting to watch.