Is cloud native design really needed in telecom?
Senior solution marketing manager
Senior solution marketing manager
Senior solution marketing manager
It’s well known that high-profile web players like Google, Facebook, and Netflix have managed to successfully use cloud-native technologies to gain large-scale efficiency and agility benefits.
The reality in the telecom industry is that so far not much has happened. Very few have launched large production networks with NFV. However, we now see some light at the end of the tunnel and we're starting to get commercial networks in operation also for large scale production, even though there is a lot left to do.
Evolution of NFVi for 5G drives cloud-native design
With 5G as the vehicle, the new 3GPP standardized 5G core will hit the market starting in 2019, and we will see limited 5G launches by the end of 2019. Because the new 5G core will be cloud native from the start, operators must be able to also run and operate containerized applications. The needed evolution of NFV infrastructure to support cloud-native applications is gaining traction in all major industry forums.
How do you design cloud-native apps for the telecom industry? Is there a difference compared to how Google or Netflix builds them? Yes and no. Companies like Netflix and Google tend to build and operate their own network application software; that is, they do not have to deliver their network application software to other companies and let those companies operate it. This is not the case for telecom vendors and CSPs. Telecom vendors deliver network applications to not just one CSP but many different CSPs with different requirements, and the CSPs then operate those applications and provide services to their end users.
Design principles
Nevertheless, there are cloud-native design principles that are valid no matter what industry you are in, such as:
- Agnosticity. A cloud-native application must be agnostic to the underlying infrastructure and resources.
- Software decomposition and life cycle management. Decompose software into smaller more manageable pieces, utilizing microservice architectures. Each piece can be individually deployed, scaled, and upgraded using a CaaS (Container as a Service) environment.
- Resiliency. In legacy applications, the MTBF of hardware has been the base metric for resiliency. In the cloud, we instead rely on distribution and independence of software components that utilize auto-scaling and healing. This means that failures within an application should cause only temporary capacity loss and never escalate to a full restart and loss of service.
- State-optimized design. How we manage state depends on the type of state/data and the context of the state. Therefore, there is no “one size fits all” way of handling state and data, but there should be a balance between performance, resiliency, and flexibility.
- Orchestration and automation. A huge benefit of cloud-native applications is increased automation through, for example, a Kubernetes-based CaaS layer. A CaaS enables auto-scaling of microservices, auto-healing of failing containers, and software upgrades including canary testing (small-scale testing) before larger deployments.
Cloud-native applications and infrastructure should not be seen as another level of complexity on top of a cloud transformation that still is not fully up and running; rather, it should be seen as the natural evolution of the cloud transformation that is in progress in the telecom industry today. The evolution to cloud-native applications and infrastructure is required to fully capture the promise of the cloud and NFV.
Cloud-native design at Ericsson
Listen to the podcast on cloud-native design with Jonas Falkenå, senior expert on application implementation architecture at Business Area Digital Services.
Want to know more about cloud native design at Ericsson?