One of the questions that operators are asking in at the end of the first quarter is “Just how much real SDN and NFV do we need?” I pointed out in prior blogs that if you were to do a successful OSS/BSS modernization you could achieve more of the service agility and operations efficiency benefits than you’d get with infrastructure modernization. The majority of operators are looking at this same sort of benefit-targeted evolution, even if most haven’t accepted the notion that it’s really an OSS/BSS shift. What the majority are looking at is what we could call the “lite” version of SDN and NFV.
SDN in a formalistic sense is based on the substitution of central control of routes for the usual adaptive control found in today’s switch or router networks. While it would be theoretically possible to simply make current networks work with OpenFlow, the benefits claimed for SDN rely on using cheaper white-box devices. To transform infrastructure to this model would obviously involve a lot of money and risk, so operators have been looking for a different way to “software-define” their networks.
NFV is in the same boat. What the original Call for Action white paper (October 2012) envisioned was the replacement of fixed appliances with pool-hosted software instances of the equivalent features. This is another infrastructure modernization, in short, and the targeted cost savings is highly dependent on achieving good economy of scale in that resource pool. That means mucho resources, and a correspondingly high level of transitional risk.
You’ve all probably read the stories about SDN and NFV adoption, and you’d be justified in thinking these technologies were really taking off. But in nearly all the cases, what’s taking off is a much narrower approach that exercises than we’d think of as the foundation standards. Hence, SDN or NFV Lite.
The principle behind all these deployment models is to go after agility and, to a lesser degree, self-care. Give the users a portal to order services that don’t require running a new access path, and then provide the minimal facilities needed to deploy these services using as much of current infrastructure as possible. The goal is to bring a change to the customer experience itself, cheaply and quickly.
This may sound like my “operations first” model, but it’s actually very different. Many of the operators have grabbed products that adapt current management capabilities to portal usage rather than even considering broader changes to OSS/BSS. One operator who did this told me “We’re trying to be agile at the business level here, and our operations processes are nowhere near agile.” What they’re ending up with is actually more OTT-like.
I think this is a current reflection of a trend that I’ve encountered as far back as three years ago, when operators’ own organizations were dividing over whether to modernize operations or redo it. They seem to be settling on a creeping-commitment version of the latter, where the nibble at the edges of operations practices using customer portal technology and management adapters.
On the NFV side, we can see this same trend in a slightly different form. You take a standard device that has a board or two that lets it host features, and you use the vendor’s management tools to maintain the features by controlling what’s loaded onto the board. All of this can be driven by (you guessed it!) a customer portal.
All of this has mixed implications for SDN and NFV. We’re taking steps that are labeled with the standards’ names, but not in the way the standards envisioned. So will these early steps then lead (as the practices mature) to “real” versions of SDN and NFV or will they end up creating silos? That’s an important question and one that’s very hard to answer right now. There are two negatives to this Lite movement. One is technical dilution and dispersion, and the other is low-apple benefit strangulation.
Obviously, a non-standard accommodation to SDN or NFV principles could very easily evolve into something that couldn’t be extended either functionally or in terms of open vendor participation. A silo, in short, and a risk to both SDN and NFV. For SDN, providing agile management interfaces could easily mean lock-in to a specific vendor. Operators already fear Cisco is trying this with their Application-Centric Infrastructure (ACI) model. The problem is that the SDN and NFV specifications have focused on the bottom of the problem, control of new devices and deployment of virtual functions, when the real issues are higher up. These Lite models thus live above the standards, in the wild west of modernization.
The second problem may be the most significant, though. You can get to the future from the present along a variety of paths, each of which has a kind of “benefit surface” that shows how it will impact cost and ROI over time. These Lite strategies are appealing because they grab a big chunk of benefits on the table at a much lower cost than a full, standards-compliant, solution. They also open a potentially interesting competitive dynamic.
The Lite model of SDN and NFV creates a portal-to-management pathway through which a lot of new services could be created. This could potentially augment, or bypass, both service-level and resource-level orchestration. That means operations vendors could jump on the approach to enhance OSS/BSS participation in transformation, or others could use it to minimize the need for operations participation in transformation. Same with the current and “true” SDN and NFV vendors—they could either build their top-end processes based on a portal notion, or other vendors could use portals to offer NFV benefits without NFV standards.
The most interesting notion here might be the potential to use portals as the front-end of both SDN and NFV, even to the extent of requiring that OSS/BSS systems interface through them. That would allow vendors of any sort to incorporate both service- and resource-level orchestration into their offerings and present “virtual services” to operations systems instead of virtual devices. From the bottom, it would mean that SDN and NFV would be low-level deployment elements, with no responsibility for organizing multipart models.
A service or a resource are, IMHO, both model hierarchies, and so are multi-part. That’s why you have to orchestrate in the first place—you have many players in a service or many parts to a resource deployment. The Lite strategy could make orchestration into an independent product space, one that does all the modeling and orchestration and uses SDN, NFV, and OSS/BSS only for the bottom-level or business-level stuff.
The higher-level portal-to-orchestration like could be the offense to the “deep orchestration” defense I’ve described. If you accept the notion that an operations-first strategy can deliver the most benefits, you need to adapt deeper SDN and NFV deployment technology to integrate with operations. If you want to realize your own benefits without waiting for operations technology to mature, you might give SDN/NFV Lite a try.