The Cloud-Native Telecom Future

By: Reed Peterson

The telecom sector is in the midst of making some serious bets about the future. The advent of the pandemic forced many companies, telecom operators included, to speed up their digital transformation initiatives. According to TM Forum’s Digital Transformation Tracker, the number of operators that said they were midway through their implementations jumped from 23 percent in 2020 to 38 percent in 2021, while 42 percent had started their moves. In total, 80 percent of companies are going through major changes today.

This work includes both external customer experience and internal operations—more than 65 percent of communication service providers (CSPs) are making changes here—while around 45 percent are implementing cloud-native technologies as part of these moves. According to Omdia research on BSS adoption trends, 34 percent of CSPs plan to refactor their BSS applications to be cloud-native in 2021.

The change to cloud-native

Moving to the cloud—whether public, private or a hybrid approach—involves a change in approach. Rather than simply moving existing technology to a different platform, migrating to cloud-native involves some changes in architecture. For many organizations, this change represents a potential source of risk. The potential benefits, however, far outweigh the exposure.

The term ‘cloud-native’ refers to technologies or processes that have been specifically developed with cloud in mind. Rather than taking a traditional approach that would previously focus on how to implement single machines or datacenter instances, cloud-native designs are built to scale up from the start. They are designed to run across multiple locations and services as their default, rather than being extended. Changing to a cloud-native approach can help CSPs to disaggregate their software, essentially moving to a more compartmentalized model that can scale up and down based on real demand levels. 

This approach is commonly referred to as a microservices design. Rather than creating large applications that cover all functionality in one monolithic code base, microservices designs split each service into discrete components. These components connect to each other to produce the same results for the customer. Rather than requiring full-scale integration at huge cost, all traffic goes through APIs between components.

Putting applications into smaller units makes it easier to adopt new services or launch new applications for customers. A good example of this approach is Netflix: each service on the Netflix homepage is a different microservice covering functions like search or recommendations. If a new service is needed, it can be built in the background and then added once it is ready using APIs. Changes in existing software components are easier to handle; as long as the APIs provide the expected results back to the other service components, the actual software or application behind the API does not matter.

As demand for a service goes up—for example, more customers start using a service, or network traffic increases—then the application can add more resources that are needed automatically where they are needed. The result from this? More efficient systems and lower costs, while still delivering at the level of reliability that all CSPs need.

All this work points to a change in how CSPs think about their approach to serving customers, providing services and—most importantly—using data in their operations. These changes will affect multiple areas around how CSPs run their services from activation and provisioning through to inventory, authentication, and ongoing network performance. Each of these areas connects with each other to provide what customers expect, so any change can have a knock-on effect as well.

Migrating to cloud-native means looking at data

Deploying cloud-native applications or services does involve looking at the data that those applications create, too. Each service within a telecom company’s infrastructure must be reliable and available, and traditionally that would have meant a fully redundant data center deployment. Moving to cloud-native should deliver reduced costs and more flexibility around how and where to deploy, but this cannot be at the expense of availability. Any deployment will have to deliver the same level of redundancy.


Latest Updates

Subscribe to our YouTube Channel