As communications service providers (CSPs) advance 5G network rollouts, they’re grappling with all manner of new technologies. On top of the technologies themselves though, they face a tsunami of new terminology, some of which seems tailor-made to confuse. Case in point: the subtle but important distinction between “containerized” and “cloud-native.”
Cloud-native software—software designed to run in hybrid cloud environments—has been a mainstay in cloud and IT environments for years, but it’s only recently come to CSP networks. 5G forces the issue, however, as the first wireless standard to assume cloud-native network software by design. Now, as operators evolve their 5G networks, they need container-based versions of network elements, many of which currently exist as virtualized network functions (VNFs). The market has responded, and almost every element in a 5G network is now available as a containerized network function (CNF).
So then, if you’re onboarding CNFs for your 5G network, you can assume you’ll be cloud-native, right? Not necessarily. While “containerized” and “cloud-native” sometimes get used interchangeably, they are not the same thing. Just because a network function runs in a container, that doesn’t mean it’s automatically cloud-native. And in fact, many CNFs on the market right now are not.
What’s the difference between containerized and cloud-native network functions, and when does the distinction matter? Let’s take a closer look.
Going Cloud-Native
As the name implies, cloud-native applications are built to run in public, private, or hybrid cloud environments and take full advantage of the unique attributes of cloud computing. That includes things like resiliency, adaptability, scalability, and observability, all driven by automation. To enable this, the cloud-native model introduces a new way to write software, breaking down traditional monolithic applications into their component “microservices,” multiples running on the same container. These lightweight containers function as independent entities that can be instantiated, moved across different cloud environments, scaled elastically, and torn down again quickly and easily.
By running 5G network elements as containerized microservices, CSPs can take advantage of the cloud agility and efficiency hyperscalers have enjoyed for years. Network functions can become:
- Self-healing, identifying when a container fails and automatically re-instantiating it—in a fraction of the time needed to restore a VNF
- Auto-scaling, elastically scaling individual NF components in and out with demand
- Auto-terminating, with the ability to delete NF components programmatically when no longer needed
Here’s the key distinction though: for an NF to be considered “cloud-native,” it has to support the above specific cloud capabilities in a predictable, stable, and automated way. Running in a container is a prerequisite for that, but it’s those capabilities that make an NF cloud-native, not the container. It’s quite possible to take a traditional monolithic application—one that hasn’t been decomposed into microservices, that can’t auto-heal or auto-scale—and pop it into a container. And in fact, that’s what many 5G network equipment vendors have done.
Migrating current VNFs to CNFs, or releasing new solutions in containers, represents an important step in the digital transformation of the telco space and a baseline to run in 5G environments. But it’s just the first step. Eventually, vendors will fully re-factor most network applications and ensure that they follow cloud-native principles. But in the meantime, you can’t assume a given CNF is cloud-native. If you’re not paying attention, you could find yourself with a containerized NF that can run in your 5G network but can’t deliver the cloud-native agility you expect.
Transforming Network Segments
Does every element in a telco network need to be cloud-native? No. For example, many operators will continue to run 4G/3G infrastructure using conventional VNFs alongside new 5G implementations. Even for newer 5G network elements though, it’s not mandatory that every NF be cloud-native immediately. Re-factoring software requires significant effort, and vendors are doing it in different ways, on different timelines, for different parts of the network:
- 5G Core: As the baseline to develop a full 5G system, the core is the highest priority for cloud-native functionality. And indeed, vendors are moving quickly to evolve Core NFs. Several already provide 5G Core CNFs that follow all cloud-native principles, while others offer containerized solutions that they’re working to make cloud-native as quickly as possible.
- 5G Edge: As operators look to deliver more advanced (and lucrative) low-latency 5G services, they’re disaggregating the 5G Core, moving some workflows out to the edge, closer to users. Given the huge potential of new Edge services, expect to see more cloud-native workflows introduced here soon.
- 5G Radio-Access Network (RAN): Until recently, operators relied on closed, monolithic RAN solutions due to the complexity of this part of the network, and the need to position base stations close to radios. Today, that’s no longer the case. Virtual RAN (vRAN) and Open RAN innovations disaggregate the RAN, giving operators flexibility to introduce new vendors and architectures. Open RAN in particular has introduced many new elements—Centralized Units (CUs), Distributed Units (DUs), RAN Intelligent Controllers (RICs) and the xApps and rApps that run on them, and others. These efforts—all purely software-based—are reinventing what’s possible in radio networks. And they will all follow cloud-native principles in the near future.
Clearly, it’s not essential that every part of your 5G network be cloud-native right now. What is important though is that, wherever you do want cloud-native capabilities, the CNFs you’re onboarding can actually deliver them. If they can’t? You’re back to relying on manual operations for many basic tasks (scaling capacity in response to an event, terminating a CNF that’s no longer needed, spinning up a new CNF when one fails). And you can expect more effort, costs, and complexity.
Know Your CNFs
VMware can help you qualify CNFs you’re evaluating for your 5G network and understand what kinds of cloud-native capabilities they support. As part of our Ready for Telco Cloud program, we work with NF providers to certify their NFs for interoperability with VMware Telco Cloud Platform. And, for solutions designed to support cloud-native functionality, we can validate that CNFs adhere to cloud-native principles and can be automated via VMware Telco Cloud Automation.
The path to cloud-native networks was always going to be complicated—for network vendors and operators alike. But with programs like these, we can help you build the capabilities you need in every part of the network, and move forward on the journey to agile cloud operations.
To learn more visit VMware’s website.
Iciar Corral
Telco Solutions Architect
With 20+ years of experience in delivering customized solutions to key clients in Telco Industries worldwide, Iciar has worked on Telco Cloud products and solutions with different carriers around the world. A technical lead, Iciar focuses on unique deployment models with deep technical background in mobile and internet.