I was finally able to fit in a briefing by Alcatel-Lucent on their CloudBand ecosystem and NFV strategy (not because they were unwilling but because of mutual scheduling issues). The briefing was very helpful in conveying what Alcatel-Lucent is really doing in NFV and the cloud, and it also illustrates the positioning challenges vendors face in this new world of virtualization.
CloudBand is a two-level process—Nodes that run resources like VMs and storage and the CloudBand Management System which is the functional heart of the process. Pretty much anything that can run OpenStack or CloudStack can be used as a node. Functionally, CloudBand operates as a work distributor that makes hosting and connection decisions based on policy, acting through the cloud management APIs (Nova and Neutrino in the case of OpenStack). Unlike “vanilla” OpenStack, CloudBand can apply policies to make decisions based on security, affinities in location, load, etc. All of this is a very cloud-friendly process. There’s a strong focus on application lifecycle management (ALM) and Chef or Puppet DevOps scripts can be imported to use as provisioning frameworks.
Virtual functions are deployed using “Recipes” that define what some cloud tools call “packages” of deployable components and instructions for their connection. It’s these Recipes that can set policies and determine how specific components are instantiated and then connected. The Nuage SDN technology Alcatel-Lucent previously announced creates an agile connection framework for the collection of nodes and functions, and Alcatel-Lucent’s previously announced Nuage-related links between SDN and infrastructure would apply to facilitate traffic management.
CloudBand supports federation at the IaaS level; as long as OpenStack or CloudStack APIs are available you could deploy across a large community of data centers. I think that it would be possible to connect even things that didn’t run Nuage, but it might require some customization of Neutron plugins. I happen to like Nuage’s capabilities so it would make sense to assume that a CloudBand deployment was a Nuage deployment, but clearly federation might change that.
The CloudBand Ecosystem is a developer program that’s designed to create an NFV-friendly test and deployment framework for virtual functions. Developers of virtual function logic are obviously constrained in terms of testing in the real world, and the Alcatel-Lucent program gives them an opportunity to test across a community of providers. It would be a small step from this to providing a complete pan-provider repository for virtual function logic and also to provide for pan-provider services based on developer-program virtual functions. Nobody talked about resurrecting the old Application Exposure Suite or Open API Program but there are clearly some similarities in terms of objectives.
There’s a clear dualism between NFV and the cloud here. CloudBand is an implementation of NFV (as much as anyone would be able to do that given the early state of the definitions from the ISG), and it stays pretty close to the structural mission of the ISG itself in that it’s about cloud-hosting virtual functions rather than about creating end-to-end services. Alcatel-Lucent indicated that they expect to run under a service management process to accomplish that. NFV management practices have not been defined in detail at this point so we can’t really compare what Alcatel-Lucent does with NFV specifications. It does appear that they have the ability to both “self-manage” inside NFV-defined functional black boxes, or reflect management state at a composite level. The latter would likely be the responsibility of the developer, at least to a degree.
Developers can build fairly generic virtual functions, potentially even using generic cloud-ready code, and I think that most cloud software components could be composed into hybrid software/virtual-function services as well. This seems logical given that Alcatel-Lucent says that some operators are using CloudBand to deploy cloud computing services, and it’s a dualism that I think is essential for the credibility of NFV. We can’t be inventing a new virtualization-driven infrastructure for every new mission, after all.
This is a pretty credible NFV framework in my view, and since it comes from a major network vendor it’s one that’s going to be taken seriously. My spring survey results showed that only two vendors were credited with having a useful NFV platform in play, and Alcatel-Lucent was one of them. The only problem with the survey as a guide here is that nothing was available from anyone at the start of the survey period and some operators may have gotten a view of other vendor platforms after they’d already turned in their responses. The fall survey should provide a better guide on how operators see CloudBand and also how Alcatel-Lucent’s competitors respond and are perceived.
As far as I can determine, there are now about seven NFV platforms at some state of development/deployment, and all of the major network vendors are said to have an NFV strategy that they’re shopping around. Ericsson’s is said to be fairly OSS/BSS-centric (no surprise given Telcordia’s acquisition), but I’ve not heard much about the other approaches. The one to watch is Cisco, of course, given that they have considerable server assets and thus direct cloud credibility. Cisco is in fact the only major network vendor who could actually make a boatload of money on NFV deployment, given that the main impact of NFV will be to explode the number of carrier data centers as hosted functions gain adoption.
How much of an explosion could NFV create? Here’s my model’s answer. Between 2013 and 2018, an optimum NFV architecture could create an increase in operator spending on data center equipment of over $25 billion per year. By 2018, NFV will impact nearly 60% of all operator network equipment purchase decisions. By 2020, an optimum NFV architecture could add so many operator NFV data centers that it would double the global number of data centers.
The operative word here is “optimum” of course. It’s very difficult at this point to assess just what an optimum architecture would be, and even harder to tell if a given NFV solution fits the mold given that articulation of the strategies (including Alcatel-Lucent’s) is still rather lightweight. I think that this will sort out, though, because the NFV ISG is making it very clear that the operators are serious about creating an NFV solution, and the fact that there are already examples of NFV implementation means vendors are taking them seriously.