Home Archives for Seshadri Sathyanarayan

Author: Seshadri Sathyanarayan

The Traditional Telecom Vendor Is Dead. Long Live the Continuous Innovation Partner!

by Seshadri Sathyanarayan Seshadri Sathyanarayan No Comments

For years, the traditional telecom vendor has been the leviathan on the landscape, generating billions of dollars in revenue through hardware, software, and network-related services. But those vendors are going the way of the dinosaur—that is, toward extinction. Telecom operators (i.e. Communication Service Providers, or CSPs) are looking for a new kind of partner, one that can help them innovate and evolve to compete in a cloud-based world that they didn’t create and can’t easily control. It’s a frightening world for many CSPs, one teeming with exotically named inhabitants like Kubernetes, Jaeger, Docker, Elastic and Istio. And it’s the reason why the role of telecom vendors, more than ever, is to help CSPs tame this new world.

What has become increasingly apparent in my conversations with customers around 5G and the future is that CSPs aren’t looking for network vendors. They’re looking for Continuous Innovation Partners (CIPs). In other words, they’re seeking partners who can help them effectively leverage cloud-native, microservices-based technology to drive innovation and service creation.  Telecom operators understand that the fast-fail, webscale development mode popularized by Amazon, Google and others is the future, but they also realize that they don’t have the skill sets and expertise to seamlessly shift to a service creation environment based on containers, microservices, NoSQL databases, and other advanced technologies. That’s where CIPs enter the picture.

The CIP effectively splits the DevOps process by focusing on the development side of the equation, allowing CSPs to focus on the more familiar operational side of managing networks and subscribers. In an environment where services are constantly being created and updated, this looks like a Continuous Innovation/Continuous Development (CI/CD) process. In the CI/CD framework, the CIP is responsible for:

  • Synching code between developers (a/k/a “checking in” code) and building it out
  • Testing the individual service/microservice components
  • Performing quality control
  • Deploying new code to a test environment
  • Fetching the latest builds
  • Service integration and regression testing
  • Packaging and archiving

This process typically takes place in an isolated part of the network, away from production, so as not to impact existing network services. In this way, telecom partners can quickly decide whether to shelf the service or move it into their production network and scale it. By accelerating the service creation process, the CIP allows the telecom operator to adopt a fail-fast mode of deployment and more quickly monetize services that look profitable.

Of course, not every telecom equipment vendor is ready to take on the role of a CIP. At Affirmed, we had a significant head start with our cloud-native UnityCloud platform. To create UnityCloud, we analyzed hundreds of different cloud developer tools to find the best few dozen, then packaged and integrated them with our cloud-native, microservices-based architecture. Doing this required a deep understanding of cloud developer tools and concepts, something that lies outside the core competency of most CSPs and even most telecom vendors.

It’s not unusual for CSPs to register apprehension the first time they see UnityCloud up close, because many of the components are unfamiliar to them. But this apprehension soon becomes comprehension as CSPs realize that we’ve already done the heavy lifting for them by selecting and packaging these cloud-native tools together. By working with a continuous innovation partner like Affirmed, CSPs can leverage the cloud for a competitive advantage without retraining themselves or investing millions to update their software development skills.

The road to 5G is a journey, but it’s a journey that telecom vendors must be able to take with their customers. With a continuous innovation partner (CIP), telecom operators (CSPs) can reach their goals sooner and continue on a path of innovation and monetization for years to come.

Cloud Native: The Disaggregation of Software

by Seshadri Sathyanarayan Seshadri Sathyanarayan No Comments

“If virtualization is the disaggregation of hardware, then cloud-native is the disaggregation of software.”

As we stand on the cusp of 5G’s arrival next year (according to most analysts), it’s surprising to me how many people in the industry still don’t agree on what 5G will look like when it does arrive. You’ll hear the usual terms in a conversation about 5G —virtualization, cloud-native, the Internet of Things—but little consensus on what constitutes a true 5G network. Is virtualization enough or does a 5G network have to be cloud-native too? Is a cloud-native architecture simply one that features containerized software or is it something more?

 

What is Cloud-Native Architecture? Here’s a Simple Definition:

Part of the confusion around cloud-native architecture stems from our industry’s affection for making the simple complex. For example, the industry definition for cloud-native invokes a whole laundry list of requirements—containerization, microservices, network slicing, etc.—that many in the industry don’t fully understand. It was during one such conversation, at a recent panel session on 5G networks, where I finally discovered a simple way of defining cloud-native architectures. “If virtualization is the disaggregation of hardware,” I said, “then cloud-native is the disaggregation of software.”

 

Disaggregation & Cloud Native

For me, that’s the whole crux of the 5G discussion right there. Virtualization is a mandate for 5G, true, but there’s a higher purpose for 5G than squeezing more cost out of the network: a mandate to make money. This requires an innovation platform built on cloud-native architecture principles that can enable new network slices and fail fast modes of operation. And disaggregating software is the key to creating and managing such a platform and driving new revenue opportunities of the 5G future. Achieving the right level of disaggregation is the true art within the science of Cloud Native.

To be clear, cloud-native is more than disaggregated software. It involves, among other things, containerization, dynamic management, an externalized state, a service mesh and, perhaps most importantly, a microservices-based architecture. Unfortunately, many network equipment vendors are clouding the perception of cloud-native by limiting its scope to a few checked-off boxes. They build on a foundation of hardware virtualization by re-packaging their existing software in containers, provide some dynamic management tools and announce that their solution is cloud-native architecture. Not surprisingly, their 5G conversations also stop short of promising more revenue. Instead, their focus is on operational and capex savings. Let’s be very clear: If your 5G roadmap ends at network savings, you’ll be running out of road a lot sooner than you think.

Ultimately, 5G is defined by how you define success. If success is saving money and watching other people innovate, then stick to virtualization. But if you define success by shaping the future and embracing the opportunity, cloud-native is a must. There are a lot of roadmaps out there, but in the race to revenue, the path for 5G is clear: the winners will be those who figure out how to drive revenue through new services, faster than the competition.

Standalone (SA) and Non-Standalone (NSA) 5G Architectures: The various paths to 5G revenues and profitability

by Seshadri Sathyanarayan Seshadri Sathyanarayan No Comments

A Telecom Transformation is underway. With 5G, a whole new generation of networks is being built to connect 50+ Billion Devices, creating more than a $12 trillion-dollar market opportunity for Mobile Network Operators. The road to 5G, it turns out though, isn’t a straight line.

The path that mobile network operators (MNOs) follow to 5G will depend a lot on how they plan to pay for that journey. For MNOs that are looking to deliver mainly high-speed connectivity to consumers with 5G-enabled devices, a non-standalone architecture (NSA) makes the most sense, because it allows them to leverage their existing network investments in transport and mobile core —rather than deploy a completely new end to end 5G network. This can be combined with efforts to reduce network operating costs by adopting virtualization and CUPS (Control and User plane separation) using software defined networking (SDN). These initial steps toward 5G, enable MNOs to begin offering 5G services providing faster data speeds and capture additional revenue streams.

For some MNOs, however, who have their sights set on new enterprise 5G services such as smart cities, smart factories or other vertical market solutions, a standalone architecture (SA) could make more sense. In this scenario, which 3GPP is still in the process of standardizing soon, MNOs could build an entirely new fully virtualized 5G network that includes new radio access network, new transport network and new 5G mobile core and edge networks – standing alone and separate from their existing 4G and legacy networks. 5G standalone arch is a fully virtualized, cloud native architecture (CNA) which introduces new ways to develop, deploy and manage services. CNA includes concepts of microservices and service-based interfaces which greatly simplify services, dramatically reducing the cost of operation and speeding up the introduction of new revenue-generating services. With 5G SA, the distinct advantage here is end-to-end support for 5G speeds and services. And the true promise of 5G is enterprise driven revenue – it changes business model from consumer-driven to enterprise-focused opening up entirely new use cases and revenue streams.

The Future of 5G Includes NSA and SA

It’s worth noting that NSA and SA aren’t an either/or proposition, but more of a “sooner or later” consideration. MNOs that begin with NSA can gradually add or migrate to SA over time. What we’ve seen at Affirmed from early 5G adopters are primarily NSA deployments as MNOs compete for the bragging rights (and the competitive advantage) of being the first to offer 5G speeds. These MNOs were typically the first to adopt 4G/LTE technologies as well, and so are fairly advanced in terms of network virtualization. Many of them are still using Affirmed’s solution as their virtual Evolved Packet Core (vEPC) solution. One of the advantages of an Affirmed’s NSA-based solution is its ability to handle both 4G and 5G-based traffic as MNOs transform their networks.

At some point, of course, NSA and SA will converge as MNOs move to a full 5G architecture. Recognizing that, MNOs would do well to look for a mobile core platform that can transition easily from NSA to SA. Having a completely virtualized 5G architecture will offer MNOs the flexibility to migrate select functionality of their existing NSA solution to the 5GC platform over time, as new 5G services are enabled, allowing them to monetize their investment gradually rather than go all-in and hope to recoup their costs later          .

With a clear path to evolving their networks from NSA to SA, Mobile Network Operators can win the race to revenues by operating their networks at webscale.

 

 

 

Source for market reference

https://www.qualcomm.com/media/documents/files/fierce-wireless-ebrief-5g-release-16.pdf