I spent some time recently looking at the state of the SDN/OF controllers available and realized that development has stalled well short of the original vision that was projected to change everything in networking. The controller discussions I read created a vision in my head of the controller as a powerful application development platform including a rich set of libraries that enable high level development of innovative network applications above the drudgery of coding all the foundation code that it must be built on. Two of the most compelling takeaways for me, great sources of hope, from the original Stanford OpenFlow documentation were that:

• Distributed Computing is a solved problem and network developers were going to finally get out of the business of inventing a new solution for fundamental distributed computing problems for each new protocol. There would, of course, be a nice distributed-computing primatives library where all of our state, persistence,  and synchronization problems would be a function call (method invocation?) away.
• The process of taking a general description of how a packet should be handled and translating it into the many switch specific rules that need to be pushed into the flow tables of the various devices would be magic. Nice libraries in the controller's SDK would convert network policy to device rules in a way that empowered developers to solve higher level (e.g. network) problems.

NONE OF THIS IS HAPPENING, as far as I can see. The killer application platform that is going to lead to an OpenFlow appstore  at the ONF was forgetten along the way.(I know this forecast at Open Network Summit was somewhat tongue-in-cheek. Unfortunately goofy analysts took it literally and your sales VP will soon have a quota for it)   We have a "bare-metal" controller level of sophistication and are asked to be assembly language programmers in OpenFlow while re-inventing point solutions to the distributed computing problem.

Using James Hamilton's notorious "mainframe business model" analogy, many people anticipate network equipment suppliers evolving from a vertical model (IBM made the chips, boards, boxes, OS and apps not unlike Cisco today) to a horizontal model (Intel/Dell/Phoenix/Microsoft). I happen to be one of the people who believes the network equipment ecosystem can, will and should go from vertical to horizontal. Broadcom is pretty much Intel in this space, and I think someone like Pica-8 could become the Dell of this world and own the delivery of commodity hardware. However, I think the Microsoft role in the new horizontal universe is still up for grabs and will be captured by the innovator that builds a high value platform, rich/powerful tool-chain and ecosystem of developers who get huge leverage benefits in their application verticals from the breadth of the foundation that is provided by the controller platform.

In terms of the evolution of networks  from the mainframe model to the PC model, we could have saved a lot of time by jumping right past the mini-computer era this time around. But that is where the folks building controllers seem to be taking us. "Hey, I've got this system that you can't program without getting bogged down in the proprietary issues about how I've architected it. And you will have to build your own application foundation in a way that won't be at all portable if you switch to my competitor. Also, it does the exact same thing as your competitors foundation code. But, hey, it's an improvement on that big iron from the usual vendors". I'm old enough to remember programming DEC's VAX and funky Unix boxes, but I'm not the nostalgic type when it comes to leverage in developer tools. Won't someone please take us right to the Visual C++ era ( or Eclipse for that matter) ?  The next zillion dollar platform company might be the reward for finishing this exercise. Or we could leap right past the commercial toolchain and have the open source community win the day. You can be Stallman if I can be Linus.  Have you got the beard for it?