Communications Service Providers (CSPs) are building cloud-native communications networks; for example, cloud-native deployment of 5G networks is the state of the art. However, at the same time, CSPs are also faced with mountains of legacy, even bare-metal, platforms for more mature services such as voice, messaging, and multimedia services. The pace of change here is slower because CSPs are wary of innovation using older architecture.
When replacing legacy services, it would just be great if you could do so via Cloud-Native Network Functions (CNFs). But alas, we’re not in the best of all possible worlds and your network might very well not yet be ready for containerization.
There are at least three possibilities we discuss with our customers when faced with this:
- Implement services as Virtual Network Functions (VNF) with a VNF manager, such as Cloudify or Nokia’s CloudBand Application Manager (CBAM) and have a clear plan to later replace these VNFs with CNFs. Here, as elsewhere, cost control is particularly important; that’s why we give our customers a fixed-price for the later CNF deployment and do not require they repurchase additional licenses or software. This strategy is future-proof and cost-effective on your way to a cloud-native solution.
- If you are not currently using a VNF manager (VNFM) and would prefer to leapfrog over network functions virtualization infrastructure (NFVI) to cutting-edge CNFs, consider deploying telecoms services as CNFs over bare-metal infrastructure with Kubernetes-based management and orchestration.
- If you already have a complete NFVI platform with VNFM but want to start with cloud-native deployment of telecoms services, you might also deploy our low-code service platform as CNF; this can be achieved by adding a container as a service layer on top of an OpenStack NFVI.
Here’s an example of 1 and 3 above. One of our customers, a tier 1 multinational CSP, needs to replace legacy platforms for telecoms services. In several of its national networks, this CSP already has implemented telco-cloud automation via VMWare, so that we can deliver CNFs to replace the legacy service platforms and provide our cloud-native Telecoms Low Code Application Platform for the creation of new apps and services. In other national networks, this same CSP is not yet ready for a cloud-native solution, so that we suggested deploying VNFs; we agree to replace these with CNFs in the relatively near future, charging only for the deployment.
I hope you see that we’re doing our best to pave a smooth and affordable road towards CNFs for all the many network and telecoms services we deliver based on our Telecoms Low Code. Moreover, containerization and CNFs play in general an essential role in how we see new low-code services being deployed: each service or app being implemented with all its required resources in its own self-contained CNF orchestrated via Kubernetes. Exciting, isn’t it?
Please reach out to me, if you’d like to know more about this or share your experiences with cloud-native architecture for telecoms services.
