The network operators, particularly the telcos, are in a battle with themselves, attempting a “transformation” from their sale-of-bits model of the past to something different and yet not precisely defined. One likely offshoot of this, Verizon’s decision to acquire AOL, has generated a lot of comment and I think it may also offer some insights into where operators are heading in terms of services and infrastructure. That has implications for both SDN and NFV.
AOL reported about $2.6 billion in revenues, compared to Verizon’s $128 billion. I don’t think, nor do most Street analysts, that Verizon was buying AOL for their revenue. Verizon’s revenues, in fact, are about a quarter of the whole global ad spend. You don’t find relief for a large problem at a small scale. That means they were likely buying them for their mobile and ad platform—their service-layer technology. So does this mean that telcos are going to become OTTs?
Not possible. Obviously somebody has to carry traffic, so the most that could happen was that telcos could add OTT services to their inventory. But even that has challenges as a long-term business model because of seismic shifts in carrier profits. OTTs get access to the customer essentially free, and telcos get paid for providing customer services, right? Right, but remember that operators everywhere are saying their revenue and cost per bit curves will cross about 2017. If the operator ends up providing Internet at a loss and making up the loss with OTT services, their service profits will be lower than the “real” OTTs’. They have to make up a loss the others don’t bear.
What is possible? Start with the fact that the converging cost/revenue per bit curves can be kept separate by improving costs or raising revenues, or any combination thereof. We’re used to thinking of “revolutionary” technologies like SDN, NFV, and the cloud as being the total solution, meaning that we’d address both cost and revenue with a common investment. Not only that, operators themselves have made that assumption and most still do so. Of the 47 global operators I’ve surveyed, 44 have presented “transformation plans” to address both costs and revenues. Well, AOL isn’t likely to impact Verizon’s cost, so it just might be that Verizon has decided to split what nearly everyone else has combined. That could be big news.
It’s not that NFV can place ads or control mobile experiences directly. As announcements for session-service platforms from Alcatel-Lucent, Huawei, and Oracle have already shown, you really need a kind of “PaaS” in which specialized service apps live. You can deploy these platforms with NFV, operationalize them with NFV principles (if you have any NFV operations features from your vendor), and perhaps even connect them using SDN. All of the vendors who have announced these platforms have taken pains to endorse NFV compatibility.
AOL isn’t a vendor, nor are they a carrier. I’ve never heard them say a word about NFV or SDN and it’s unlikely they designed their mobile or ad platforms to be SDN-consuming or NFV-compliant. That means that what Verizon bought isn’t either of these things, and that’s where the interesting point comes in.
Late last year, a number of operator CFOs told me that their need for a resolution to their cost/revenue problems quickly. Many said that unless they could make the case for NFV as a path of resolution for these problems before the end of 2016, they’d have to find another path. Might it be that Verizon has decided that they need a revenue-generating architecture, NFV or not? AOL proves an important point, which is that many service platforms for mobile and advertising are multi-tenant. You don’t have to “deploy” them for every user, they’re just hosted for multi-tenant services. IMS is like that, after all. So for these types of service you don’t “need” NFV. It’s a cloud service.
Two things generate a need for orchestrated service behavior. One is deployment frequency. If I have to spin up an instance of a service feature set for every customer and service, then I have to worry a lot about costs for that process. If I spin it up once for all customers and services, then I’m much less concerned about the spin-up costs. The other factor is management and SLAs. If a service has to be managed explicitly because it has an explicit SLA, then I have to orchestrate service lifecycle processes to make that management efficient. If a service is best-efforts I’ll manage resources against service load and roll the dice, just like the Internet does.
If we can address service revenue growth outside SDN/NFV, how about the cost side? Service automation is a path to reducing opex, but you could also envision opex reduction coming about as a result of “infrastructure simplification”. Suppose you built a vertically integrated stack of virtual switching/routing, agile SDN tunnels, and agile optics, all presented as NaaS? Could this stack not have much lower intrinsic operations cost even without a lot of add-on service automation or orchestration? Sure could.
The risk to operators in both these “outlaw” solution strategies is that they’ll end up with silos by service, major infrastructure transformation costs to secure benefits, vendor lock-in, and so forth. The operators don’t want to face these risks, but that’s not the primary driver. The point I think Verizon/AOL may prove is that operators’ priority is solving their business problem not consuming a specific technology. If SDN or NFV or even the cloud don’t boost the bottom line appropriately, they won’t be invested in.
I believe that SDN, NFV, and the cloud combine to solve all of the operators’ revenue and cost challenges to the extent that any infrastructure technology can. The challenge is defining a scope for them to address enough benefits to justify costs. The pathway to making this work is simple.
First, the cloud is the infrastructure of the future. The network only connects cloud stuff and connects the cloud with users. Thus, we need an architecture for service hosting and one for the building of services from hosted components. I suggested a “microservices” approach to this but any useful architecture is fine. We just can’t build toward a future with no specific technology framework to describe it.
Second, network infrastructure delivers NaaS. Every service in the future has to be defined as a “connection model” and a set of endpoints. The former offers the rules for delivery and the latter defines the things that can emit and receive traffic. The definition, in abstract, has to then be resolved into resource behaviors appropriate to the devices involved. Maybe it’s legacy/MPLS or GRE or VLAN. Maybe it’s SDN. Whatever it is, the resolution of the model defines the commitment of resources.
Third, services have to be modeled from intent through to resource structure through a common, phases-of-decomposition, chain of progress based on a harmonized modeling approach. We have to isolate service definitions at the intent/functional level from changes made to how a function is fulfilled when the service is ordered.
Finally, service automation has to completely bind human and machine operations processes to the model so that all of the lifecycle phases of the service from authoring it to tearing it down when it’s no longer in place are automated based on a common description of what’s there and what has to be done.
The unifying concept here is that there has to be a unifying concept here. Operators, including Verizon, may be risking long-term efficiencies by addressing their “transformation” processes without that unification. But they have to address them, and I guess that if no unified approach is available then lack of unity is better than lack of profit.
There should have been a product for Verizon to buy, not a company. We’ve known about the problem of profit-per-bit for almost a decade, and all of the technology concepts needed to solve it have been around for at least two or three years. Everyone in the industry will now be watching to see whether Verizon’s move can get them to the right place. What we have to learn from is that the industry is failing its customers.
