Recently, I blogged that the transformation of NFV from VNFs (VM-centric) to CNFs (“cloud-native” or “containerized” network functions, depending on your level of cynicism) was unlikely to be successful. One long-time LinkedIn contact and fellow member of standards groups said “If CNF never makes it… then the whole story is doomed and it’s a bad sign for Telcos’ future.” So…will CNF make it, and if it doesn’t then is the whole NFV story doomed, and if that is true, is it a bad sign for Telcos’ future? Let’s see.
Red Hat is one of the many cloud/software players who embraced NFV as part of its telco software story. They have a web page on the VNF/CNF evolution, and I want to use that as an example in the rest of this discussion. Not only is Red Hat a premier player, their stuff represents a “commercial” view of the situation rather than the view of standards-writers, which are often a bit obscure.
The Red Hat material starts with a true statement that, nevertheless, needs some amplification. “Virtual network functions (VNFs) are software applications that deliver network functions such as directory services, routers, firewalls, load balancers, and more.” That’s true, but it’s a specific example of the unstated general case that VNFs are a hosted/virtual form of a physical network function, or PNF, meaning some sort of device. The original NFV model was all about replacing devices, and routers were actually not on the original list.
The PNF origins meant that “In the initial transition from physical elements to VNFs, vendors often simply lifted embedded software systems entirely from appliances and created one large VM.” There was some debate on whether “decomposition” of existing PNFs into components should be required, but that was contrary to the base PNF-centric mission and had (obviously) little vendor support. Thus, VNFs were virtual devices, monoliths.
It took time, more than it should have frankly, but the NFV community eventually realized they needed something different. “Moving beyond virtualization to a fully cloud-native design helps push to a new level the efficiency and agility needed to rapidly deploy innovative, differentiated offers that markets and customers demand.” Since the cloud was shifting toward containers rather than VMs, “different” morphed into “containerized”. “CNF” could be said to stand for “containerized network function”, and to some it did mean that, but as the cloud became the specific target, CNF turned into “Cloud-native Network Function”.
Containers, of course, are not automatically cloud-native, and in fact my survey of enterprises suggests that most containerized applications aren’t cloud-native at all; they are not made up of microservices and are not fully scalable and resilient. Containers are a step forward for VNFs, but we might be better thinking that the real goal is a “CNNF”, which obviously means a cloud-native network function. The CNNF concept would admit to a service built from functions/lambdas, hosted serverlessly but not in containers, and also focus on the harmony with the cloud.
The final thing I want to pull from Red Hat is this interesting. Referencing the need for an open, consistent, foundation for telcos, they say: “Building that foundation on NFV (with VNFs) and especially cloud-native architectures (with CNFs) results in improved flexibility and agility.” This defines what I think is the critical shift in thinking. NFV means VNFs, and cloud-native or CNFs means not NFV, but cloud architectures. Red Hat is preparing a graceful transitioning out of NFV into the cloud, retaining the notion of network functions but not the baggage of NFV.
Or maybe not, or maybe only some. If we assume containerized cloud-native elements, then we can assume that services built with CNFs would have all the container elements needed to deploy on an arbitrary cluster of resources (the “telco cloud”); they carry their instructions with them. A service could be visualized either as a set of functions that created a virtual device (what NFV would have treated as a monolith), or as a set of functions, period. That would seem to substitute cloud resource management and orchestration for NFV’s MANO, a cluster or clusters for NFVI, and CNFs for VNFs. One thing left is the notion of VNFM.
The goal of VNFM was/is to present function management in the same way that device management was presented when a VNF was created from a PNF. We can’t expect the cloud to manage network functions with cloud-specific tools; the CNFs are “applications” to the cloud, and their management would be more specialized. There’s also the question of the extent to which function management has to be aware of function hosting, meaning the underlying resources on which the CNFs were deployed. NFV never really had a satisfactory approach to that, just a name and a loose concept of PNF/VNF management equivalence.
CNFs could, then, fall prey to this issue. Before NFV ever came about, I’d proposed that hosted network features had to have a management interface that was composed rather than expressed, using what I’d called “derived operations”. This was based on the IETF draft (which, sadly, didn’t go anywhere) called “Infrastructure to Application Exposure” or (in the whimsical world of the Internet) i2aex. You used management daemons to poll everything “real” for status and stored the result in a database. When a management interface was required, you did a query, formatted the result according to your needs, and that was your API.
The advantage of this approach is that it lets you grab status information from shared resources without exposing those resources to services, which could at best overload resources with status polls, and at worst lead to a security breach. We don’t have that in CNFs as the NFV ISG sees them, and Red Hat doesn’t appear to assume the approach either.
VNFM seems to be the only piece of NFV that’s 1) needed for cloud-native function virtualization, and 2) not specifically adapted to the cloud by the CNF initiative. Since I would argue that the NFV ISG version of VNFM wasn’t adequate for multi-tenant services in the first place, adapting that wouldn’t be worth the effort. Since the cloud really isn’t addressing the specific issues that VNFM did (inadequately, as I’ve said), we can’t expect the cloud to come up with its own strategy.
When I advocate that we forget NFV, write off the effort, I’m not suggesting that we don’t need something to support hosted virtual functions in networking, only that NFV isn’t and wasn’t it. I’d also suggest that if the NFV ISG and NFV supporters in the vendor community think that CNFs are necessary, then they should accept the fact that just having CNFs doesn’t make NFV a cloud technology. We need the equivalent of VNFM, and I think the i2aex model I mentioned is at least a credible pathway to getting that. It may not be the only one, but it’s at least an exemplar that we could use to undertake a broader search.
Where does this lead us in answering the question I raised at the start of this blog? Vendors are answering it by blowing kisses at NFV while quietly trying to do the right thing, IMHO. That’s better than doing the wrong thing, but it means that the NFV ISG initiatives aren’t working, and won’t work, and the reason is that standards-related bodies worldwide have always been reluctant (well, let’s be frank, unwilling) to admit their past efforts were wasted. We’ve spent a lot of time trying to make cosmetic changes to NFV rather than substantive ones, all the while ignoring the truth that the cloud has passed it by in almost every area, and leaving the one area where the cloud probably won’t help lie open. CNFs won’t fix NFV, and if that means it’s in trouble, then we’d better start dealing with that.
