As the market embraces edge computing and 5G networks, telecommunications service providers are increasingly looking for ways to migrate their monolithic services to microservices and containers. These providers are moving from legacy hardware appliances to virtualized network functions to containerized network functions on cloud infrastructure. Red Hat’s partnership with a rich ecosystem of software-defined networking (SDN) vendors, independent software vendors (ISVs), network equipment providers (NEPs), as well as its deep involvement in the open source projects powering these initiatives, give customers the choices and long-life support they need to build the services infrastructure that supports their business needs both today and tomorrow – as well as the journey in between.
The key word here is “journey”, not “toggle” or “flip-of-a-switch.” Rather than a sudden change where all workloads suddenly switch from virtualized to containerized, environments will go through a period where both types of applications, virtualized and containerized, must coexist. For example, mobile phone service providers are unlikely to rip-and-replace applications and services that are spread around the world due to scale, geography and other various business and technical reasons. As infrastructure reaches the end of its life, or as new applications are developed, containerized applications could be introduced to handle new services or growth in subscriber or bandwidth capacity, rather than re-writing to containerize an entire deployment all at once. A similar transition in automobiles can be observed as hybrid cars bridge the gap during the conversion from today’s gas-powered to tomorrow’s all electric – virtualization of network functions (VNF) is part of the journey from legacy hardware solutions to containerized network functions (CNF).
Why is this journey taking place? It all comes down to flexibility. The sheer number of networks becoming software-based and the number of connections within those networks mean that network infrastructure needs to be able to scale with demand. Using the mobile service provider example:
- Physical network functions – Initially, specialized hardware was required to provide phone connectivity as well as new network functions such as voicemail, call forwarding, conferencing, etc. Physical hardware had to be sized based on peak usage, resulting in huge capital and operating expenditures on resources which was sitting, largely unused, therefore not generating any revenue .
- NFV – Virtualized network functions allowed for increased flexibility and more dynamic resource allocation. Unlike dedicated hardware solutions, virtualized applications are abstracted from the hardware, thus the underlying infrastructure could be utilized more efficiently, reducing the expenditures for resources that are not being used.
- CNF – In addition to scaling to serve a growing user base, providers are now rolling out new applications to stay ahead of their competition. Instead of offering a single service (like voice calling), providers are creating new applications enabling innovations like live transcription, instant meeting coordination, and even real-time translation to break down communication barriers. Containerization brings with it a cornucopia of benefits affecting everything from app development to security. From the beginning, development time is reduced because each container image is just the application – no additional VM complexity. This means that containers can be created, updated or destroyed much faster than traditional infrastructure – further accelerating time-to-market and reducing the management burden with easier updates and rollbacks. Containers add a layer of abstraction, not present in VMs. While VMs rely on the infrastructure layer to provide benefits such as resilience, containers are cloud-native and are built to be independent of their infrastructure. This abstraction also enhances security, not just because patches can be rolled out faster, but because just the container host can be patched – as opposed to multiple, individual guest operating systems that each need attention. By making application development faster, scaling easier and management less complex, containers allow providers to launch newer applications (services) faster and gain a competitive advantage.
At Red Hat, we believe that the future is all about choice and that our customers know the best ways to serve their own customers. As modern telecommunications networks explore new architectures to meet tomorrow’s customer demands, Red Hat is ready to help along the way.
From current NFV to nascent and growing CNF deployments, providers are at different stages of evolving their networks. As providers continue their journeys towards network transformation, they can count on infrastructures running Red Hat OpenStack Platform to power production-ready, NFV applications. Red Hat OpenStack brings the stability of long-life releases backed by a 5 year support lifecycle that lets providers focus on business, not managing infrastructure. Red Hat OpenStack’s integration with a large ecosystem of partners and ISVs allows customers to choose how to build the most effective solution – beyond what a single vendor can offer. Customers around the world choose Red Hat OpenStack to serve as a platform for today’s workloads, but also as a future-ready foundation.
While already under way, the transition from virtualized to containerized network functions is going through a period where networks will need to run both types side-by-side. The strategy, “cap and grow”, allows for VMs to exist for their full, expected life cycle, while new applications will be written as containers – decreasing the ratio of VMs to containers over a period of years. Providers aren’t converting functional VMs into containers en-masse; rather they are writing or sourcing new applications (e.g., 5G functions) as containers, while they maintain VMs with older technology that will eventually decline in number.
Finally comes the question of “where can I run my apps?” – “Wherever you want”! The conversation about containers would not be complete without mentioning one of their best assets: portability. Because containers are so abstracted from the infrastructure, OpenShift can run them on your cloud of choice; and move them as needed. For example, if a container is deployed in a public cloud but needs to move on premises for data locality reasons: it can.
Red Hat OpenShift Container Platform deployed in a public cloud is great but when Red Hat OpenShift is deployed on top of Red Hat OpenStack Platform, the result is an environment supporting both virtualized and containerized network functions. This allows both current and future applications to share the same infrastructure and our customers can move at their own pace by leveraging this deployment model of coexistence to migrate their VM workload or containers.
At the vanguard of network transformation, providers are fully containerizing their mobile network core and are writing their own cloud-native applications. For added stability and faster development, Red Hat can certify that a Universal Base Image (UBI) reduces risk by serving as a supportable foundation for container-based workloads: standardized innovation. Working within the partner ecosystem, Red Hat is expanding support and certification for CNF with ISVs, along with early access customer trials. Upstream, Red Hat is also working with the Kubernetes and other project communities to bring telecommunications requirements into the key projects for supporting CNF use cases.
What does this mean for our customers? Whether rolling out CNF, supporting a mixed environment of CNF and NFV, or running dedicated NFV environments, Red Hat has the platform, the experience and services to power their network function strategy wherever they are in their journey. Truly delivering open source solutions, Red Hat can be the trusted, impartial adviser to guide service providers through this transformation and beyond without the shackles of single (or forked) vendor proprietary offers – and therefore enable customers to build exactly what they want to deliver when and where they need it.