Code Never Lies

Network

With code, it either works, or it doesn’t


With telecom networks becoming increasingly virtualized, we deal less and less with ‘boxes’ and spend more of our time looking at code. In theory, this should make introducing a new service or network function much easier. As the saying goes, code never lies. It either works or it doesn’t. And when it doesn’t, you fix it.


In practice, it’s not quite as straightforward, and industry take-up of network virtualization has been hampered as a consequence. The answer, I believe, lies in adopting an open source approach.

Ending the pain of VNF onboarding


Even though you now don’t have hordes of engineers delivering and installing new equipment, adding a new VNF to your network (VNF onboarding) is still a time-consuming and costly exercise.


The new VNF should be ‘orchestrable’, and the VNF vendor will typically provide the automation scripts and artifacts, such as descriptors and relevant APIs, needed to make it compatible with the operator’s orchestration platform.


Once the VNF has been ‘onboarded,’ the operator needs to test its compatibility with other VNFs it has to talk to, and with the network as a whole. If automation artifacts are found to be incompatible, or if the vendor simply hasn’t provided them, this sets off a lengthy troubleshooting process for the operator.

Troubleshooting today


In my experience, the process of fixing errors and plugging gaps is one of the costliest aspects of NFV network deployment today.


Resolving a trouble ticket – no matter how small the error – typically involves everyone from the VNF vendor’s tech support to product management, network engineering and R&D to the developers who will ultimately amend the code.  In addition, staff from the service provider’s organization will be tied up in this process as well.


The iterations between vendor and operator can easily eat up over a third of the overall budget. What’s more, they may ultimately negate some of the benefits associated with virtualization, not least cost efficiencies and reduced time-to-market for new services.

Fixing code the open-source way


This is where the open source approach has a distinct advantage over traditional telecom business models.  Open source code is in the public domain, not hidden away in a ‘black box’ like proprietary vendor solutions.  This means that VNF onboarding can be dramatically simplified compared with the troubleshooting process described above.


If we take the ONAP orchestration and automation platform as an example, as an open source project, its code will be completely transparent to both vendors and operators.


This has two immediate benefits. The first is that vendors can now pre-configure their VNFs to work with ONAP, ahead of rollout.  The second is that when onboarding throws up technical issues, they are much more straightforward to resolve by amending orchestrator and VNF code directly. This eliminates the endless to-ing and fro-ing between vendors and operators, leading to significant time and cost-savings on both sides.


Taking a collaborative approach


If you consider what open source has already done to transform operating systems (Linux), virtualization infrastructure (OpenStack) and big data (Hadoop), the benefits of taking this collaborative approach – rather than relying on proprietary solutions or standardization bodies – are clear.


As I said before: code never lies: it either works or it doesn’t. The beauty of open source over proprietary approaches is that, when it doesn’t, you can fix it more easily and quickly – and the wider industry benefits from your contribution.

Summary

With telecom networks becoming increasingly virtualized, we deal less and less with ‘boxes’ and spend more of our time looking at code. In theory, this should make introducing a new service or network function much easier. As the saying goes, code never lies. It either works or it doesn’t. And when it doesn’t, you fix it.

Follow

Add New Comment

Add new comment

Summary

With telecom networks becoming increasingly virtualized, we deal less and less with ‘boxes’ and spend more of our time looking at code. In theory, this should make introducing a new service or network function much easier. As the saying goes, code never lies. It either works or it doesn’t. And when it doesn’t, you fix it.

Follow