We’re living in a period when every day someone proposes a new networking revolution, and I find it interesting that the networking revolutions that we’ve really tried to bring about are still in the smoky-room-unshaven-anarchist phase. Five years ago, network operators had three priorities for monetization, the top one being content. As of last fall, they were telling me that they had made little progress there. Sixteen percent of content projects approved had even gotten as far as the trial stage. Why?
In the course of these project developments I got about two-dozen detailed project plans to review, and I was struck by the similarity of the plans—not so much in the specific details but in the fact that the centerpiece of the whole thing was the functional block diagram. On the average these diagrams had about 20 blocks, and they made great reading in the executive washroom I’m sure, but they don’t do much beyond organizing what you have to do. In particular they don’t deal with the “how” part. In eighteen of the plans I reviewed, the operators were unable to find components to match the blocks, and that simple truth is what stalled the project.
So what do we see today when we look at “revolutions” like the cloud, or SDN, or NFV? The dreaded functional block diagram. OK, we all know that the cloud has to provide for resource hosting (a block), management (another block), assignment (third block). Does drawing this picture move the ball on designing a cloud stack or implementing a cloud? Not unless you’re doing “Dick and Jane do Cloud”-level work. With both SDN and NFV we have proposals for functional architectures, but if you wanted to write an SDN or NFV application today, how far do you think you’d get? Not far enough.
In the early days of service-layer standards work, after months of frustrating conference calls on a particular standard, I got an email from a big European telco, and it said “Tom, you have to understand we’re 100% behind implementable standards. We’re just not sure this is one of them.” Which is my big gripe about all of this stuff.
Everything about the cloud, or SDN, or NFV has to be about APIs—application program interfaces that let software call functionality and drive changes in resources or applications. In modern development, APIs are normally defined as part of an object model, which is a set of software abstractions that represent the pieces of the thing being done. We use, indirectly, object models every day that we use smartphones or browsers or .NET because the stuff is built on that principle. So where is the object model for the cloud, or SDN, or NFV?
Well, we are not there yet, with any of the standards activities built around our revolutions. We’re not even moving convincingly in that direction. I’ve been reading a thread online where a group is looking to define SDN. Well, SDN is already defined. Here’s a presentation that provides as good a foundation for the notion as you’ll find anywhere: http://www.slideshare.net/martin_casado/sdn-abstractions. The presentation not only defines SDN, it introduces a key point about implementing SDN or anything else; software-building is about the creation of abstractions. That’s what object models define. If we had an abstract object representing a network and mapped it to both direct devices and virtual subsets, we could write apps to that object’s APIs and the same code works in all cases! Isn’t this something we’d want? Is it something we’re talking about? No, because we’re not talking about the right stuff.
My suggestion has been that every “standard” activity that’s aimed at software-driven processes be accompanied by an open source project that builds the object model, prototypes the logic, runs lab tests and demonstrations, and insures that the issues of functionality, performance efficiency, security, and availability are addressed from the first. This would also insure that “standards” don’t end up available only through proprietary implementations. I still think that’s the best approach, but I’m not seeing much support for the notion in the vendor community (Surprise!) or even among operators. Yet if you look at those agonizing standards processes that never seemed to get anywhere, those operator projects like content monetization that are still pasted to walls in conference rooms and not running in networks, they’ve all fallen prey to problems that collateral development could have resolved from the first. If we want software to take a key role in the future of networking, we need to start thinking like software people.