Last week I was chatting with our CEO Steve Mullaney as he animatedly described the challenges he faces getting "traditional networking" people to understand what it is that Nicira does. He's not alone in this - I've heard similar things from CTO Martin Casado and Marketing VP Alan Cohen as well. In fact, it's probably no co-incidence that a large percentage of the engineering ranks at Nicira come from some field other than networking - distributed systems and operating systems people are especially well represented.
That led me to wonder why it was that Nicira's product and value proposition made sense to me the first time Martin explained it to me. So much sense, in fact, that I left my comfortable position in a traditional networking company after 16 years to join Nicira.
Part of the answer, I think, is that there are a few different ways to look at networking, and the only one that has ever made sense to me is the "Systems Approach". Since 1995, I've collaborated with Larry Peterson - who comes from a distributed systems background himself - on many editions of a computer networking textbook called "Computer Networks: A Systems Approach". We go to some lengths to explain what the Systems Approach is, but to me it's mostly about solving problems by looking at all the components of a system, and thinking about how they interact with each other to solve the problem efficiently. One important aspect of this approach is that you need to think carefully about how to assign functionality among components. The matter of whether reliable delivery should be performed at the link, network, transport, or application layer is a classic example of the sort of question that systems thinkers need to tackle.
In some sense, the Systems Approach stands in contrast to the standard "layered" model of networking, most often taught as the 7-layer OSI model. The layered model encourages you to think about one layer at a time in isolation of the others. That can be a helpful way to learn basic concepts, but layered thinking often leads to designs that may optimize one layer, and yet don't work well in optimizing system behavior. (How useful is it to build reliable delivery into the network layer if the transport layer needs to do it all over again? Or if the application needs timely delivery more than it needs reliability?)
All this led to the idea that maybe too much layered thinking is the problem with understanding what Nicira does. The problem we are trying to solve is to virtualize networks just as completely and effectively as hypervisors have virtualized computation. So some people look at our product and say "oh, I see, you're running L2 over L3". That is such layered thinking.
What Nicira's Network Virtualization Platform actually does is to enable virtualized networks to be built and operated on top of physical networks - just the same way a hypervisor lets you run virtual machines on top of a physical machine. Sure, if all you need is an L2 network to connect up your servers, we can do that, but how many networking problems are solved simply by running L2 networks? And didn't we figure out that L3 networks are more scalable than L2 a few decades ago? Just as a hypervisor fully and faithfully reproduces all the capabilities of a physical machine for the guest OS, so must a proper network virtualization solution fully and faithfully reproduce all the features of a physical network. Those features include access control lists, firewalls, monitoring features, and on and on.
I was tempted to call this post "Layered networking considered harmful" but that is both too strong (layers are a useful way to understand a system once it's been designed) and beside the point. We are all about solving problems involving complex systems - the multi-tenant, virtualized data centers of our customers - and we do that using a systems approach. If you understand that network virtualization is about building fully featured networks that are decoupled from the underlying physical hardware - not about putting one protocol layer on top of another - then that's a good start towards understanding what we do.
