What Is Cloud-Native?
Cloud-native is an approach to building and running applications that fully exploits the benefits of the cloud computing model. For communications service providers (CoSPs), applications are network functions. Examples of these functions include the Session Management Function (SMF) and the User Plane Function (UPF). The following is a high-level description of some important cloud-native principles:
- Microservices are services that work together as a distributed system. Microservices are small, focused, and autonomous.
- Containers are a method of virtualization that bundles an application with all its dependencies—required executables, binaries, libraries and configuration files, for example—into a singular package.
- Continuous integration/continuous delivery (CI/CD) is a DevOps technique that supports frequent code changes or service updates (sometimes daily) while verifying that those changes do not negatively affect service functionality. CI/CD is a new concept for CoSPs and is a contrast to upgrades that occur only once every year or two.
- Dynamic cloud-based management takes advantage of automation, containers as a service (CaaS), and other orchestration tools to keep the network up and running 24/7.
By combining these principles, CoSPs can build the 5G network with cloud-native network functions (CNFs).
Overview of Cloud-Native Benefits
For CoSPs, going cloud-native delivers several benefits:
- Reduced capital and operational expenditure for better cost efficiency
- Faster time-to-market for new services
- Scalability to grow services according to demand
- Flexibility to update services and develop new ones quickly
- Resiliency so that if one instance of a service fails, another one can quickly take its place
Design Principles and Best Practices Can Smooth the Migration to a Cloud-Native Network
To maintain the always-on aspect of the telecommunications network, CoSPs can use several design principles and best practices, as they transition network functions into containerized, cloud-native microservices:
- Canary testing is a way to bring new functionality into a service while verifying the new feature works as intended. A small group of users tests the new feature by running two versions of the service simultaneously. This is made possible through the microservices architecture.
- Resilience and service availability is also made possible by a microservices architecture, where CNFs are not tied to specific hardware and are designed to survive multiple failures.
- Automated service recovery is enabled by the use of a CaaS manager, such as Kubernetes. Through CaaS monitoring, automated procedures and policies recognize and heal CNF instance failures.
- Appropriate design for compromises between consistency and availability is enabled by the use of synchronous or asynchronous communication. These tradeoffs occur over a spectrum, combining consistency and availability in a way that makes sense for a particular application or microservice.
- Circuit breakers help manage network quality by tracking a microservice’s ability to respond quickly to requests and applying automated policies, such as spinning up a replacement instance or re-routing requests.
- Separation of business logic from transport using a service mesh that controls how microservices share data with one another. The service mesh uses sidecars, which are proxies in separate containers (apart from the main microservice container). The combination of service mesh and sidecars provides CoSPs the necessary control to apply uniform microservice communication policies.
CoSPs don’t have to make the journey to a cloud-native 5G network all alone. They can take advantage of the Intel® Network Builders program, which is an extensive community of telecom and IT players that work together to simplify and accelerate cloud-native networks. In addition, Intel is enabling standard, reusable, shared platforms that are easy to upgrade, maintain and scale.
Interested in learning more? Read the white paper, “Why Use Containers and Cloud-Native Functions Anyway?”.