Home Archives for Sean O’Donoghue Page 2

Author: Sean O’Donoghue

Innovation at the Core: Standalone 5G Core Architecture

by Sean O’Donoghue Sean O’Donoghue No Comments

Whenever 5G is mentioned, the conversation seems to inevitably shift to 5GNR (New Radio) as the driver for the diverse use cases that will come. Meanwhile, all those 5G core innovations are pushed to the margins, with maybe a mention of network slicing. These same pundits like to tell people that 5G is still years away and to keep building out their 4G cores until it arrives. In reality, what should actually be talked about is standalone 5G core architecture. Sinking investments into a sub-optimal, closed 4G network isn’t biding your time wisely – it’s burying an opportunity.

Let me explain. Traditional mobile cores were designed to support a “one size fits all” model where voice and data services dominated the landscape. And that was understandable in a world where most networks had few service differentiations. When NFV arrived, communications service providers (CSPs) began to look more closely at cost-saving opportunities – but not at the service opportunities – presented by a virtualized Evolved Packet Core (vEPC). What they missed was the fact that next-generation services would require a radical transformation in the mobile core architecture beyond virtualization, specifically around areas that address high throughput, low latency, and high reliability. This radical transformation led to the idea of a standalone 5G core architecture.

Your cloud vendor matters… a lot

On the road to the future, CSPs need to question if their current network strategy is open to the changes and disruption that 5G will bring. For example, are they partnering with cloud-native companies or with legacy vendors whose cloud strategies are mostly air? If you’re working with a true cloud partner, you should already have a standalone 5G network in place or in process. Otherwise, you won’t be able to support the new DevOps models that will drive the revenue streams for 5G services.

Beyond that, a bigger question is whether your network is ready for 5G. Is your network infrastructure optimized and adaptable to change? 5G network should be flexible enough to deploy on public clouds, hybrid clouds, VMs or bare metal. If your 5G strategy isn’t prepared for all those scenarios, you’re seriously limiting your future. I cover this subject of cloud vendor preparedness in my blog, “It’s Time to Come Clean About Cloud-Washing.”

Five ways that a standalone 5G core can drive revenue

Network slicing is just one slice of the 5G pie. There are plenty of ways that a standalone 5G core architecture can drive revenue:

#1. Network Slicing

This is a frequently talked-about capability in 5G where a network is logically “sliced” into different segments with unique policies and capabilities to deliver customized services to an enterprise or group of customers. While network slicing is important in realizing new revenue streams – particularly for enterprise use cases – it can also serve a range of additional use cases such as the accelerated transition to virtualization, operational maintenance or new service rollouts.

#2. The Service Based Architecture (SBA)

The SBA enables network functions and external systems to communicate using web-based APIs. For a CSP making the transition from telco-native to cloud-native, this can be a seismic shift. Forget about the days when you needed to understand dozens of telecommunications protocols in order to make a simple connection. In SBA, services can register themselves and subscribe to other services, or new services can be introduced, using the same API patterns. For the first time, a network’s data and services can be exposed in a standard, secure and comprehensible way to innovative third-parties in order to create better services.

#3. Integrated Gi-LAN Services

I wrote about the value of an integrated virtual probe and analytics solution in an earlier blog (“The Intelligent Data-Centric Network”). With powerful, actionable customer insight, CSPs can rapidly create personalized targeted offers, promotions, and service bundles to attract new customers and grow revenue. Affirmed is unique in this space, as we’re the only company to provide a single platform for value-added services such as security, video optimization, TCP acceleration, and parental control that enables a unique and differentiated experience on a per-flow basis.

#4. Multi-Access Edge Computing (MEC)

Formerly known as mobile edge computing, multi-access edge computing (MEC) is yet another exciting area for growth that requires a high-performance, reliable, and scalable mobile 5g core. Affirmed’s Cloud Edge (ACE) is a MEC-based solution that allows CSPs to rapidly deploy and monetize use cases such as content delivery networks (CDNs), augmented/virtual reality, autonomous vehicles, drones, IoT, private LTE/5G for enterprise and location-specific services (e.g., in-store retail, advertising, etc.).

#5. Automation

This will be critical in the future, as CSPs will need to scale in the hyper-connected societies of tomorrow. The CSPs that execute automated service provisioning and service assurance well will reap the benefits of faster time-to-revenue and higher customer lifetime value.

Not all mobile core vendors can deliver on the promise of 5G in the form of ultra-reliable, low latency, high-throughput networks. In fact, most of them cannot deliver this because of fundamental limitations in their technology, operational challenges, and the double-sided desire to protect their legacy revenue streams. But all this raises an interesting question: If your vendor has an agenda that doesn’t align with your vision of the future, where are you headed?

 

Make no mistake: 5G is still up for grabs. Someone is going to make a lot of money on new 5G services. It could be the Googles and Amazons of the world – and it probably will be, to some extent – but CSPs have the potential to be the real winners in the battle for 5G services revenue. So what’s your competitive advantage: a network experience that feels like a slightly faster version of 4G or one that completely transforms the user experience by delivering better experiences and driving innovative new services to market quickly? When you need a standalone 5G network, only one truly stands alone: Affirmed Networks.

It’s Time to Come Clean About Cloud-Washing

by Sean O’Donoghue Sean O’Donoghue No Comments

They did it again. Another company has taken their old software, cleaned it up a little for deployment in the cloud, and called it cloud-native.

We call it cloud-washing. Like the “green-washing” of old, where companies would make claims of environmentally friendly products and practices when, in fact, little had changed from the past, cloud-washing is simply the rebranding and repackaging of monolithic, sub-optimal, on-premise software to appear innovative. Creative, maybe. Innovative, never.

True cloud-native software is built specifically to leverage the inherent benefits of a cloud architecture: hyper-scale, high resiliency, service velocity, and hybrid cloud flexibility, for example. Unfortunately, some companies have discovered their own shortcut to the cloud: port their old software onto virtual machines, repackage it as “virtualized” software and stuff it into a container. That isn’t cloud-native, it’s cloud deceptive.

At the core of the deception is a desire for innovation. Communications service providers (CSPs) are facing unprecedented challenges as they look to support an ever-expanding digital economy. Services revenues are flat or declining, while data and video traffic are exploding. As a result, the business model for CSPs is currently inverted, as revenue per bit converges with cost per bit, leaving little room for profit.

Hyper cloud providers such as Amazon, Google, and Microsoft, on the other hand, are turning in record profits by delivering innovation at a very low cost using cloud-native models, open-source services, machine learning, and self-service models. To survive and thrive in the new digital economy, service providers will need to follow suit, embracing the same models, processes, and technologies used by the leading hyper cloud providers. It’s a new world for CSPs, which is why it’s critical for them to have truly cloud-native solutions.

What does a real cloud-native solution look like? Basically, there are five main design principles that determine whether an application is truly cloud-native:

1. Multi-Cloud Support

By its very definition, cloud-native software is designed to be hosted in a multi-cloud environment. Software that cannot be deployed in a public, private, and hybrid cloud environment is not cloud-native, period. Simply connecting to a cloud isn’t the same as being built to run in any cloud.

2. Container Packaged

Software packaging and delivery have evolved from single, monolithic software packages to virtual machines and, more recently, containers. Container and orchestration platforms such as Docker and Kubernetes bring clear advantages to a cloud-native architecture by making applications more lightweight, open, portable, and easier to deploy, orchestrate, operate, upgrade, and manage. Some vendors use the right buzzwords (e.g., containers, pods, Docker, Kubernetes) but have the wrong ideas about cloud-native characteristics, and instead, they package their software as a big, complicated blob.

3. Dynamically Managed

Cloud-native software should be elastic. It should be scaled once for the initial load and then automatically scale up or down using cloud-native tools such as Kubernetes or Helm as demands increase or decrease. We call this dynamic management, and it’s a monumental mind shift for CSPs that are accustomed to dimensioning network solutions based on peak traffic scenarios with very limited agility.

4. Microservices Oriented

IT teams have already successfully implemented a microservices-based architecture for front-end channel applications as well as for back-end customer management and order management applications. CSPs can now invoke and re-use these microservices components in different combinations to simplify software upgrades or create new services. If software claims to be microservices oriented but shows little evidence of delivering autonomous, changeable, replaceable services, you’re probably looking at a cloud-washed product.

5. Externalized State

One of the limiting factors in scaling an application is statefulness, particularly its session state. Applications in which the application and session state have not been externalized to a high-availability store will have a hard time functioning in the cloud.

The Last Word about Cloud-Washing

The promise of 5G as a catalyst for nonstop reliability, new service innovation, and increased revenue is well documented. Re-architecting the network around the aforementioned architectural principles is the foundation for the promise of 5G. At Affirmed, we call that a platform for innovation.

The race to digital services is already underway, and competition will come from all sides. CSPs need a web-scale, cloud-native network architecture that can deliver next-gen digital services. These networks will have to deliver ultra-high performance and advanced features such as network slicing, service automation, and real-time analytics to radically accelerate service creation and drive down network costs.

More than ever, service providers will need to roll up their sleeves and fully evaluate each architectural element, principle, and capability of their 5G platform. This means challenging vendors on their cloud credentials, their roadmaps, and their commitment to open-source technology. In short, insist that your vendors come clean about whether or not they’re selling true cloud-native technology or simply cloud-washing their old products. A high-performance, cloud-native architecture using open-source technology can open your 5G future to more agility, flexibility, and opportunity. Don’t settle for anything less.