Gartner released some IT data it will be discussing further in a financial analyst conference next week. The information suggests that IT spending is growing more slowly than previously estimated, and it probably won’t surprise you to learn that software growth is well ahead of hardware growth. The company says that “Price pressure based on increased competition, lack of product differentiation and the increased availability of viable alternative solutions has had a dampening effect on the short term IT spending outlook.” They expect “normal” spending to resume in 2015-2018 (which I don’t).
I think that networking can learn something from IT here. I now use a laptop computer that probably cost less than $500 as a “desktop” system. It has a quad-core processor and plenty of storage and memory and it actually outperforms my old desktop system. I’m sure the manufacturer is happy I made the substitution, but the fact is that part of my motive was that I was getting more for less. That “for less” part is the point about price competition and lack of differentiation Gartner cited. If you can’t find something else that’s quantifiably better to you, you make a price-based choice. Bits, being hard to differentiate, have commoditized.
We hear a lot about networks shifting to software for differentiation and commoditization avoidance, but we’re missing the point here. “Software” per se is not the issue. If you consume a software-produced bit versus a hardware-produced bit, it’s still a bit. Software is more valuable not because what you do with it is better, but because you can do more differentiating things more easily. My PC is a brick, whether the old or new one, without software to run on it, and it’s the software that creates the value proposition. The software isn’t the value proposition, it’s just a vehicle.
In network terms, that means that SDN and NFV are not game-changers in and of themselves. How much service innovation are we hearing about for either? I don’t mean “service innovation” as a path toward cheaper bits or lower operations costs, I mean innovation of the kind that enterprise software can offer.
To create differentiating features, we need three things. First, we need something that’s valuable to the buyer that can be targeted. Utility is the first test of differentiability. Second, we need to be able to target that something quickly enough to satisfy buyer needs while the need still exists. That’s agility. Finally, we need to be able to do the Golden Something at a price the user will pay and with a level of profit that justifies our making the attempt. That’s efficiency.
Why has network software not met these tests? It clearly has not, because we’re not seeing some explosion in “network software”. I think the answer is simple; we don’t have “network software” today. We have software used in the network as part of hardware platforms to push bits. We should think of network software as serviceware, as the stuff that you write services in. I’m not talking about a new language, beyond Java or Visual C++ or something, but rather a new model. We have to be able to address utility, agility, and efficiency and that means coming up with some way of “writing services” that does the job. Sure that will involve “software” in the traditional sense, just as a computer chip involves addition or data movement, but it has to go beyond the basics or it’s a commodity right out of the box.
To my way of thinking the biggest advance we’ve made in the network services space, from the perspective of platform innovation, is the notion of modeling. We are seeing glimmers of a future where you build a service by dragging and dropping elements at the GUI level. Yes, it’s software that will create the GUI and other software that will translate the model you create into a functioning cooperative system of resources, but the architecture here is new; the modeling “language” we use becomes the serviceware of the future.
You’re probably thinking at this point about just what modeling language that might be. Even among the “literati” of network operators we have relatively little understanding of service modeling languages. Two-thirds of operators think of modeling of services as being modeling of the networks, and obviously that’s not the case. The network isn’t going to create the serviceware of the future because services are on the network not in it. We have to look to the cloud, and there we have an array of possibilities.
There’s a bunch of stuff out there, including OpenStack itself, that focuses on modeling applications. Everyone who has used OpenStack knows that Neutron includes models, but when you look at these models they’re still models of the networks on which applications live, not of the applications themselves. We do have some emerging stuff that shows some signs of relevance, like the OASIS TOSCA (Topology and Orchestration Specification for Cloud Applications”) model, but all of them have one fatal flaw, the flaw of NFV and SDN, and even the cloud. The flaw of focus. All our model revolutions are talking about modeling service infrastructure for deployment and management, and not modeling service logic. We’re using advanced tools to make the stuff we do more efficient, but not making it better.
I worked on the TMF’s SDF activity years ago, and one of the issues that came up very quickly was the difference between the service logic plane and the service management plane. Making something we assemble with a model useful, agile, and efficient mandates both logic and management and we’re still stuck on the management-model side. What do assembled components of a service do? How do we create useful functions by combining functional components? I can provision five components into a glorious ecosystem with NFV and connect them using SDN, but they move the ball on differentiability at the service level by what they do and not how I assembled them.
Bodies like OASIS, the NFV ISG, the ONF, and all of the other groups already running or starting up in the network service layer space should look at the logic/management point carefully, because if they don’t they’re not doing network software at all, they’re doing softened hardware.