Everyone who’s followed NFV knows that there is a relationship between NFV and the cloud. Logically there would have to be, because public cloud services host applications on a per-tenant basis with tenant isolation for security and performance stability. That’s what network features for individual customers need, so it would be totally illogical to assume a totally new multi-tenant approach would get invented when NFV came along.
The thing is, this simple justification would lead you to believe that not only was there a relationship between the cloud and NFV, the two were congruent. As you’ll see, I think it’s very likely that NFV and the cloud will evolve into a common organism, but we’re not there yet. That current separation is something that proponents of both NFV and the cloud need to minimize, and that a lot of NFV marketing is exploiting in a cynical and negative way. Thus, we need to understand just what the relationship between the cloud and NFV is, and what the differences mean right now.
A good discussion of differences should start with similarities, if for no other reason to prove that convergence of NFV and the cloud is not only inevitable, it’s already happening. Cloud computing is a computing architecture that allows components/applications to be hosted on shared servers in a highly separated (multi-tenant) way. The obvious advantage of this shared hosting is that the cost of the servers are amortized across more applications/users and so the per-user cost is less. This is analogous to the “capex reduction” benefit of NFV.
The problem is that pooled, shared, resources are not infinitely more efficient as they become infinitely large. There’s a curve (expressed by the Erlang C “cumulative distribution” curve) that shows that utilization efficiency grows quickly as the resource pool gets bigger, but this tapers off to eventually a plateau and further increases in the pool, even large ones, make little difference. The biggest savings occur early on. What that means is that enterprises with large data centers approach the efficiency of cloud providers, which means that public cloud services couldn’t save much in the way of capex. Note that operators have quietly shifted away from a pure capex-driven NFV value proposition.
Fortunately for cloud providers and NFV proponents there’s another force at work. Most SMBs and even some enterprises have found that the cost of supporting IT infrastructure is growing faster than the cost of the infrastructure. For many, TCO is already two-thirds opex to one-third capex. By adopting a cloud model of IT (particularly SaaS, which outsources most support) a business can transfer operations to a player who can get access to skilled labor and use it efficiently. If we look at the savings side of cloud computing’s benefits, opex reduction is now the most compelling story. And that is also the same with NFV.
Cost reduction vanishes to a point, though. You can’t justify major technology revolutions through cheapness because at some point the percentage reductions in expense that you can present won’t fund the technology changes any more. ROI based on cost management always declines over time, so you need to have something else—new benefits. For cloud computing, this means turning the cloud into a new-age application architecture that can do stuff that was never done with traditional IT. Amazons growing repertoire of cloud services or my notion of point-of-activity empowerment are examples of a benefit/revenue-driven cloud. For NFV, this is the “service agility” argument.
What’s the difference between NFV and the cloud, then? The first answer is that because NFV targets large sophisticated buyers, it has to do a better job of harnessing benefits from its incremental costs or there will be no movement to NFV at all. NFV is in many ways a kind of super-DevOps, an architecture to automate the processes of deployment and management to the point where every erg of possible extra cost has been wrung out, every inefficiency of utilization eliminated. First and foremost, NFV is a cloud-optimizing architecture.
Because NFV addresses today (for its prospects) the problems all the cloud will face down the line, “cloud” approaches look a lot like NFV approaches if you just look at one application/service in one limited test. Most of the NFV PoCs, for example, really look more like cloud hosting than dynamic, agile, flexible NFV. This has allowed virtually every vendor who purports to have an NFV story to over-promote what’s really a cloud value proposition. You can replace many custom network appliances not with virtual functions but with cloud components, and that’s particularly true for functions that have very long lives. Where NFV becomes critical is when you have to do the deployments a lot, often, for short intervals.
NFV’s “service agility” benefit depends largely on evolving how services are built to generate more of this dynamism. This point gets missed a lot, in no small part because vendors are deliberately vague about the details. If we need to rethink service creation, we necessarily have to spend some time considering the new architecture. It’s a lot easier to say that we’ll cut provisioning time from two months to two days, which is great for time-to-revenue, right? But if the customer didn’t want the service in two days but had two months’ notice (as opening a new office would likely offer) we have less chance of any revenue gain. If the customer has the service already we get nothing; you can’t accelerate revenue you’re already collecting.
Here in facing the service dynamism issue, interestingly, the cloud may be leading NFV. I believe that Amazon knows darn straight well that its cloud service future lies in being able to build cloud applications that are cloud applications, totally unsuitable for premises execution. I also believe that we are seeing, in the mobile revolution, more and more situations where these new cloud applications could be a major benefit to users and a major revenue source. That’s where my trillion dollars a year in incremental revenue for point-of-activity empowerment comes from.
NFV has led the cloud in recognizing that DevOps has to grow a lot to manage the scale of computing that cloud success would imply, and to manage the increasing dynamism that exploiting the cloud’s special characteristics would create. But NFV has been totally unable to deal with the issue of how dynamism is realized, how application components that create dynamic experiences become service components. The OTTs and the cloud developers are thinking more about that than the network operators and the NFV advocates.
Neither NFV nor the cloud can now succeed without the other. Without NFV, the cloud’s growth will expand its cost of operations in a non-linear way until there’s no further benefit that can be realized. Without the cloud and an understanding of the notion of cloud-specific services/applications, NFV will never realize a nickel from service agility and stall out when operations costs can’t be reduced further. The question is which constituency—cloud/OTT or network operator—is going to get smart first and address the issues that the other constituency today is handling a lot better. It may be that if the “cloud” wins, OTTs win and operators are forever consigned to public utility business models no matter how they’re regulated. If NFV wins, then operators have a darn good chance of making the OTTs of today into the CLECs of tomorrow.
