Once upon a time in NFV Telco wonderland

There is no doubt the future of Telcos includes cloud technology. However, sometimes we forget to explain what is long acquired as evident when we talk about our current challenges. As Carl Sagan once said, "You have to know the past to understand the present."

The main pitfalls I saw in NFV

Looking back, I remember the initial scepticism about NFV, with the daily comparison with bare-metal CapEx/OpEx, deployment timeline and performance. Fortunately, NFV overcame the CapEx/OpEx and agility battle, but the deployment timelines and performance battle not so much.

But let's get to the point. What were the main pitfalls I saw during the last years?

1. Some VNFs were not cloud ready: At this point, I've seen it all, some vendors translating the bare metal solution to a "virtual" solution where the requisites were not cloud ready, others asking for 0,5 vCPUs for a VM saying they don't need more. It was rather usual to vendors require dedicated virtual HW with bespoke requirements instead of following the blueprint. Of course, this reduces the performance and increases the timelines to deploy. However, as time passed, VNFs and Telcos private clouds' maturity evolved and helped surpass some technical issues that appeared initially. Teamwork is like dream work!
2. Operating Model and collaborative tools not adapted to the new reality: This is a joint pain for this NFV transformation and every digital transformation project. There is a part of the organisation that is changing rapidly, although other areas not so much. What is the drawback? We are only as fast as the slowest member. I experienced VNF's upgrades where the organisation was technologically ready to do it in 1/2 days. However, we took a couple of months because of not adapted operating model across areas. Also, the culture of collaborative tools was not yet adopted and accepted. We can't be efficient if we chat in emails and have hundreds of emails to read. We might become "high importance email reactive" persons, which is awful for engineers' bright minds.
3. Trying to have Big Bang projects in brownfield Telcos:  A Tier1 once asked me to perform an operating model cloud-native ready without having most of the network visualised. Another wanted to orchestrate the network without having the minimum maturity. It is essential to understand that every Telco will have its journey, and we must make many decisions (e.g. LCM, HW, VNFs design, and the VNF vendors). You can't begin right on K8s and have a fully cloud-native network turnkey project. We need to accept that for brownfield Telcos, the journey is longer and more painful. In my opinion, the three secret ingredients to succeed in this transformation are 1) culture change, 2) vendors with the same culture and 3) having a feasible plan where we begin with some concrete use cases.
4. Lack of data analysts: NFV can be a paradox since we want to be more efficient by adding a complexity layer to the network. Also, operators began to have power and visibility on something that previously was a black box. In other words, we need to manage VNFs/CNFs, the infra that supports it and integrate with the rest of the ecosystem while being more efficient. How do we work with all this? Well, with a lot of data analysis to support our Engineering decisions and stop the: " Add 20% on top just to be sure". 

What is cloud-native and why do I need it?

I define a cloud-native Telco as a fully virtualised and almost fully orchestrated network. Also, most network functions should be containers instead of VMs. Besides, we should have monitor tools to know what is happening in this complex environment and predict future network issues.

However, this is my pragmatic view, and I could spend hours having philosophical discussions about this (with a good bottle of wine, of course).

To understand the why, I'll ask and reply to the two main questions stakeholders made me during the past year:

Why is cloud-native so important in 5G core?

With cloud-native, aka having CNFs and orchestration, we can begin to have the futuristic promises of 5G, such as ultra-low latency and mission-critical that were not possible before. We can also have the network capabilities exposed to extract their value. In other words, we have a very powerful lego! Another main benefit is accelerating the design and deploy of containerised network functions (CNFs) through CI/CD pipelines. However, I think this one for most Telcos I worked with is not for the near future.

Why containers?

Containers are the natural evolution of what we have today (VMs). Containerised network functions (CNFs) are the true beginning of microservices applied to the network. They can lead to quicker deployment, higher agility and resiliency of network functions when compared to VNFs (VMs based). With this, we can leverage the scalability, low CapEx and OpEx promised by NFV but only partially achieved (Yes, network functions can be cheaper and more efficient!). However, this challenge should be considered as a journey and not a turnkey project, and that's why we will see VMs and containers co-exist together for a while in Telcos.

What's next?

With cloud-native 5G networks, we will have a massive amount of data, and we continue to manage infrastructure and SW that is still relatively new for us. With all of this, we need to collect our network data efficiently and correlate it. Also, we need to bear in mind that data give us answers only with new tools and practices.

However, I'll let this discussion to another post.

Stay safe!