Everyone surely knows the old saw about the difficulty in pushing spaghetti uphill, and it occurs to me that we’re in danger of trying to do something very like that with changes created by SDN and NFV, perhaps even the cloud. The expression is usually applied to tasks that are made difficult not by the intrinsic goal but by the fact that execution is starting at the wrong point. You probably understand why I might think that’s an issue with our trio of revolutions.
“Services” in an IT, network, or cloud sense are really retail services. A seat is not a car, and while you surely need seats in cars for them to be useful, you can’t talk about seat improvements as though consumers ran down to their dealerships to buy seats every couple years. If you focus on the seat and not the car, you miss the dynamics that actually drive the market.
When we say that SDN or NFV or the cloud will improve services, and at the same time present them as alternatives to doing what we already do, we’re saying that the “improvements” are non-functional. If Car A differs from Car B for non-functional reasons, then the only valid differentiator the buyer would likely recognize is cost. But if we’re saying there is no benefit to these technology shifts other than cost, then adopting them will simply reduce revenues to the sellers, and downward through the food chain. So, arguably, the success of all three will depend on generating some of those functional improvements, increasing the utility of networking or IT to the point where people will spend more on services, not less, because they get something that justifies that change.
For the cloud, that means that we have to stop talking about IaaS. IaaS is hosted virtualization; virtualization is multi-tenant server consolidation. All of that stuff is about cost management. Something isn’t expected to run better, or even different, in the IaaS cloud, only cheaper. Amazon’s recent focus on augmenting EC2 with new web service features to deliver functional value to cloud applications is a step in the right direction. IaaS is going to grow up, and we need to not only accept but embrace that maturation, by thinking about good stuff that can be presented as a functional service element and not a cheaper service platform.
For SDN, I think the key is the notion of the service model. SDN manipulates forwarding processes per device to create an overall service/connection model. If the model we create is identical to that of Ethernet or IP, then we’ve added no functional utility through SDN and we can only justify it based on the assumption it’s cheaper—a lot cheaper in fact because of the risk premium associated with a new technology. We should be talking about service models created northbound from SDN, models that would bring different features to network users.
NFV is the classic. On the face, NFV proposes to take a box and turn it into a chain of VM-hosted, network-connected, elements. The result would do what the box did, and the allegation is that it would be cheaper. Well, how many VMs do we need? What’s the cost of the VM if we amortize server costs, data center power and cooling, and (most of all) operations costs? How would creating something from four distributed hosted elements be easier to manage than the box?
We got into this mess by spaghetti-pushing. The car buyer wouldn’t evaluate a car by looking at how well the wheels turned or how the seat moved or how bolt A fit into nut B. They’d talk about “how it looks” and “how it drives”, meaning they’d apply very high-level functional utility standards. The car-builder, at least those who want to live to sell another day, would similarly start with the primary aesthetic issues that buyers respond to. Imagine your excitement as your dealer shows you how your car is assembled from a pile of parts. Would you stand around to see what was going to emerge, or more significantly would you buy based on the promise of the process and not the characteristics of the final result? If you say “Yes” I’d love to sell you a car.
NFV, SDN, the cloud, all mean nothing if they don’t expose new benefits. Vendors will not invest to contract their markets, nor will service providers build out to lose money faster. Service creation is the process of functional assembly. Yet we don’t talk about functions at all when we talk about SDN or NFV or the cloud; we don’t talk about the high-level impact, because we’re not prepared to propose what the impact might be or how we might achieve it.
Orchestration is the poster-child for all of this. Ask an “NFV” provider about it and they’ll say they do it—with OpenStack. Flash: OpenStack is not orchestration. It’s cloud component deployment. It’s screwing the seat onto the frame, not building a car. Run screaming from those who say OpenStack is the solution to NFV, or SDN, or the cloud. Shun them. They’re pushing spaghetti uphill and they want you to join them in their futile endeavor.
We have nothing in the way of standards to drive us forward toward functional-driven orchestration, nothing to connect all our low-level bluster with the buyers’ wallets. We have no hope that a new standards process could achieve anything but generating Platinum memberships at this point; we’re out of time. The buyer is standing in the showroom, checkbook in hand, and looking at our pile of parts. By the time we assemble a notion of what we expect to do with them, that buyer will be standing somewhere else. Someone is going to have to take a stand, build a car. Unless there’s no automotive market, unless buyer functional requirements mean nothing, that someone is going to have a big payday.
