Rethinking the Network

Michael Bushong

Subscribe to Michael Bushong: eMailAlertsEmail Alerts
Get Michael Bushong: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Cisco Virtualization Journal, Java in the Cloud, OpenStack Journal

Blog Feed Post

Networking Pidgin: The next step for abstractions?

There is a natural phenomenon that occurs when two groups lacking a common language come together. Essentially, the two groups construct impromptu a means of communicating. This new language pairs parts of the existing languages with new words, sounds, and body language. This new set of linguistic conventions becomes the primary means of communicating over time, allowing trade and exchange of information between the groups. This natural linguistic evolution creates what is called a pidgin.

There are lots of examples of pidgins, but the two that people are most likely familiar with are Hawaiian Pidgin (combining Hawaiian and English) and Louisiana Creole (English and French). Regardless of the languages of origin, pidgins have a common set of characteristics:

  • Uncomplicated clause structure (no nested clauses, for instance)
  • Reduction consonant clusters
  • Basic vowels like a, e, i, o, u
  • No tones
  • Use of separate words to indicate tense, usually preceding the verb (I done look would mean I had looked, for example)

These rules are all in support of simplification. The nuances of the languages are dropped in favor of a simplified, repeatable approach to communication. The result is something that sounds dumbed down to the casual listener. But that dumbing down was necessary to bring two uncommon languages together organically.

So how does this apply to networking?

One of the primary objectives of SDN is to make the network more tightly linked to the applications it serves. This might happen through service agility (automating workflows to shorten the time to provision a new service), or it might happen through the exchange of application requirements in more application-centric deployments. Whatever the exact manifestation, the question that often gets lost in the details is: How do the network and applications actually talk to each other?

To date, the answer is typically some derivative of There’s an API for that. But anyone who has worked with APIs knows that simply throwing up an interface does not mean that communication happens. If that API is too networking-centric, the application people are forced to either learn a new networking dialect or punt the work to the networking team. If the API is too application-centric, the networking people have to either learn application speak or they have to punt the work to the application team.

And the API discussion is really more about mechanics than communication. Sure, the API will ultimately relay information to parts of the system that request it, but it doesn’t necessarily define linguistically how the disparate entities ought to talk. So while product teams have been quick to solve the API problem, they have left the harder problem largely unaddressed. What we ought to be working more diligently on is the abstractions that allow the different groups to communicate. Put differently, we need to be creating our own networking-application pidgin.

But how do pidgins evolve? New languages need three things to evolve: necessity, proximity, and exposure.

There must be a need for the new language. When it is people, that need is typically trade. For IT, the need is driven by a shift from connectivity to experience. Tuning and ultimately guaranteeing application experience requires a common understanding of application requirements (likely in the form of SLAs). CIOs are well past the point that they can call out five 9s and declare success. There is clearly a need for something more.

Beyond need, the communicating partners must be in close proximity. For a language to develop, there has to be an interaction, which implies a physical proximity to each other. In the IT space, this proximity is likely defined at the intersection of infrastructure boundaries. Wherever a boundary exists, there is an interaction. These interactions define where and how language must evolve. In some cases, it might be the intersection of applications and networks, but there will also be similar boundaries between the network and storage, and the network and compute. This likely means that there is more than one pidgin that must evolve.

And finally, for a language to exist, there has to be prolonged exposure. A single interaction will not generate a pidgin. You need frequent contact over a sufficiently long period for a pidgin to emerge. Similarly, we should not expect that the relevant abstractions in networking will be formed after a coarse exchange of requirements. The reality is that these things take time – they are evolutionary. We need experience and iteration to derive the right set of linguistics. It simply cannot be the case that a single company goes out and derives all the abstractions on their own. The multiple parties need to co-exist for these to fully materialize.

Given these requirements, we ought to be asking how we make progress as an industry. The need for contact and exposure suggests that abstractions are not going to be developed within yet another silo. So where are the natural points that disciplines come together?

Right now, I don’t think these venues exist for the most part. But I do think they are forming. OpenDaylight’s first incarnation seems to be mostly network, but I could reasonably see supporting infrastructure coming together. It would make sense, for example, for analytics companies to join the effort. It might make sense for storage controller companies to join early to resolve the controller-controller communication that will be a necessity in the not-too-distant future. There are already obvious tie-ins with OpenStack.

Beyond OpenDaylight, I think there could be similar hope for Big Switch’s Floodlight efforts. They are similar in concept to OpenDaylight, and so they should be looking to attract more members from the supporting areas. We might also see collaboration coming out of the NFV efforts, though those relationships would appear to be between network or cloud services and the supporting infrastructure. And as the ONF takes on northbound interfaces, there might be still more opportunity for prolonged interaction between networking and non-networking folks.

It is not immediately clear to me which efforts are most likely to yield positive outcomes. The best I can do is conclude that we need to be making more explicit efforts to get disparate groups to talk. Without this type of communication, the appropriate pidgins will not be able to emerge. And it feels like a natural evolution is far more likely to succeed than a mandated abstraction cast down from one vendor or even one group of vendors.

As a customer, this means that you ought to be getting plugged into the various points of communication convergence. These will be the most likely to deliver a set of abstractions that serve as a unifying force. So go and take a look at OpenDaylight, Floodlight, NFV, OpenStack, TOSCA, and others. It very likely will be that we are still a ways off from a networking-application (or networking-storage, networking-computer, and so on) pidgin. But if one is going to emerge, it is only going to happen where two groups come together, so being at that intersection puts you in the best position to shape and ultimately adopt the output.

[Today's fun fact: Elephants are the only mammals that can't jump. This is contrary to the Wesley Snipes & Woody Harrelson classic White Men Can't Jump.]

To read more on this topic, check out:

The post Networking Pidgin: The next step for abstractions? appeared first on Plexxi.

Read the original blog entry...

More Stories By Michael Bushong

The best marketing efforts leverage deep technology understanding with a highly-approachable means of communicating. Plexxi's Vice President of Marketing Michael Bushong has acquired these skills having spent 12 years at Juniper Networks where he led product management, product strategy and product marketing organizations for Juniper's flagship operating system, Junos. Michael spent the last several years at Juniper leading their SDN efforts across both service provider and enterprise markets. Prior to Juniper, Michael spent time at database supplier Sybase, and ASIC design tool companies Synopsis and Magma Design Automation. Michael's undergraduate work at the University of California Berkeley in advanced fluid mechanics and heat transfer lend new meaning to the marketing phrase "This isn't rocket science."