In my last post, OpenFlow Might Lower CapEx While SDN Will Increase OpEx I pointed out the OpenFlow/SDN won’t cheaper over a three to five-year period. By the time you factor in the software development costs for your controller and application, you will probably be paying more than ever. I can barely imagine any business running a software development project – most of the market can barely handle customizing their accounting system. Of course, the last decade has seen the fashion move to buying “off the shelf” with minimal customisation.
As I talked about in my Introduction to OpenFlow and SDN Webinar , Software Defined Networking comes in two distinct parts – Controller and Applications. The controller is simple platform for communication, using OpenFlow, with the network devices. It has shared libraries, common resources, and standards compliant elements. (There are no rules here but that’s how I see it today).
But the controller isn’t any good without applications. What is the decision engine that determines what flow entries are sent to the device ? What path analysis is used to determine the flow path across the devices ?
These problems are handled by the Applications that run on the Controller. Consider the applications as somewhat equivalent to OSPF, BGP, MPLS or some pathing protocol that suits your requirements. For example, an Ethernet multipath
The future of OpenFlow is defined by it’s Applications. These applications could be many things – routing apps, load balancer apps, switching apps, dynamic networking, multicast tree, security apps and much more. The application will use an algorithm to program the flow table to achieve the networking outcome that you want. Sure, none of this is here today but that is the potential of the platform.
And who has the expertise, financial muscle, and customer confidence with network services ? Which companies have proven history of delivering networking products ? And maintaining those products ?
You guessed it. The big vendors do. They don’t even have to change much to embrace OpenFlow, just the delivery is a bit different. Today, vendors are building Network Management Systems that provided fault monitoring and performance management. This leaves the operation and configuration of networks to some other process, usually hand crafted by engineers at the CLI.
Software Defined Networking means that vendors will shift to Network Operations Management and offer a chance to handle the configuration of the network using automated tools for much of the daily grind of operating a network. And building that software is exactly the sort of the challenge that big vendors should do well – skill and resources to build, support and maintenance teams and credibility with customers are going to define these products.
The EtherealMind View
There are opportunities for startups to enter the network space during the disruptive phase but I’d say that SDN belongs to big companies with deep pockets and many resources. SDN is much more likely to have big price tags when purchasing your software for the reasons I describe. In return, I’d say that customers will get better networks that cost less to run as a justification. And sure, some businesses will find new ways to turn OpenFlow/SDN into something new, like Google has this week but that’s an outlier not a trend.
It’s took VMware ten years to develop their disruption in the server market. SDN is about three years into a similar cycle. Lots of time to go before the final game is up. Don’t get caught in the hype. OpenFlow/SDN is competing against a LOT of other technological innovation – TRILL, Fabric, Merchant Silicon and software appliances are bigger trends. And more macro trends in network engineering such as OSPF LFA, FRR, BGP enhancements means that there are many technology choices.
Damn but it’s a good time to be in networking.