If you’ve been in the telecommunications world for some time, you’ll know that we occasionally borrow ideas and technologies from IT, move it into the telco space, and call it something more complicated so we can look smart.

The server virtualization initiative in enterprise and cloud data centers was called “virtualization” – big surprise. When we moved it into the telco space we amped up the sophistication-level by renaming it “network functions virtualization.”

To be fair, NFV included more elements than just the platform virtualization (NFV-I/VIM). It also demonstrated how the existing element management systems (EMS), which configure these virtualized network functions (VNF), could exist in the framework and introduced VNF managers. Further, it showed how an orchestrator might fit and how the system could interface with OSS/BSS. Now, as we move into the world of containers, we’re moving forward with much less structure on how to achieve this new concept labelled cloud-native network functions (CNF) – again, a fancy term for, primarily, container technology coupled with microservices architecture.

NFV Framework – Helping or Hurting

The original NFV framework was our best attempt at formalizing a structure under which our collective community could move into the world of virtualization. But I’m wondering if that structure did us a disservice.

For years, we tried to force-fit different components into the NFV framework only to realize that there wasn’t just one VNF manager – the holy grail of a generic VNF manager being near impossible to achieve – but multiple VNF managers. We grappled with OpenStack as a VIM, fighting to get it installed and deployed but realizing it was hard to upgrade, especially in the early days. We mucked around in the NFV-I, working to accelerate workloads and attempting to achieve similar performance numbers to hardware counterparts without comprising portability. And as we wrestled OSS/BSS integration to the ground we tried to fathom the role of the orchestrator.

Collectively, perhaps we should have put more effort into making sure the VNFs were properly virtualized and not just NFV-washed port-overs of their physical counterparts. Without proper APIs for orchestrations, lifecycle management, telemetry, and performance information the VNFs were just facsimiles of their physical counterparts, unsuited for NFV. Instead, it seemed like we spent more time trying to stand up an infrastructure that looked like the ETSI NFV framework.

Now, as we face another jump into the world of CNF, I’m wondering if we’ll be better off this time because we’ll be less prescriptive in terms of how this next evolution happens, or will we be worse off for lack of a well-defined structure?

Journey From VNF to CNF

Looking back, I’m torn on the NFV journey thus far. On one hand we’re at the ETSI NFV Release 3 specification and we’ve learned a lot around acceleration, license management, VNF onboarding, and multi-site management. We’ve come to grips with the complexity of OpenStack and also now understand the need to bring in CI/CD and testing. On the other hand I’m wondering if we had asked a cloud service provider or an enterprise to “virtualize” our network functions would we have had a better outcome? Without our complicated NFV framework perhaps we would have ended up with a leaner and meaner version of NFV that worked efficiently without all the trappings of OpenStack, VNF-Ms, NFV-Os, etc.

As we stand on the cusp of making the next leap, do we drag NFV into the CNF world? Or do we take the learnings but start with a clean slate? If we look at NFV’s evolution from October 2013, when ETSI published the first group of documents, and compare it to the cloud world, what do we see?

Docker started in 2013 too, and just look at the meteoric rise of containers. Arguably, they leveraged existing elements, but so did NFV – virtual machine (VM) technology wasn't new. Kubernetes was introduced in 2014 by Google; and Microsoft, Red Hat, IBM, and Docker joined on in July of that year. Linkerd and Envoy were introduced in 2016, followed by the launch of Istio in May 2017 by Google, IBM, and Lyft. Again, we don’t need to belabor the success of Kubernetes or Istio. Other examples abound, but these are sufficient to allow us to compare the uptake of technologies in the cloud world versus the telco world.

None of these cloud successes came from a specification or a standards body working together – they were driven by a need and a bunch of smart engineers coming together to create a solution to that need. The solutions evolved, sometimes internally within a large company and sometimes externally, as open-source projects with a certain amount of Darwinism prevailing.

So, as we enter the CNF world, perhaps leaving things a little more organic and taking an open-source software-centric path is the right way. There are efforts underway at the Cloud Native Computing Foundation (CNCF), which is part of the Linux Foundation, with the containerization of ONAP and OPNFV, as well as projects like Ligato and network service mesh. As we make progress maybe we’ll learn how to do it the right way and spread that message organically.

CNF-Washing, the New NFV-Washing

Speaking of containerization, remember NFV-washing? Well, we’ll see lots of CNF-washing now. Squeezing a big fat VM into a container isn’t CNF. To get to cloud-native network functions we need to take a VNF and break it into component microservices. And then we need to figure out how to orchestrate those pieces and turn over control to Kubernetes.

Wait, Kubernetes is the VNF-M? Is it the NFV-O? Or do we control Kubernetes from an external NFV-O? Perhaps Kubernetes is all of it because Kubernetes needs to orchestrate between the microservice components of all the running VNFs. The stories we tell about breaking VNFs into components like the DPI classification engine microservice, the encryption and decryption microservice, the packet transformation microservice, and so on are good stories. As are those that claim we can now scale the DPI engine microservices independently from the encryption engine. But are we really there yet?

Not quite. Kubernetes needs to be outfitted to play that role of a microservice VNF component orchestrator. And what about resource consumption and scheduling between VNFs? And wait, why do I need 10 different DPI microservices from 10 different vendors doing the same job? Ah, the challenges and the opportunities for all the vendors.

Service-Based Architecture (SBA) and 5G

While we watch the organic evolution from NFV to CNF, and while the CNCF and Linux Foundation try to shepherd some of that along – since they and their constituents have much to gain from those efforts – let’s turn our attention to parallel efforts driven by another standards body, the 3GPP. Remember 5G? We have a massive infrastructure investment and NFV, and possibly CNFs, will be part of that. The 3GPP has created the telco twin of microservices architecture that works with VMs, but is ostensibly better with containers: the service-based architecture (SBA). To demonstrate that there’s a formal telco framework in place, here’s the architecture of SBA:

There are enough acronyms to make this justifiably a telco effort. I predict we’ll see a lot more of SBA in 2019, as I’m already seeing it appear in analyst briefings from 5G players like Ericsson, Nokia, Huawei, and Interdigital. SBA, microservices, and containers will be uttered in the same breath and we’ll see it plastered across many trade show booths this year.

So, Are We There Yet? Are We There Yet? NO, We’re Not There Yet!

We’re barely scratching the surface in the telco move from VMs to containers. In reality we haven’t really figured out why our last move to NFV with VMs took us so long nor why we had so many failures. But hey, there’s a shiny new object on the horizon. And containers will save us where VMs didn’t. So NFV is dead, long live CNF! Except, maybe we’re not quite there yet. Maybe in a year, or two, or three.