Anyone who’s watching the networking market realizes by now that there’s a huge interest in open-source, especially among service providers. Many attribute this to penny-pinching, but that’s not the case. Operators know that moving from appliances to hosted elements is going to save less than 20% on their capital budget and have a so-far-unpredictable impact on opex. Those who have looked closely at the latter issue have concluded, in fact, that there’s no incentive for things like SDN and NFV other than operations efficiency and service agility. So why push for open source?
Operators tell me that they believe vendors are not responding to their need for transformative technology, and my surveys show that’s been true for almost a decade now. They’ve issued RFIs and RFPs and tried to influence standards groups and even spun up a few of their own, but in the end none of this is resulting in a flood of new technology options to do what operators need. They can’t join to develop something, either. In many countries they can’t manufacture, and in more they can’t work together without getting slapped with an anti-trust suit. So open-source is their only choice; they can work on an open project as easily as on open standards.
I’m a big fan of open source, as I’m sure those who read my stuff already know. I’d love to see operators do more—do everything—with it. That’s not going to happen, though, and in truth it doesn’t have to happen. Most of the software elements of the network of the future are going to be commercial, for years to come if not forever. But what I think is even more important is that many of the operators’ goals could be met in the near term by taking a different path, and that path could still embrace and even lead to open source down the line. What is it? The answer is “MANOaaS.”
All the disdain operators say their vendors have for transformation support should have generated a huge startup opportunity, even in our current age of VCs funding different ways of organizing social media and video. Why hasn’t that happened? The reason is that the central thing that operators need is a highly flexible management/orchestration framework. Everyone who’s looked at this problem knows it gets harder the deeper you look, and the VC community has no interest in funding something that would generate a transformation that would empower server/platform stuff their startups don’t make but would require prodigious investment and time to complete.
Suppose we look at this another way? In both the SDN and NFV worlds, we need to create services across technology domains and manage them, and associated legacy technology, end to end. This means doing things like modeling and decomposing, optimizing and allocating, and transforming among a host of different management visions and needs. Almost all of this stuff could be done in as-a-service form.
Let’s take the task of converting a service model (a description of the rules associated with making connections among network users) into a service by controlling forwarding tables. You could easily envision a “StampOutMyVirtualStuff” service that takes, as input, a graph describing the topology of the physical environment and all of the attributes of the nodes and paths, plus a similar description of the desired connection behavior. Flash, bam, alakazam (as the old song goes), you have a list of forwarding instructions to send to some controller. Other nuclear tasks associated with SDN and NFV could also be made into services, and those who need them could dodge capital costs of MANO completely. If the SaaS model is smart for enterprises, why not for providers?
Another virtue of MANOaaS is that it could force the industry to present functionality in atomic form, through RESTful interfaces that could facilitate open substitution of elements and thus promote competition. Competition would be lower, and the opportunity to set de facto standards greater, for early players so we could start a competitive rush to get things out there and working. That could jump-start the use of the new tools.
For the service provider, the MANOaaS model could provide relief from a terrible dilemma; do you roll out a universal strategy that will solve all your problems but perhaps take years to be cost-effective, or do you do little chunks here and there and hope you’ll not create technology silos worse than the service-specific networks of the past?
Even the software guys, the people who could, should, might do something in the MANO space might find this to be an attractive approach. It’s pretty hard to make money on open-source unless you’re a company large enough to drive a credible professional services business. A startup could host a couple pieces of MANOaaS on a public cloud provider and see their own costs scale reasonably. Their per-orchestration or per-service fee might be something that the providers would balk at down the line when their MANOing becomes universal, but that pressure could be relieved by offering licenses to run the stuff on the providers’ own clouds.
Even open-source could be promoted here. I’m convinced you could do a lot of MANO, as much as 85%, with open source, but even if I describe how to do that (which is what I plan) it doesn’t get it done. Who drives the project forward? Will the players who are now resisting offering transformative tools to operators suddenly change their minds? We need different players involved here, as many as we can possibly induce to get involved, as fast as they can be made to commit. The more profit models we can offer them the better the chance at least one of those models is right.
This may be a critical thing for the credibility of the cloud too. Can we say that SaaS is the right model, that the cloud is universally applicable, when the very people we think will build that cloud don’t think they can use it to jump-start their own transformation? What’s sauce for the goose is sauce for the gander.