The cloud native

transformation
A guide to cloud native design
and operations principles

October 2020
2 Ericsson  |  The cloud native transformation

Cloud native –
a holistic view

Being cloud native is synonymous with industry-wide

transformation in the ICT field, with extremely fast innovation
and value coming both from start-ups and established players.

In the telecommunications sector, many These four aspects do not exist – nor Technology plays a crucial role in
operators and vendors are also embracing should be looked at – in isolation. They all all four aspects of cloud native. For
cloud native. In this paper we wish to share influence each other, and so none of them communications service providers (CSPs),
the holistic methodology we at Ericsson should be overlooked at any point in time, many of the aspects are connected to the
use to understand the main implications irrespective of whether we are discussing a desire to build networks with equipment
of cloud native, with the strong belief development of a brand-new cloud native from multiple vendors (for example,
that in order to get the desired benefits – network function (CNF), transforming an applications provided by one vendor and
especially in the telecom context – one existing legacy application onto the cloud, infrastructure provided by another), so
needs to view this transformation from or transforming a whole network. it is therefore crucial that multi-vendor
different angles. Omitting any of the aspects carries interoperability is ensured. Alignment
The four main aspects of cloud native the risk of not gaining the full intended between players across the necessary
described in this document are: benefits – for example, if applications, interfaces can be tricky, but open source
• application design and development infrastructure and orchestration all follow initiatives, such as the Cloud Native
• technology and infrastructure cloud native design patterns, yet the ways Computing Foundation (CNCF) and
• processes and ways of working of working and organizational setup and The Linux Foundation, often provide a
• management and orchestration model do not take advantage of the cloud good basis to work with in the form of
native setup, the full potential will not de-facto standards (like Prometheus
be reached. for monitoring or Helm for package
management). However, alignment
around processes and ways of working
is still lacking as of today and is an area
where industry consensus via open source
and standardization is very much needed.

Figure 1: The four main aspects of cloud native

Application design and development Processes and ways of working

Cloud native

Technology and infrastructure Management and orchestration

3 Ericsson  |  The cloud native transformation

Application design
and development

We have identified five design principles to follow

when designing cloud native telecoms applications.

Agnosticity Figure 2: Cloud native application agnosticity

In the telecommunication industry, a
cloud native application (CNA) needs to be
Cloud native Cloud native
agnostic to the underlying infrastructure. application application
This does not necessarily apply to the
traditional cloud native players, such as
App business logic App business logic Cloud native Cloud native
Netflix and Uber, since they control the full application application
stack that they deploy their application on.
As we evolve the cloud infrastructure
towards supporting container as a service App business logic App business logic

(CaaS), the requirement for agnosticism Kubernetes based CaaS: Any

remains but the challenges are different.
A CNA requires a container infrastructure
and must be deployable on whatever IaaS*: Any Kubernetes based CaaS: Any
CaaS and infrastructure as a service
(IaaS) combination that a CSP has in its
cloud environment; see Figure 2 for CNA Hardware: Any x86 Hardware: Any x86*
agnosticism scenarios.
A CNA must be able to run on any
modern kernel without requiring any
proprietary additions. CNAs should only Life cycle management more manageable pieces, whether
require “vanilla Kubernetes” with no A fundamental principle of a CNA is to this is referred to as “microservices”,
additional plug-ins for basic operation. decompose software into smaller, more “subroutines”, “code modules” or
Optional use of plug-ins for optimizing manageable pieces. This is usually done “software components”. What is
performance is allowed. through utilizing microservice architecture. new, however, is that each piece has
At the same time, the telecoms industry This is a design pattern that strives to a well-bounded scope and can now
is highly regulated. Mission-critical telecom structure an application as a collection be individually deployed, scaled and
services, composed of infrastructure and of loosely coupled stateless services and upgraded using a CaaS environment. In
applications supplied by IT and telecom stateful backing services. addition, microservices communicate
vendors, must live up to very demanding This concept is not new. It has always through well-defined and version-
internet CSP (ISP) requirements. been good practice to divide code into controlled network-based interfaces.

Application design principles: Figure 3: Example of a microservice architecture

• Agnosticity
• Decomposed software Stateless Cloud native application
• Application resiliency services Yang VES XML
• State-optimized design REST µService DB
CM CM µService PM µService Logic 3 DB
• Orchestration and automation Stateful backing API AppLogic 3 API
µService DB PM DB FM
services

µService
REST REST µService DB
Application AppLogic 1 Logic 4 DB
API API AppLogic 4 API
(SE)

Cloud native
TR µService REST µService
application
IF AppLogic 2 API AppLogic 2
consumer
4 Ericsson  |  The cloud native transformation

Figure 4: Upgrade/update example

µService A µService B Before

Version x.0 Version y.z

Fallback

µService A µService B During

Version x.1 Version y.z

µService A µService B After

Version x.1 Version y.z

Scaling State-optimized design Network-level orchestration

A microservice architecture allows The best way to manage state or data and automation
independent scaling, based on each must be decided based on the type, and Internal CNA automation is not
microservice’s particular need. It will the application context within which it is enough. It is equally important that it
scale linearly as long as the infrastructure handled. The lifetime of states can vary can be orchestrated from an external
provides needed resources like CPU, significantly, from milliseconds to days or management system in order to be
memory, storage and networking. even months. included in a wider network context, such
This scaling is automated to enable In general, the following aspects are as a 3GPP network slice. For this purpose,
self-dimensioning applications. used for determining the importance of a CNA must expose performance and
maintaining state information in the case fault management information to an
Upgrade of a microservice failure: external management system, as well
By eliminating the application-level • impact severity of the state/data loss as allow for model-driven configuration
clustering and relying on CaaS-level • impact on user management. This enables automation
mechanisms and backwards-compatible • cost/benefit considerations pending and orchestration of network-level use
APIs between services, in-service upgrades frequency of changing states cases like instantiation/decommissioning
can be simplified. Application upgrade and network scaling of a CNA (where
becomes the automated and orchestrated Orchestration and automation “network scaling” means adding more
upgrade of its microservices; see Figure 4. Internal automation and orchestration: instances of the CNA).
By ensuring that two microservice CNAs are automated, thereby automating
instances of the same type never the lifecycle of the internal microservices
communicate, it’s possible to run images that make up the application through
with different software revisions in the service discovery, load distribution and
same application instance. This makes other CaaS mechanisms. Some examples
canary testing efficient and low risk. of automated actions are scaling, healing
and in-service update/upgrades.
Application resiliency
Previously, local 1+1 resiliency models
together with geo-redundancy have been
deemed sufficient for physical network
functions (PNFs). This is due to the long Figure 5: A CNA with multiple failures
meantime between failure (MTBF) of
Cloud native application
hardware. In cloud environments, this is not
enough, as one must consider the (much
shorter) aggregated MTBF of hardware,
virtual machines (VMs) and containers. µService A µService A µService A

Therefore, a CNA should support

any combination of failures at any time,
without escalation to full restart and loss
of service.
µService B µService B µService B
Multiple failures will lead to
degradation of capacity, but not of service
availability. Service will continue as long as
one instance of each required microservice
type is available. The degradation of µService C µService C µService C
capacity is addressed by automated
scaling, enabling a system to recover
quickly and automatically.
5 Ericsson  |  The cloud native transformation

Processes and ways

of working

As the cloud native open source landscape grows

and matures, it becomes increasingly important to
make use of the best open source components.
Figure 6: Using open source platform software
The CNCF provides a new starting point
when looking for reuse opportunities
from a cloud native and microservice Ericsson CNFs 3PP CNFs CNCF
architecture perspective, adding value
Prometheus
by creating structure, choosing relevant
Spinakker
open source projects, and ensuring overall Ericsson Platform Services (PaaS)
Helm
quality and community acceptance. It Operator Framework
also provides a comprehensive map of Elastic
Istio
potential realizations for different areas. Logstash
Strict backward compatibility of the Configuration management Tracing OpenTracing
exposed interfaces is required to achieve Envoy
Redis
loose coupling and make it possible for Multus
each service to evolve independently. Performance management Database Kafka
At the same time, semantic versioning Project Calico
Jaeger
on the interfaces creates a common Docker
way to communicate the evolution of Jenkins
Fault management Service mesh
the interfaces.
The model for using open source
software is to bring in the source code –
Logging Life cycle management
even if pre-baked container images are
provided by some projects – and build
container images, including the selection
of the base operating system image, to
ensure security and to maintain version CCD EKS AKS GKE
control. Regardless of whether a service is
based on open source code or a proprietary
implementation, the development team Any IaaS including bare metal
structure and the responsibility must be
the same. Constant validation is crucial
for early detection of any potential issues
relating to backward compatibility.
In order to avoid creating proprietary
branches of open source components, and
thereby losing the open source advantage,
it is critical to apply an upstream-first
strategy; new functionality needs to be
contributed to the open source project
before being released to customers.

Open source components are key for cloud native success

6 Ericsson  |  The cloud native transformation

Figure 7: Telco phasing of software pipeline (CI/CD/CD)

Continuous design and integration Continuous delivery Continuous deployment

µService Application System System System

Delivery Deployment
staging staging staging staging staging

Live network
Monitoring and Monitoring and Monitoring and
analytics analytics analytics

Software vendor Software operator

Continuous ways of working rather, the vendor delivers software speed without raising cost; see Figure 8.
The fundamental continuous integration to multiple CSPs that operate the However, this comes with an integration
and continuous delivery (CI/CD) software application. This means that the software cost, since software pipeline tools are
pipeline methodology comes from the pipeline needs to support three phases not yet standardized across the
ICT industry, and is simple to understand – continuous integration, continuous telecom industry.
for mainstream web players where delivery and continuous deployment Automated pipelines have the potential
the same company is responsible for (CI/CD/CD) – rather than two to solve many challenges of the software
both the development and operations (that is, CI/CD). life cycle. Through staging multi-vendor
of an application. This implies that the Since the telecom landscape is made systems in multiple phases, the increase
development environment can be identical up of multi-vendor systems, this needs in network and system complexity can
to the runtime environment. to be catered for in the software pipeline be mitigated and the cost of
In the telecom environment, it’s not setup and phasing. This can be automated integration managed.
usual for the software vendor to both by merging pipelines and reusing test
develop and operate the application; suites, thereby increasing flexibility and

Figure 8: Merging pipelines

Vendor 1 Vendor integrator role Operator integrator role

µService Application System System System

Delivery Deployment
staging staging staging staging staging

Vendor 2
Live network

µService Application System

staging staging staging

Vendor 3

µService Application System

staging staging staging
7 Ericsson  |  The cloud native transformation

Technology and
infrastructure

Telco infrastructure has evolved fundamentally in the last 10 years,

starting with the introduction of network functions virtualization
(NFV) in 2012, which has shaped today’s preferred practices.

Infrastructure evolution Public cloud orchestration. While shortcomings

NFV introduced a clear separation of Demand is increasing to deploy CNAs on are addressed, it is expected that less
hardware and VM-based software public clouds managed by hyperscale demanding applications and use cases will
components. It also brought unified cloud providers like Google, Amazon and be realized on public cloud.
management of infrastructure and Microsoft. All major public cloud providers We are striving for openness and
application workloads with MANO. Over offer managed Kubernetes-based CaaS portability, working with all major public
the years, MANO has been thoroughly solutions, spanning from data center cloud providers to make this a viable
standardized and evolved with more deployments to edge and on-premises deployment option for CNAs. These
advanced automation capabilities. The cloud solutions. This deployment journey has providers offer various proprietary
native evolution brought CaaS environments only just started, though most Ericsson platforms as a service (PaaS), for example
on top of VM-based infrastructure, with cloud native telco applications can already logging and metric collection services.
Kubernetes as the choice for orchestration be deployed on public cloud. However, In the absence of standards, or de-facto
of container-based workloads. Here we see some aspects of specific applications standards, in the PaaS layer, Ericsson
strong momentum towards Kubernetes- and cannot yet be fulfilled; challenging areas considers CaaS to be the most relevant
Helm-based APIs becoming the preferred include telco networking, performance multi-vendor integration point for telco
way to define and manage container characteristics and management and CNAs (see Figure 10).
resources and applications.
To further optimize the resource
Figure 10: Preferred portability layer
utilization and reduce operational
complexity, the next natural step is to
deploy the CaaS environment directly on Ericsson CNFs
the hardware, via bare metal deployments.
However, VM-based applications will
remain for the foreseeable future. To avoid Ericsson Platform Services (PaaS)
fragmentation and multiple operational
Configuration management Logging Tracing
models, we foresee an extended
CaaS layer, which would be capable Performance management Database
of managing both VM and container Fault management Service mesh
workloads via a unified API (see Figure 9). Ericsson Platform Services (PaaS)
For telco applications, the CaaS layer
Portability
provides the most cost-efficient multi- layer
vendor integration point with strong EKS AKS GKE
de-facto realizations like Kubernetes and
Helm. It constantly evolves, enriching it
with more capabilities to support telco
applications and use cases with expected VMs (any IaaS) Bare metal
functionality, performance and security.

Figure 9: Infrastructure evolution

NVFI with IaaS CaaS using IaaS resources Iaas and CaaS with evolved MANO Evolved CaaS
VNFs VNFs and cloud native apps VNFs and cloud native apps VNFs and cloud native apps
MANO MANO MANO MANO
Open stack Open stack Helm API Open stack Kubernetes Kubernetes
API Minimizing API CaaS Evolved API CaaS / Helm API Harmonizing / Helm API

IaaS operations IaaS MANO and IaaS CaaS "VIMs" and CaaS
impact BM CaaS evolved SDI
Hardware Hardware Hardware Hardware
8 Ericsson  |  The cloud native transformation

Management and
orchestration

Management and orchestration is a wide discussion topic in itself.

Here, we discuss the main benefit of using Kubernetes; the possibility
to delegate automation tasks to the container orchestrator.

There are two notable differences that built-in automation of Kubernetes. the automation in the Kubernetes space,
Kubernetes offers, when compared to The declarative nature of the it is essential that the higher-level
more traditional IaaS environments: intent-based Kubernetes API also management systems provide enough
• The ability of Kubernetes to carry out contributes to simplicity – what used to be abstraction from the realization, avoid
end-to-end life cycle management for a complex workflow becomes practically low-level resource control and rely on
pods (which are the main building a specification of the desired state for policies to influence the lower-level
blocks of CNAs) each microservice – but also presents its controllers. It can be assumed that
• The declarative approach by which own challenges where the Kubernetes higher-level orchestration systems
Kubernetes handles automation tasks operators and controllers constantly need following an intent-based management
to ensure that the current state of the approach can effectively leverage
Compared to traditional VM orchestrators, microservice matches the desired state, automation and innovation in the
Kubernetes deals with containers and and take action if needed. To leverage Kubernetes layer.
pods as the main building blocks of a CNA,
and complements those with additional
essential services such as discovery or load Summary the cloud native benefits in the
balancing. While a VM-based application Our holistic strategy for the cloud telecom context.
typically needs additional logic on top native transformation offers CSPs There is huge potential in industry
of what is available in the Virtualized the possibility of decreased time alignment for operational models,
Infrastructure Manager (that is, Open Stack) to market combined with opex processes, ways of working and
to be able to manage the life cycle of an reductions, along with a more modern automated software pipelines, and
application, some life cycle management operational model where software the suggested channels for these are
procedures can be delegated to flows continuously from development standardization and open source,
Kubernetes controllers. to production environments. The four where vendors and operators can freely
Provided that the application is key aspects highlighted in this paper collaborate and share specifications
developed according to the cloud native are application design principles, and software components.
design principles, and is decomposed into infrastructure evolution, processes and We are currently deploying
functionally independent microservices, ways of working and management and 5G Core software that is built to be
Kubernetes can instantiate, terminate, orchestration. fully cloud native, and are transforming
scale (based on KPIs) or even upgrade Our strong recommendation is to our existing digital services portfolio,
these microservices. Even where consider all four aspects as having considering all four aspects of the
Kubernetes might lack in capabilities equal importance, in order to maximize holistic cloud native strategy.
by default (as, for example, life
cycle managing stateful services such
as databases), Kubernetes operators,
which are built specifically for a particular
microservice, can be used to bring the
necessary logic right into the
container orchestrator.
The main benefit in the telecom context
is reduced complexity at the higher levels
of the orchestration chain. The life cycle
of microservices, which comprise a CNA,
can be delegated to Kubernetes, its
built-in controllers, or custom Kubernetes
operators. This delegation allows the
higher-level orchestration to focus on the
smart composition of microservices into a Application design principles, infrastructure, ways of working
CNA, leveraging the intent-based API and and management and orchestration are equally important
 Ericsson enables communications service providers
to capture the full value of connectivity. The company’s
portfolio spans Networks, Digital Services, Managed
Services, and Emerging Business and is designed to
help our customers go digital, increase efficiency and
find new revenue streams. Ericsson’s investments in
innovation have delivered the benefits of telephony
and mobile broadband to billions of people around
the world. The Ericsson stock is listed on Nasdaq
Stockholm and on Nasdaq New York.

www.ericsson.com

Ericsson The content of this document is subject to 4/287 01-FGM 101 51

SE-164 80 Stockholm, Sweden revision without notice due to continued © Ericsson 2020
Telephone +46 10 719 0000 progress in methodology, design and
www.ericsson.com manufacturing. Ericsson shall have no
liability for any error or damage of any kind
resulting from the use of this document