If kids put teeth under their pillow and hope for quarters, or dig in their yards hoping to find pirate treasure, so financial planners in operators are looking for NFV and SDN to generate revenue. Cost savings are fine as a means of delaying the marginalization of the network and bridging out of a difficult capex bind, but only new revenue can really save everyone’s bacon. The question is whether the financial planners’ aspirations are any more realistic than those of our hypothetical quarter-and-treasure-seeking youth.
It’s really hard to say with confidence what services will be purchased in the future, even five years out. Survey information on this sort of thing is totally unreliable; I know that from over 30 years’ experience. I’ve made my own high-level guess in prior blogs—we have to presume that business IT spending growth will come from improvements to productivity gained by harnessing mobility. Rather than tell you that again, I propose we forget for a moment the specifics and look instead at a very important general question. Not “what” but how?
“Service agility” is the ability to present service offerings that match market requirements. If we knew what those requirements were we wouldn’t need to be agile; we’d just prepare for the future in a canny way. The fact is that even if we knew the next big thing, we’d have to worry about the thing after it. Service consumers are more tactical than traditional service infrastructure. What we need to know now is what the characteristics of the string of next-big-things-to-come are, so we can build SDN and NFV correctly (and optimally) to support them.
Sometimes it’s really helpful to engage in “exclusionary thinking” for something like this. So, we’ll start with what they are not. We are not going to get new revenue from selling the same stuff. We are not going to get new revenue from selling new stuff whose only value is to allow customers to spend less. We are not going to get new revenue from sources that could have given us new revenue all along had we but asked for it. New revenue may not come from my guess on mobile empowerment but it’s going to come from something that is new.
If we follow this thread we can look with somewhat of a critical eye at the current NFV activities at least insofar as supporting new revenue is concerned. Virtual CPE is not new revenue. Hosted IMS is not new revenue. In the SDN world, using virtual routers instead of real ones or OpenFlow instead of adaptive routing isn’t new revenue either. All of these things are worthy projects in lowering costs and raising profits, but cost management (and those who depend on it) vanish to a point. We have to see these as bridges to the future, but we have to be sure we can support the future as it gets closer.
“Old revenue” is based on two things—sale of connectivity and sale of connection-related features. New revenue delivers stuff, provides information and decisions. Thus, it’s much more likely to resemble cloud features than service elements. Services will be integrated with it, and in particular we’ll build ad hoc network relationships among process elements that are cohabiting in a user’s information dreams, but we’re still mostly about the content rather than about the conduit.
If we look at SDN in these terms we realize that SDN isn’t likely to generate much new revenue directly. It’s important as a cloud enabler or as an NFV enabler, depending on what you see the relationship between these two things being. NFV is definitely a support element too, but it’s supporting the dynamism of the features/components and their relationship with each other and with the user. We’re using NFV to deploy VNFs, components, VNF-as-a-service, and so forth. We’re using SDN to connect what we deploy.
What is that? Not in terms of functionality but in terms of relationships? There seem to be two broad categories of stuff, one that looks much like enterprise SaaS and the other that looks quite a bit like my hypothetical VNFaaS or what I’ve called “platform services”. Amazon is building more and more value-added components in AWS to augment basic cloud IaaS, to the point where you could easily visualize a developer writing to these APIs as often as they’d write to common operating system or middleware APIs. These combine to frame a model of service where composition of services is like application development.
This more dynamic model of service evolves over time, as companies evolve toward a more point-of-activity mission for IT. Some near-term services will have fairy static relationships among elements, particularly those that support communities of cooperating workers or that provide “horizontal” worker services like UC/UCC. Others will be almost extemporaneous, context- and event-driven to respond to conditions that change as fast as traffic for a self-drive car.
In general, faster associations will mean pre-provisioned assets, and as activities move from being totally per-worker-context-driven to a more planned/provisioned model we’ll move from assembling “services” from APIs and VNFaaS to assembling them in the more web-like sense by connecting hosted elements. In between we’ll be deploying service components and instances on demand where needed and connecting them through a high-level connection-layer process that looks a lot like “overlay SDN”.
NFV’s MANO is about deployment instructions; it models the service’s functional relationships only indirectly. As you move toward extemporaneous cloud-like services you are mapping functions and functional relationships themselves. In many, likely even most, cases the “functions” don’t have to be deployed because they’re already there. It’s a classic shift from service management to service logic, a boundary that’s been getting fuzzier for some time, though the shift has been gradual and largely unrecognized.
This is a new kind of orchestration, something that’s more akin to providing a user with a blueprint that defines their relationship with information and processing, and the relationship between those two things and all of the elements of context that define personalization because they define (at least in a logical/virtual sense) people. Think of it as an application template that’s invoked by the user on demand, based on context and mission, and representing the user through a task or even entertainment or social interaction. Identity plus context equals humanity? Perhaps in a service sense that’s true.
Both NFV and SDN need to be expanded, generalized, to support this concept but I’d submit that we were as an industry, perhaps unwittingly, committed to that expansion anyway because of the cloud. NFV is the ultimate evolution of DevOps. SDN is the fulfillment of the ultimate generalization of OpenStack’s Neutron.
Yes, Neutron. OpenStack is probably more important in the model I’m describing here than SDN Controllers because the latter will be abstracted by the former. TOSCA is more important than Yang because the latter is about network connections and the former is about cloud abstractions. We’re not heading to the network in the future, but to the cloud.
Don’t let this make you think that I believe NFV is superior to SDN. As I indicated above, both are subordinate to that same force of personalization. Whatever services you think are valuable in the future, and however you think they might be created, they’ll be aimed at people and not at companies or sites. Both SDN and NFV have blinders on in this respect. Both see the future of networking as being some enhanced model of site connection when mobility has already proved that sites are only old-fashioned places to collect people. It’s the people, and what they want and what makes them productive that will frame the requirements for NFV and SDN in the future.