Today we have the network sequitur and the network non sequitur. In the former category I place the Alcatel-Lucent comments on the demise (or surrender) of their API efforts, and in the latter I place the Cisco guy leaving for Big Switch. And amid all of this, I see tooth fairies and trolls.
Some people believe in SDN. Some believe in NFV. Some are holding out for the tooth fairy or trolls or ghosts. For those with one of the first two belief sets, or others relating to improved network functionality, it’s hard to escape the fundamental truth that if software is going to control something, it’s going to do the controlling through APIs. Further, it’s inescapable that if you start with those high-level APIs that would allow software to influence the network’s behavior, and you build downward from them, you’ll eventually create a cohesive set of control elements that translate what software wants to what the network does. Top-down design, in short.
Look at Alcatel-Lucent’s notion of APIs and you run into the concept of “exposure”, and IMHO where Alcatel-Lucent went wrong is at that very early and critical point. Exposure is a bottom-up concept, something that makes the current mechanisms for control accessible rather than defining the goals. If you progress from what you have toward something you don’t quite grasp, you likely go wrong along the way. You have to get from NYC to LA by making a series of turns, but if you don’t have the context of the destination in mind all along, you’ll make the wrong ones and end up in the wrong place, as Alcatel-Lucent did.
Perhaps, as Alcatel-Lucent believes, they aren’t needed where they focused their initiatives, but that means the focus was wrong and not the need. What Alcatel-Lucent needs to do right now is to take up the NFV process as their baseline for progress. NFV is thinking a lot about how to deploy and manage virtual functions but so far relatively little about where these things come from. Hint: The tooth fairy and trolls will not figure prominently in providing them! Building services from virtual components starts with building services, and building them in a way that allows software processes to drive everything along the path to delivery. Otherwise the operations costs for virtual functions will explode as the number of choices and elements explodes. Any good software guy would look at the process and whip out a blank sheet on which to start drawing an object model. Where’s that happening? Nowhere I see, so Alcatel-Lucent can be on the ground floor, still.
On the Cisco-Big-Switch switcheroo on an executive, we’re trying to make news out of what is far more likely to be a simple career decision. If you’re an SDN guy, why not join an SDN startup and collect a zillion dollars on the flip, or at least try to? You can always go back if it doesn’t work out, or go to a competitor. An old friend told me that in the late 40s or 50s, networking executives/managers get to the point where they have to roll the startup dice or forget that game forever. But since having somebody leave establishment Cisco for revolutionary Big Switch looks like the revolution is working, it’s a great tale. So was the tooth fairy and trolls, but that doesn’t make them real. Stick a tooth under your pillow or look under the next bridge you see, and you’re unlikely to become a believer in fairy tales.
There’s a connection here besides the negative one. The cloud is creating a dynamic application and resource model that demands a dynamic connection model, a different model from the static site networking or experience networking that businesses or consumers (respectively) now expect. SDN can’t make a go of itself by providing a mechanism to do something that software can’t get its head around. We have to start by looking at how that dynamic connection model is instantiated on dynamic infrastructure to support something stable and manageable and cost-effective enough to be commercially viable. Big Switch isn’t doing that, not for the cloud as a whole. If they don’t, or if somebody doesn’t gratuitously do it for them, then Cisco is going to win and Big Switch is going to lose.
Same with NFV. We can have a great architecture to deploy virtual functions but we have to connect them into cooperating systems and manage their behavior, and most of all we have to do this while addressing the agile applications that absolutely have to come along and become the revenue kicker for telcos that makes all this work worthwhile. And doing that means getting out that sheet of paper and drawing that object model, not drawing trolls and tooth fairies.