Silicon Valley investors have been characterized as lemmings charging towards the latest buzzword (defined as cliffs) with tribal abandon.  Trends I recall from the top of my head include RISC (reduced instruction set computers), client-server, PDA’s, browsers, search engines, java, security, appliances, managed services, Linux, virtualization, mobile applications, cloud, big data and the latest craze – Software Defined Networking (SDN).

Let’s look at the SDN cliff: Software Defined Networking has been recently (in the last 6 years) popularized by the Stanford/Berkeley OpenFlow project (Dr. Nick McKeown and Dr. Scott Shenkar).  The OpenFlow project was started to create an experimental network to facilitate applied research in networking.  You can learn about it with a free tutorial from: http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/MininetGettingStarted.

Software Defined Networking has existed much longer, in particular as ForCES – Forwarding and Control Element Separation spearheaded by Intel’s visionary Fellow Dr. Raj Yavatkar (see SDN:  ForCES vs. OpenFlow).

Lets get geeky for a second:  SDN’s basic idea is the networking version of microprocessors opening up the CPU market such that a single microprocessor could run different operating systems:  Unix, Windows and Mac.  In Software Defined Networking, instead of having 6 million lines of proprietary code in a router, you can have a switch executing forwarding rules defined in software.  The switch contains low cost merchant switching chips as opposed to proprietary and expensive custom router chips.   A network operating system can now manage the network under software control and applications can even access information from the network and impose requirements on the network.

So, what are the SDN killer benefits?  SDN gets lower cost networking in merchant hardware.   You can limit the size of the code and complexity of your switch by supporting only the protocols you need.  SDN opens up routing and switching to facilitate innovation in networking and on the Internet.  The Internet as it stands today, is closed to innovation with 6,200 RFC’s a router must conform to.

Request for Comments

From Wikipedia, the free encyclopedia

“In computer network engineering, a Request for Comments (RFC) is a memorandum published by the Internet Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.”

Through the Internet Society, engineers and computer scientists may publish discourse in the form of an RFC, either for peer review or simply to convey new concepts, information, or (occasionally) engineering humor. The IETF adopts some of the proposals published as RFCs as Internet standards.

Request For Comments documents were invented by Steve Crocker in 1969 to help record unofficial notes on the development of the ARPANET. They have since become the official record for Internet specifications, protocols, procedures, and events.^[1]

For instance, RFC 793, published in 1981,

describes the DoD Standard Transmission Control Protocol (TCP).  There were nine earlier editions of the ARPA TCP specification on which this standard is based, and RFC 793 draws heavily from them.

RFC 3748 describes the Framework for Forwarding and Control Element Separation, ForCES, one of the earliest efforts in Software Defined Networking.

Cost savings using cheaper SDN switches are important for Internet bandwidth providers, who are seeing global IP traffic growing at 40 to 50% while customers do not want to pay any more for connectivity.  Another term associated with the explosion of bandwidth worldwide is Big Data:

Big Data

From Wikipedia, the free encyclopedia

In information technology, big data^[1][2] is a collection of data sets so large and complex that it becomes difficult to process using on-hand database management tools or traditional data processing applications. The challenges include capture, curation, storage,^[3] search, sharing, analysis,^[4] and visualization. The trend to larger data sets is due to the additional information derivable from analysis of a single large set of related data, as compared to separate smaller sets with the same total amount of data, allowing correlations to be found to “spot business trends, determine quality of research, prevent diseases, link legal citations, combat crime, and determine real-time roadway traffic conditions.”^[5][6][7]

SDN – DISRUPTIVE TECHNOLOGY
SDN is truly a disruptive technology that promises cost and performance benefits.  It is buzzword worthy technology.

So what’s the problem?  In the competition to be recognized as a visionary in the Silicon Valley fray, the elephant in the room is eclipsed by the glare of hubris.  In the case of SDN, the obfuscated pachyderm is the lack of SDN standards or even an agreed upon definition of SDN.  Software Defined Networking is barely defined and definitely not ready for prime time.  In an interview by Matt Palmer posted on SDN Central: Amit Agarwal, Product Manager at Google with the Platforms team states:

“OpenFlow as a protocol is still barebones and in its infancy. There is ongoing work in adding more features and capabilities and enhancing the protocol. Some of these have been incorporated in subsequent versions and others are being actively discussed at the Open Network Foundation (ONF)*.  However, even in its current state OpenFlow is good enough for many use cases, such as, Google’s WAN deployment shows.”

A more general answer can be found in the book “Crossing the Chasm:  Marketing and Selling Disruptive Products to Mainstream Customers” by Geoffrey Moore. Early markets for disruptive product consist of Innovators and Early Adopters.  They are interested in the technology.  Innovators may pick up a technology from open source research code, before any products are available.  Early adopters want an early version of a product, known as the generic product, and a value proposition.

The main chasm is a disconnect transitioning from Early Adopters to the mainstream Early Majority, Late Majority and Laggards.   Moving from the former to the latter, customers in the mainstream market become much more risk averse.  They want to see a stable company, reference customers, a complete product, established standards and multiple vendors and services (consultants, VAR’s, interoperable complementary products).  A great summary of the book “Crossing the Chasm” by Mike Lee illustrates the chasm and the challenge:

The High-Tech Marketing Model

“The way to develop a high-tech market is to work the curve left to right, focusing first on the innovators, growing that market, then moving on to the early majority, growing that market, and so on… In this effort, companies must use each ‘captured’ group as a reference base for going on to market to the next group. Thus, the endorsement of innovators becomes an important tool for developing a credible pitch to the early adopters, that of the early adopters to the early majority, and so on.”

Illusion and Disillusion: Cracks in the Bell Curve

However, the High-Tech Marketing Model is not accurate. A more accurate model is this revised Technology Adoption Life Cycle. “Between any two psychographic groups [are] gaps [that] symbolize the… difficulty any group will have in accepting a new product if it is presented in the same way as it was to the group to its immediate left.”

• The First Crack

This is the gap between the innovators and early adopters. It “occurs when a hot technology product cannot be readily translated into a major new benefit.”

• The Other Crack

This is the gap between the early majority and the late majority. “When a product reaches this point in the market development, it must be made increasingly easier to adopt in order to continue being successful.”

• Discovering the Chasm

This is a wide chasm between the early adopters and the early majority. It often goes unnoticed because “the customer list and size of the order can look the same”, though “the basis for the sale… is radically different.”

Even though the Chasm is a well-understood model, entrepreneurs and investors can be more reality challenged than informed risk takers.  They are aided and abetted by marketeers and analysts who get paid mostly when there is (allegedly) a product or company to sell.  Hence, the reality based market life cycle defined in Crossing the Chasm becomes the siren call to unsafe precipices known as the Gartner Hype Cycle consisting of:

• Technology trigger
• Peak of Inflated Expectation
• Trough of Disillusionment (aka “The Chasm”)
• Slope of Enlightenment
• Plateau of Productivity

A blog post by Mike Oda illustrates the relative position of Big Data and SDN in the Gartner Hype Cycle.

Hype Cycles for Big Data and Software Defined Networking

Big Data is overhyped and about to fall from media attention.  Software Defined Networking (SDN) is on the rise.

The media is looking for actual Big Data deployments in the enterprise.  With a pack of companies pitching the vision for Big Data, media are looking for real-world examples that aren’t at a humongous company like Google and Yahoo.  These are great examples, but they’re too big for the average enterprise to relate to.

In the meantime, the new kid on the block is SDN.  It’s hot with tremendous potential, but limited numbers of deployments, even less than Big Data.  However, the vision is seductive and the media will pay attention to the great change in data center networks that SDN will one day bring about.

A friend of mine recently pointed me to a presentation that John Vrionis gave at the Open Networking Summit in April.  John’s a partner at Lightspeed Venture Partners and pays attention to things like hype versus value.   John’s presentation contained a slide on the Gartner Hype Cycle for Big Data and Software Defined Networking (SDN).   I included his slide from Gartner above.

I have been following SDN for 3 years now and can offer some lessons learned for entrepreneurs, technology enthusiasts and early adopters interested in this promising, emerging technology:

1. No one is suggesting that you rip out your existing network infrastructure and replace it with SDN switches.  If you want to kick the tires – pick a test, pilot or new deployment to start with.  You will be getting a generic product – and a production deployment will require that you write and maintain any code you need that is not yet available.
2. Most, if not all, current vendors are offering hybrid solutions:  traditional networking with a SDN option for part of your network.  A common approach is deploying SDN at the edge of your legacy network.
3. If you want to attract funding from a lemming, then take the hybrid approach:  have your product or service support legacy networking and also SDN, so that your buzzword compliant solution can sell regardless of when sales of SDN takes off in the perpetually sought hockey-stick of growth.  The hockey stick is actually a staircase of growth – with discontinuities at market transitions defined in “Crossing the Chasm”.
4. The SDN switch technology market is already pretty saturated.  If you want to build a billion dollar company, make a compelling solution for a vertical market that uses SDN as an enabling technology.
5. Murphy’s Laws of Technology apply to any SDN endeavor, i.e. “The expert is always the one who says the job will be the hardest and take the longest.”
6.  And put on a parachute before jumping off that cliff.