I think what SnapRoute is doing is the start of a fundamental shift in thinking about how network equipment, specifically data center switching and routing, should be deployed, managed and, more importantly, how they are classified. I believe they are the start of the transition where a managed resource in a data center is not something special but simply a compute object with different characteristics that can be assembled in a way that serves the purpose of the workloads that need to run in that data center.
For awhile now the push has been (for the networking industry anyway) scripting and automation working up to some sort of orchestration to make networking advance into the realm of cloud first or at least something a developer could code against. While this is important and will likely continue for the next decade or more it is far from the final goal of what a cloud first approach really entails.
Some in the industry are thinking the next evolution is intent based networking. Defining what you want to have happen and having the system orchestrate the outcome to match the intent. I actually consider that a big jump from where we are at today and companies like Apstra are trying to be an early market leader in that space. But I still consider that solution fundamentally orchestration and there are other methods and approaches out there that are just as valid but still only go up the stack as high as Level 3 (see the chart below).
I think a tweet from my friend Gian Paolo helps explain what is happening really well.
It is worth noting that this applies much wider than the networking industry overall. It seems what SnapRoute is attempting to do is the tooling for Level 4 and they are doing an end run around traditional networking tooling and methods. Instead, they have chosen to leverage cloud native constructs and tools to make networking adapt to those ethos instead. So, SnapRoute uses Kubernetes to run and deploy the resources on the Edge Core switches they support (more suppliers to be added, I imagine, depending on customer demand). Today, their solution runs on a single switch running Kubernetes but it is clear where their vision is going. A grouping of leaf/spine switches in the data center will be a Kubernetes Pod and likely Istio and Envoy will be used to expand the capabilities of what SnapRoute can do in that Pod. More importantly, a traditional network operator really has no choice but to learn cloud first methods and working with Kubernetes, Istio and Envoy are exactly the tools they must learn to make that transition.
I suppose the interesting question is, how is where SnapRoute going significantly different then where the networking market is currently going today? I think the simple answer is they are using the Cloud Native approach which really combines Level 2, 3 and 4 together. They get to avoid the incremental moves of the industry and have a first mover advantage, they are effectively leapfrogging several steps. This assumes they are able to pull off a Kubernetes Pod for the data center fabric but from what I can tell, it sure looks possible. What they are working on could really change the game for developers deploying in on premises data centers. They are worth keeping an eye on and seeing if they are able to make significant deals to help push their vision forward.- Ed