We clearly live in a virtual world, in terms of the evolution of technology at least, but I really wonder sometimes whether everyone got the memo on this particular point. It seems like there’s a tendency to look at the future of virtualization as one focused on creating virtual images of the same tired old real things we started with. If that’s the case, we’re in for a sadly disappointing future in all of our tech revolutions—cloud, SDN, and NFV.
I’ve commented before that cloud computing today tends to be VM hosting as a service, which confines its benefits to fairly simple applications of server consolidation. What the cloud should really be is an abstraction of compute services, a virtual host with all sorts of elastic properties. We should define the properties of our virtual computer in terms of the normal compute features or course, but we should also define “platform services” that let applications take advantage of the inherent distributability and elasticity of the cloud. By creating cloud-specific features for our virtual computer, we support applications that can run only in the cloud, and that’s the only way we’ll take full advantage of cloud capabilities.
Why do we get fixated on the low apples of the cloud? Partly because vendors are so fixated on current-quarter numbers that they don’t even think about the end of the year. Partly because socializing a complete shift in IT technology is beyond our marketing/positioning/media processes. Partly because any populist revolution (which all of tech is these days) has to dumb down to be populist. But we can all drive without being automotive engineers, so it’s possible to make complex technology changes consumable, right?
Well, you’d never guess that was the case in the SDN space. Software-defined networking today offers us two totally different visions of networking. One vision, promoted by the software-overlay players, says that “connectivity” is an artifact of the network edge, an overlay on featureless transport facilities. Another, the OpenFlow hardware vision, says that networking is a totally malleable abstraction created by manipulating the forwarding rules of individual devices. And yet what do we do with both these wonderfully flexible abstractions? Recreate the current networks!
Then there’s NFV. The original concept of NFV was to take network functions out of purpose-built appliances and host them on commercial off-the-shelf servers—if you’re a modernist you’d say “on the cloud”. How much real value could we obtain by simply moving a firewall, or even an IMS component, from a custom device to a COTS server? Whatever operations issues existed for the original system of real devices would be compounded when we mix and match virtual functions to create each “virtual device”. We have to manage at two levels instead of one, and the management state of any network element that’s virtualized from multiple components has to be derived from the state of the components and the state of the connectivity that binds them into a cooperating unit.
The real answer for both SDN and NFV is to go back to the foundations of virtualization, which is the concept of abstraction. Take a look at Metaswitch’s Project Clearwater architecture (the link is: http://www.projectclearwater.org/technical/clearwater-architecture/) and you’ll see that we have a cloud-ready IMS at one level. Look deeper and you’ll see that Clearwater abstracts IMS into a black box and then defines a component set that roughly maps to 3GPP elements but that cooperates to create the expected external interfaces. That, my friends, is how abstraction should work. Which is how the cloud, and SDN, and NFV should all work.
Flexibility that expands our options does us little good if we exercise it by affirming and entrenching the same choices we made before we got flexible. The most important dialogs we could have on the topic of cloud, SDN, and NFV aren’t how we do what we do now, but how we might, in our flexible future, do what we can’t do now. As we look at new announcements in our three key technology spaces, we should keep this point in mind, and take vendors to task if they don’t address it. I’m going to do that, and you’ll get my unbiased views right here.