SDN APIs & The Next Wave Of Innovation

10 Powerful Facts About Big Data

As SDN technology matures, the conversation is moving away from subjects such as OpenFlow and VXLAN and toward APIs. APIs have emerged as a key component because they provide a standard mechanism for third-party devices and applications to interact with an SDN controller, and they do useful things, such as spin up a service or get access to network resources.

But if the industry is rolling out standardized APIs and vendors are integrating with said APIs, how does one vendor claim to be different from another vendor? Won't products simply become homogenous and interchangeable?

To get to the answer, let's take a trip to the early days of local area networks. Back in early 1980s, one way that vendors tried to differentiate themselves from competitors was through the use of underlying protocols for network communication, including Token Ring, ARCNET, FDDI, and Ethernet. Every vendor argued that its protocol was the better solution.

[It's all about speed. See IT Innovation At Full Speed: InformationWeek Video.]

As we know, Ethernet eventually triumphed. Yet despite the broad standardization of Ethernet, there were (and are) significant differences among switches from one vendor and another. Simply put: Just because the rules of low-level networking became homogenous didn't mean all networking equipment was the same.

The standard is the outer edge by which the devices communicate, but the value is in what those devices do once they have the packet.

Now substitute APIs for Ethernet and move the clock forward to 2014. We find ourselves in a similar situation; the APIs may be en-route to standardization, but the APIs won't define what can be done. Each product will still have its own story to tell.

Consider Cisco ACI. Recently, Cisco made some new announcements around its ACI product strategy and automation with its APIC software. During one of the keynotes, an ACI executive pulled up a demo showing the kinds of automations that partner vendors had put together. In particular, he pulled up examples of load balancers. On the screen, you could see one partner had done 13 different things and the other did four.

The demo held a subtle but important comparison: There might be a standard in place for how automation integration will work between Cisco ACI and Cisco's partners, but within that standard there is a lot of room for differentiation -- much like how the Ethernet standard still leaves room for differentiation on features, speeds, operations and management, price, and more.

A standard is simply the rules of language. How we interpret and act on the words communicated is where the interesting bits lie. As we wrap our heads around SDN, APIs, and emerging standards we need to keep this in mind.

Standards do not create homogenous, interchangeable products -- they enable innovation at other layers of the stack.

Network engineers need broader expertise for their careers to thrive in the coming software-defined networking era. Also in the new SDN Careers issue of Network Computing: Don't be a networking dinosaur.