Alcatel-Lucent has been in many ways the leader among network equipment vendors in service-layer strategy. Their notion of the “high-leverage network” and their focus on APIs and developers for next-gen services has been, in my view, right on the money (literally). Their positioning of their concepts, and as a result their ability to leverage their vision into some bucks in the quarterly coffers, has been disappointing. So they’ve changed their game now, starting with the divesting of ProgrammableWeb, the API outfit they’d previously purchased to augment their developer strategy.
I’ve always been a fan of “application enablement” in Alcatel-Lucent’s terms, but I wasn’t a fan of the ProgrammableWeb thing, largely because I think it ignores the fundamental truth about developers, which is that they’re not all the same. From the very first, network operators told me that they were less interested in exposing their own assets to developers than in creating their own service-layer assets to offer as retail features. That requires APIs and developer programs, but below the surface of the network—down where infrastructure and service control live. In fact, that is where Alcatel-Lucent now says it will focus.
This whole exercise demonstrates just how complicated it is for network operators and equipment vendors to come to terms with the software age. For literally a century, we’ve built networks by connecting discrete boxes with largely static functionality. A “service” is a cooperative relationship of these devices, induced by simple provisioning/management steps that are simple largely because the functional range of the devices are limited. No matter how many commands you send a router or switch, it’s going to route or switch. But make that device virtual, instantiate it as a software image, and now it’s a router or switch of convenience. Add a functional element here and pull one out there and you have a firewall or a web server. How do you build cooperative services from devices without borders?
When I go to NFV meetings or listen to SDN positioning or review my surveys of enterprises and network operators, what strikes me is that we’re all in this together, all trying to get our heads around a new age in networking, an age where role and role-host are separated, and so where role topology (the structural relationship among functional atoms in a network) isn’t the same as device topology. Virtual networking is possible because of network advances, but it’s meaningful because of the dynamism that software-based functionality brings to the table.
There are players who purport to “get” this angle, and I’ve been talking to them too. Any time I go to a public activity I get buttonholed by vendors who want to tell me that they have an example of this network-new-age situation. In some ways they’re right, but there’s a difference between being a gold miner who uses geology to find proper rock formations for gold deposit and somebody who digs up a bag of gold in their back yard while planting a shrub. Any change in market dynamic will create winners or losers just by changing the position of the optimal point of the market. What separates these serendipitous winners and losers from the real winners and losers is what happens when the players see that the sweet spot has moved. Do they run to the new one, or defend the old?
That’s Alcatel-Lucent’s dilemma now. Their API strategy has been aimed at the wrong developers. They picked up some baggage as a result, and now they’re shedding that. Good move. But did they pick up new insight when they dropped old baggage? Do they understand what it means to support service-layer development now? It’s more than saying that they’ll help the operators expose their assets, or more than saying that they’ll expose their own network APIs as assets to the operators. What operators are saying is that they need to be able to build services in an agile way, reusing components of functionality and taking advantage of elastic pools of network-connected resources. The future, in short, is a kind of blending of SOA principles and cloud computing principles. When we build services, not only now but henceforth, we are building these elastic SOA-cloud apps.
Nothing we have today in terms of infrastructure matches the needs of this future. Static device networks won’t connect elastic application resources. Element management systems make no sense in a world where an element is a role taken on by a virtual machine. Blink and you’re managing a server; blink again and it’s a firewall or a CDN or maybe even a set-top box. Schizo-management? Provisioning means nothing; we’re assigning roles. Service creation is software component orchestration. The question for Alcatel-Lucent is whether they grasp where the reality of future services will be found, because if they don’t then they may have dropped the baggage of ProgrammableWeb, but they’ve picked up another heavy load that will reduce their agility and limit their ability to create relevance in a network environment that is not only changing rapidly, it’s institutionalizing a mechanism to permit changes to be completely unbridled—because that’s the goal.
But for Alcatel-Lucent’s competitors, the issue may be worse. Alcatel-Lucent has at least shown it knows it’s bringing empty buckets to the fire and put them down. Do Cisco or Ericsson or Juniper or NSN know that? Is Alcatel-Lucent’s commitment to virtualize IMS, for example, an indication that they know that all network features that aren’t data-plane transport are going to be fully virtualized? Do they know that NFV goals will eventually be met ad hoc whether the body meets them or not? And do other vendors who have made no real progress in virtualizing anything or even talking rationally about the process have even a clue? If they don’t, then even a detour through the backwaters of the too-high-level-API world may still get Alcatel-Lucent to the promised land before their competitors take up residence.