Historically, Communication Service Providers (CSPs) networks ran on purpose-built hardware. However, in the early 2000s organizations started to update their infrastructure, moving to virtualization. Now, providers are looking to take the next step, and cloud-native models are becoming the industry’s most sought-after solution. For CSPs, transitioning to a cloud-native environment is essential for modernizing their network to deliver the services customers demand and reap the benefits of opportunities, such as those dependent upon 5G. The migration is the ultimate step in a decades-long digital transformation process.
In fact, a Heavy Reading survey showed telcos believe that digital transformation to cloud-native required cloud computing (46%), edge computing (45%) and 5G (36%) as the most important aspects to support the journey. When asked more specifically about their priorities, service providers shared that they are investing in cloud-native solutions to improve agility, scale, and efficiency (36%), bolster network alignment, (36%) and create a service-oriented architecture (28%).
But the journey to cloud-native isn’t always straightforward, and the path is different for every telco. To help, I’ll work to break down the challenges of the cloud-native journey, explain why the benefits outweigh the concerns and provide prescriptive steps to choose the right path for every CSP.
There are several reasons why service providers would benefit from moving real-time communications beyond hardware and virtual network functions (VNFs).
The first is that deploying communications as a cloud-native function (CNFs) can be an incremental investment for service providers driven by 5G.
While virtualization and VNFs took us some of the way towards automation and the ability to separate application logic from the underlying infrastructure, we’re already seeing new use cases with CNFs that simply weren’t previously available.
Finally, due to technological advancements, we now have a de-factor orchestration environment with Kubernetes. That wasn’t the case with VNFs. Kubernetes is backed by strong community involvement and an emerging talent pool dedicated to simplifying how service providers move communications to cloud-native environments.
And this isn’t just pie in the sky. Several leading providers, including AT&T, T-Mobile, Verizon, Dish and more, have publicly discussed their cloud migration plans. Whether it’s to improve efficiency, scale, or agility, CSPs are making a move.
The migration to cloud-native does not come without challenges. During the transformation, CSPs must answer tough questions, such as how do we choose the best solution for our communication workloads? Is it public, private or hybrid? How do we manage the co-existence of cloud native functions and virtual network functions environments without duplicating costs? How do we ensure we choose the right solution that addresses our unique needs for real-time communications?
Concern isn’t a reason to halt progress, though. Teams need a plan to stay competitive and reap the benefits touted by cloud-native environments. The best way to start is with a detailed and well-researched cloud migration strategy.
The first question providers need to answer is which cloud model is suitable for our network? Cloud models consist of three unique categories, all of which are dynamic and will continue to evolve.
A public cloud model is notable for streamlining the overall implementation process, including cost, time to market, and geographic reach. When it comes to the VNF to CNF transition, public clouds offer a quicker migration process, bypassing the need to deal with the underlying infrastructure investment. Public cloud also delivers an expanding suite of offers for the telecom core and edge. While it is evolving, the major drawback of public models is that they were not originally designed for real-time communications workloads, and also offer fewer opportunities for customization.
Private models are a common choice for many service providers because they offer complete control over the delivery of real-time communication workloads. However, since a private cloud infrastructure is not outsourced, it must be maintained internally, which can be costly and time-consuming, especially regarding expansion, and the migration from VNF to CNF can be challenging.
Hybrid models are a unique third option for service providers but are often misunderstood. It is not a simple case of choosing the best parts of public or private models. Hybrid models shine when service providers have a clear understanding of their current infrastructure and what their strategy is for the future. For example, a service provider might choose a hybrid model and use a public cloud to augment a private cloud deployment. Or perhaps they’d deploy new CNFs on a public cloud and cap VNF deployments on a private cloud.
There are many options for hybrid. If companies can identify what specific features they need, hybrid models can be a fantastic, customizable option. A good question to ask is, where are you now, and where do you want to go?
With a cloud deployment model identified, it’s now essential to map out how teams will manage the co-existence of VNFs and CNFs. It can be very challenging to ensure a seamless transition without duplicating costs. Two main strategies exist to solve this problem: automation and a common management system.
Automation is one of the primary keys to any successful cloud-native deployment. It helps simplify all aspects of deployment, from infrastructure to lifecycle management to provisioning, testing and more. When automation tools and processes are designed optimally, those same processes should be backwards compatible with managing VNFs, simplifying the transition from virtual to cloud environments.
That’s not the only benefit, though. Automation can also reduce OPEX costs. When you reduce errors, you help eliminate configuration drift and can support faster troubleshooting with an external source of truth. Finally, you can deliver features and services more rapidly.
In addition to automation, the benefits of having a common management platform that equally supports VNFs and CNFs cannot be overstated.
These systems need to support access control, observability, configuration management, analytics and more. The integration of those functions should be independent of the application system and agnostic to the deployment environment. By deploying a common management system, CSPs can simplify OSS/BSS integration, streamline complexity of monitoring and managing microservices in CNFs, deliver a consistent user interface regardless of VNF or CNF deployment, and make the migration process as transparent as possible.
What are the key attributes of this type of system? Smart CSPs will look for options that leverage a single pane of glass mentality, allow for cross-functional use and the delivery of actionable data for application management, observability, and system health functions.
Real-time communications workloads are not the same as their web-based data counterparts, — several unique attributes need to be considered. For instance, voice calls are only managed by knowing the state of the call, which can be hampered by erratic network behaviors or periodic maintenance. To solve this, CSPs need to have cloud-native implementations that ensure high availability, distributed and accessible memory caches and multiple instances for reliability. Providers also need to consider elasticity and session optimization. Solutions that support a single cluster view, fast failure detection and intelligent session distribution will be critical.
The migration to cloud-native won’t happen overnight. It could take months and years, but don’t doubt that it has started. CSPs that delay any longer will struggle to compete in today’s rapidly evolving market. To ensure the transition is seamless is as possible, it’s imperative to identify the right cloud model, efficiently manage the VNFs and CNFs, and find the right tools and partners that understand how to support the unique attributes of real-time communications in the cloud.
By Dan Teichman
