Busting the myths around cloud-native cores

[Oded]

Cloud is transforming every part of the technology world, and communications service provider (CSP) networks are no exception. This transition starts in the core, where 5G requires operators to make the jump to cloud-native network functions (NFs). But what, exactly, does cloud-native mean in a 5G core? Not necessarily what you think it does—and definitely not what some vendors would like you to believe.

If you’re still trying to wrap your head around the full implications of adopting a cloud-native core, you’re not alone. Once you step into the world of containers, microservices, and Kubernetes clusters, things get complicated quickly. But you definitely want to get the facts now—before you invest in something that’s advertised as “cloud-native” but doesn’t actually deliver what the technology is supposed to provide.

HPE can help with our new webinar series: Demystifying Cloud-Native 5G. We're offering insights from independent analysts and HPE technology experts on the practical aspects of using a cloud-native core. We can help you separate fact from fiction, hype from reality, and learn what running the fully cloud-native HPE 5G Core Stack can mean for your business.

The road to a cloud-native core

Before diving into what cloud-native means—and what it doesn’t—we should review how we got here. Why bother going cloud-native in the first place? For several reasons:

• It’s fast. At the end of the day, core network functions are software applications—which means they can benefit from the same agile software practices the big cloud hyperscale companies enjoy. That includes much faster deployments than legacy models grounded in the world of specialized physical appliances. Our first webinar is dedicated to just this topic, showing how you can go from a raw environment to a fully functioning network slice in less than an hour.

• It’s flexible. When monolithic network applications are decomposed into microservices, each running in its own container on off-the-shelf hardware, it becomes much easier to retool and customize your network on the fly. You can plug in the right NFs exactly where you need them—a huge benefit, given that CSPs still aren’t sure which 5G use cases will offer the best bang for their buck. Assuming your core uses true cloud-native principles (and that’s not always the case), you also gain a more open network. You can mix and match NFs from different vendors to build differentiated best-of-breed services without being locked into one vendor’s release schedule and pricing.

• It’s scalable. Cloud-native cores bring cloud scalability to CSP networks, allowing you to quickly, dynamically instantiate network resources and elastically scale them as needed, often in a fully automated way. 

• It accelerates innovation. One of the biggest advantages of running NFs as containerized microservices is that you can now update your network more easily and frequently. After all, it’s a lot easier for vendors to roll out new features—and a lot easier for network teams to implement them—when you only need to update one discrete component of an application instead of the whole thing.

Together, these advantages paint a compelling picture. But they’re all based on the assumption that your cloud-native core really is cloud-native. And unfortunately, that’s not always the case.

Cloud-native or merely cloud-washed?

NF vendors know they need to go cloud-native if they want to participate in 5G networks. The 5G specification itself assumes core functions will run inside containers, managed via container lifecycle management tools like Kubernetes. So naturally, every vendor now offers their NFs as containerized solutions. But as much as some would like to blur the line, containerized is not the same as cloud-native.

True cloud-native software is designed fundamentally differently than traditional monolithic applications. Each component is built as a discrete microservice, designed from the ground up to be modular and containerized. Ultimately, it’s this decomposition that enables all the big cloud-native benefits. And it’s a much bigger change than the basic virtualization NFs have undergone in the last decade, as vendors decoupled network software from specialized hardware. But you wouldn’t know it looking at some of the “cloud-native” NFs hitting the market.

In many cases, vendors have skipped the whole process of decomposing and redesigning their software. Instead, they’ve taken the same old monolithic network applications and just dropped them into a giant VM running inside a container. “Voila,” they say, “now we’re cloud-native!”

Well, not quite.

Yes, you can technically use these “cloud-washed” NFs in a containerized architecture, but you won’t get the benefits that cloud-native software is supposed to deliver. When it comes to deploying, scaling, and updating them, the process is just as slow and complicated as running a monolithic application—because that’s basically what they are. You don’t have true cloud-native flexibility to mix and match components to create innovative, differentiated services. You still likely need to use proprietary tools to monitor and manage those products. And, you’re still locked into that vendor’s release schedule and pricing—meaning your vendors, not your customers, dictate how and when you roll out new services.

A better approach

At HPE, we look at the evolution to cloud-native networks a little differently. We don’t have a portfolio of legacy NF products that we need to protect or any incentive to keep customers locked into the closed, proprietary software architectures of the past. We view 5G as the perfect opportunity for CSPs to embrace the more agile, innovative software models that hyperscale cloud companies have used for years. And we designed the HPE 5G Core Stack to enable exactly that.

This is not monolithic software that’s been squeezed into a container to meet the bare minimum requirements of a 5G core. It’s a completely new application stack, designed from the ground up according to cloud-native principles, built to deliver the full benefits of cloud-native software.

Among the most important of those benefits: speed, with the ability to dynamically commission and deploy your network orders of magnitude more quickly. In fact, a 5G cloud-native core is over 10 times more dynamic than previous-generation networks.

Steps in Deploying and Commissioning a New Core Network	Traditional Core	HPE 5G Core Stack (based on lab installation)
Hardware logistics and shipment	1 week	N/A
Hardware installation	2 days	N/A
Software infrastructure setup	20 minutes	20 minutes
Functional software installation	Half day	10 minutes
Configuration	2 days	20 minutes
Testing	3 days	30 minutes
Total Timeline	2.5 weeks	Less than 2 hours

Learn More

In our ongoing webinar series, we’re taking a deeper dive into what all of this means in practice for CSP network organizations. We’re exploring what it’s like to deploy and run the 5G Core Stack in concrete terms and exactly what the scalability, flexibility, and openness of a truly cloud-native core can mean for your business.

In our first webinar, GSMA broke down the current state of the market for cloud-native 5G core to help separate the hype from reality. Then we went inside the day-0/day-1 rollout of a cloud-native 5G core, covering the main steps, including:

• Preparing the toolkit of preloaded applications on the deployment control node to trigger automated deployment
• Provisioning the pretested, prepackaged repositories (NF images, instantiation workflow, Helm charts and slice descriptors) for the Kubernetes-native continuous deployment framework
• Automatically instantiating a slice to support the targeted 5G service, tracking every step of the process with unified, standardized monitoring
• Testing end-to-end services to validate that the slice is up and running and hitting the targets it was designed to meet

We showed how a cloud-native framework can help you go from zero to fully functioning network slice in under an hour.

Check out the video below for more details on the automated deployment, instantiation, and testing process. And, to learn more on how it looks like in practice, sign up for our next webinar now.