►
From YouTube: Lessons Learnt and Thoughts on Telco Cloud Native Evolution an... Seshu Kumar Mudiganti & Qihui Zhao
Description
Lessons Learnt and Thoughts on Telco Cloud Native Evolution and Open Source Practices - Seshu Kumar Mudiganti, Huawei Technologies India Pvt Ltd. & Qihui Zhao, China Mobile
With the maturity of 5G and the development of edge computing, operators have gradually transformed into network service providers. Providing agile, robust and flexible network cloud is operators' primary goal. Currently, together with vendors, operators are researching on cloud native methodologies and technologies, such as container, microservice and DevOps, and pushing network cloud evolving towards cloud native. The current session mainly highlights on the lessons we learnt from operating on various CNCF projects, OKD as part of the XGVela project, we will also present the current open source implementation of a PaaS platform, NF microservices, CNFs and other cloud native technical points. In this session, we will also introduce China Mobile's thoughts and practice on network cloud native evolution, clarify the evolution requirements.
A
A
A
Firstly,
let's
look
at
china
mobile's
cloud
native
situations.
China
mobile
has
three
types
of
cloud:
e-cloud,
I.t
cloud
and
network
cloud.
Ecloud
is
our
public
cloud.
It
can
provide
general
and
standard
cloud
services
to
individual
users,
as
well
as
some
customized
cloud
solutions
to
the
enterprise
users,
and
also
this
cloud
carries
some
of
cmcc's
service
platforms
like
the
ai
platform
and
the
big
data
platform.
A
A
The
third
cloud
is
cloud
network
cloud.
This
is
the
most
important
cloud
for
us
as
an
operator
it
carries
4g,
5g
network
functions,
value-added
network
functions
such
as
multimedia
messaging
services
and
some
network
function.
Related
management
systems
is
also
on
this
cloud,
for
example
the
manual
ems.
A
This
cloud
is
also
a
private
cloud
that
has
strong
telecom
features
so
by
looking
at
all
the
three
clouds
as
e-cloud
and
itcloud
has
less
telco
features.
They
go
faster
on
cloud-native
evolution,
our
e-cloud
is,
is
always
providing
the
past
services
for
applications.
Containers
micro,
service
architectures
are
provided
as
the
service
of
e-cloud.
A
A
Okay,
here,
let's
have
an
overview
of
cmcc's
network
cloud.
Since
2018
cmcc
has
been
establishing
centralized
network
cloud
in
eight
different
districts
in
china,
our
5g
core
ims,
epc,
are
running
on
this
cloud.
The
cloud
ratio
of
cmcc's
network
cloud
is
currently
up
to
35
percent
and
also
we
we're
planning
to
build
some
edge
clouds
in
each
of
our
31
provinces.
A
A
Package
that
are
deployed
in
the
cloud
this
makes
it
when
we
want
to
use
it
for
different
use
cases.
We
would
only
use
one
deployment
with
some
different
configurations
for
for
those
different
use
cases,
but,
as
we
all
know
that
the
to
b
customer
has
very
diverse
requirements,
it
may
cause.
If
we
continue
to
use
this
kind
of
deployment
strategy,
it
may
cause
inflexibility
and
some
resource
waste
in
in
in
the
future.
A
A
The
redundancy
may
exist
at
a
network,
function,
level,
server
level,
resource
pool
level
and
etc,
but
if
we
allow
some
light
service
downgrading
using
the
containers
to
achieve
staples
and
multiple
replicas
of
of
network
function
services,
we
may
reduce
resources
that
are
redundantly
redundantly
used
and
also,
as
navs
are
now
usually
designed
with
a
large
size
of
virtual
machines.
This
may
cause
service
resources
are
not
service.
A
Resources
are
not
fully
used,
for
example,
if
a
server
usually
has
two
two
physical
cpus
and
we
deployed
two
virtual
machines,
one
is
with
20
vcpus
and
the
other
one
has
the
12
vcpus.
This
would
cause
a
waste
of
resources
if
the
other
the
another
virtual
machine
needs
10
virtual
cpus,
but
if
we
can
design
the
network
functions
as
micro
services
with
each
micro
services
cost
smaller
piece
of
resources,
then
the
utilization
rate
might
increase
and
the
third
problem.
We
think
that
the
cloud
native
may
solve
is
automate
the
process
of
network
function.
A
Firstly,
we
would
generate
some
requirements,
then
the
vendors
would
do
the
development
and
then
we
would
receive
a
new
version
deployment
package
delivered
by
the
vendors,
and
we
would
do
some
manual
testing
of
these
upgraded
network
functions
and
then
we
would
select
several
commercial
sites
to
do
a
trial
deployment.
If
the
feedback
from
the
trial
deployment
are
good,
we
would
do
some
offline
upgrade.
A
A
So
these
are
some
examples
to
explain
why
evolve
towards
cloud
native
is
important
to
the
telco
operators,
but
as
there
are
many
special
features,
taco
industries
has
we
we.
We
cannot
simply
copy
those
successful
experience
of
I.t
cloud
native
evolution.
We
we
have
to
explore
our
own
way.
So
here
I
listed
several
features
of
network
cloud
that
are
different
from
traditional
cloud
computing.
A
Firstly,
the
network
functions
are
our
core
applications.
We
don't
have
many
other
diverse
applications
and,
secondly,
the
network
functions
and
cloud
platforms
of
of
the
telco
operators
are
usually
bought
from
the
vendors
and
we
we
define
the
product
requirement
through
standards
and
we
don't
do
the
design
and
also
the
development.
A
And
the
the
other
feature
is
that
the
nfa
architecture
has
been
used
for
many
years
and
is
quite
mature
right
now.
So
if
we
want
to
involve
some
new
technologies,
we
have
to
considering
about
its
influence
on
the
nfa
architecture
and
also
the
the
the
workflows
and
also
in
telecom
environments.
We
have
relatively
solidified
operation
and
management
systems
and
the
processes.
A
So
we
have
many
things
that
different
from
the
I.t
industries,
but
but
here
we
found
some
common
features
that
can
be
shared
between
the
id
systems
and
also
the
telecom
systems.
The
number
one
is
micro
services
plus
sit
list.
These
are
about
the
application
design
and
also
we
would
have
agile
infrastructure.
A
We
have
summarized
three
research
points
that
were
exploring
the
first
one
is
how
to
achieve
a
network
function,
micro,
service
design
and
management,
because
application
is
always
the
vital
point
and
we
have
to
always
start
from
the
application
level.
And
the
second
research
point
is
the
capabilities
of
platform
to
support
the
cloud-native
network
functions.
A
A
We
have
draw
the
conclusion
that
there's
no
standard
on
network
function
micro,
service
design,
but
commonly
they
still
follow.
The
structure
of
the
physical
network
functions
which
contains
the
load,
balancer
module,
some
business
processing
unit,
the
oem
unit
and
the
data
storage
unit,
but
the
developers
are
doing,
do
do
working
on
splitting
these
units
into
smaller
pieces
for
micro
service
management.
We
we
don't
have
any
solution
for
this
now,
but
knowing
whether
to
manage
or
not
what
to
manage
and
how
to
manage.
A
Microservice
is
the
direction
and
for
past
we
have
working
on
path,
structure
and
capabilities
in
the
network
cloud.
How
to
involve
paths
and
merge
with
the
nfv
structure
or
even
change?
It
is
one
of
the
key
questions
we
we
try
to
answer
right
now
and
what
path
capabilities
and
corresponding
use
cases
is
another
thing
we
are
exploring,
and
this
is
happening
in
x,
develop
project
on
the
standard
promotion
part.
Our
team
has
also
done
a
lot.
A
A
We
follow
cncf
projects,
including
kubernetes
and
keynative,
and
also
we
start
a
new
one
named
x,
develop
to
explore
platform
capabilities
required
by
the
natural
cloud
we
we
have
found
that
cognitive
is
closely
related
to
first-hand
experience
of
network
function,
design,
development
and
operation.
So
it
requires
us,
as
an
operator
to
engage
in
all
these
procedures
and
have
internal
look
into
the
network
function
at
code
level.
So
we
think
start
from
open
source
practice
is
a
good
way.
A
B
Thank
you
for
the
information
hi
guys.
This
is
from
huawei
technology,
india,
private,
limited
and
I'll
be
covering
about
extremely
and
how
actually
we'll
be
solving
some
of
the
problem.
Statements
which
shiftware
has
actually
explained
before
to
start
with
extruela
is
a
open
source
telecom
class
part
pass
platform.
We
know
that
pass
has
passed.
B
Platforms
are
mainly
in
the
current
scenario,
and
we
want
to
actually
expose
what
the
telecom
needs
of
it
as
a
specific
functionality,
so
exhibit
is
actually
going
to
address
all
those
issues
which
are
there
as
a
part
of
telecast
problems.
The
problems
which
will
be
coming
across
in
telecast
world
and
we'll
be
looking
into
how
we
are
trying
to
solve
them
to
start
with
actualize
a
project
which
started
in
april
2020,
it
got
a
sandbox,
it
has
been
adopted
as
sandbox
watch
with
11
in
the
2021
january.
B
Currently
we
have
targeting
dsc
members
working
on
exuberance
who
have
been
participating
issues
in
different
functional
aspects.
The
if
you
see
the
architecture
of
extremely
it
mainly
constitutes
of
extension
to
the
past
platform.
The
general
path,
as
you
see
in
the
blue
box
here
is,
is
the
one
which
we
are
all
know.
What
extremely
scope
is
mainly
the
red
dotted
line
and
red
scope
here,
the
key
scope
being
the
solid
red
line
here,
which
is
actually
constituting
two
main
parts.
B
One
is
eruption
layer
which
is
an
extension
to
the
general
path
itself,
but
adapts
to
the
specific
telecom
needs
and
then
the
functionality
which
has
to
be
implemented
as
a
telecourse
itself.
I
know
it's
a
little
confusing
at
the
initial
stage
to
see
this
entire
stuff
as
a
building
block
we'll
be
covering
of
it
in
details
in
the
next
slide.
The
other
important
aspect
to
understand
here
is:
we
also
have
the
interfaces
to
the
general
pass
wherein,
as
and
when
necessary.
B
B
Our
mainly
scope
is
to
enhance
this
functional
here,
which
is
teleport
specific
pass
capabilities,
mainly
used
by
net
functions
and
teleco
management
systems
under
the
teleco
scenario
and
adaptation
layer
to
make
sure
that
this
teleco-specific
functionalities
are
adapting
properly
to
the
general
pass,
and
then
the
apis
are
on
it.
The
upper
bound
not
bound
for
this
will
be
again
any
application.
It
could
be
third
party
hosted
app,
it
could
be
any
nf
and
a
function
which
is
coming
from
any
osdt.
B
B
That
includes
issues
that
includes
functionalities
like
telemetry
monitoring,
logging,
the
scope
of
it
all
that
the
other
other
aspects
which
we
also
consider
our
the
service
mesh,
the
tracing
logging,
security
and
compliance,
and
all
that
what
we've
tried
to
build
on
top
of
this
is
the
telco
pass
layer
which
actually
is
talking
about
the
fmas.
The
metric
management
default,
the
configuration
which
are
again
looking
at
a
teleco-specific
functional
areas,
the
artificial
layer
which
is
actually
more
like
a
glue
between
these
two,
which
includes
some
protocol
enhancements.
B
It
can
be
enhancements
over
the
telemetry
monitoring
and
all
that
which
we
don't
require
to
use
as
it
is.
Maybe
we
require
to
fine
tune
as
the
on
need
basis.
Actually,
so,
if
you
see
the
pass
capabilities
requirement
are
actually
divided
into
three
different
categories:
one
wherein
we
required
to
implement
nf
functions.
The
other
is
pascal,
is
required
to
implement
enough
to
manage
the
functions
which
already
there.
B
That
is
what
we
are
talking
about
here
and
then
the
pass
component
to
expose
the
pass
capabilities
to
expose
enough
services
to
external
customers.
So
these
external
customers
we
are
talking
about-
are
these
layers,
which
is
actually
coming
as
part
of
the
this,
this
osspss
or
ao,
nap
or
nfu,
sort
of
orchestration
layer
or
the
oss
spaces
or
the
telemetry,
and
I
mean
the
metric
analytic
layer
and
all
that.
B
The
other
part
which
we
have
is
this
horizontal
part
which
is
going
to
be
useful
for
us
in
different
aspects.
We
require
to
actually
have
the
catalog,
the
lcm
part,
the
image
plus
registry,
all
that
this
is
what
will
be
our
horizontal
section.
This
diagram,
which
is
there,
is
to
illustrate
different
aspects
of
where
and
what
we
will
be
using
and
what
we'll
be
building
on
top
of
it.
B
B
The
mdcl
is,
is
a
most
of
us
may
be
knowing
that
that
it
is
pretty
advanced
past
platform
which
has
been
provided
by
maven
air,
and
it
is
in
production.
Some
of
the
key
features
have
been
adopted
from
that
from
the
as
part
of
seed
core.
Currently
we
have
the
cmas
the
conservation
management,
which
actually
provides
a0,
d1
and
j2
configurations
for
the
telugu
pass.
B
The
tmas,
which
is
specific
topology
management
as
a
service
which
again
is
providing
us
the
most
3gb
pmos,
which
is
nothing
but
manager,
objects
for
nfs.
The
f
mass
is
the
fault
management.
This
is
what
will
be
our
key
focus
area
to
do
this
part
of
release,
one
the
best
gateway,
the
cim
and
health
based
packaging
framework.
So,
as
the
name
suggests,
these
all
things
are
supporting
their
support
systems.
B
For
us
to
work
on
delivering
of
this
specific
functional
areas
is
what
we
have
as
a
part
of
release
man,
this
plan
right
now
we
are
focusing
on
fms
as
our
top
one
priority.
The
others
will
be
following
in
in
the
coming
month,
but
I
can
say
that
f,
mass
t
mass
and
this
n
part
of
c
mass
is
what
we
are
trying
to
deliver
as
a
part
of
various
one
f
mass
being
the
top
end
priority.
B
So
the
way
we
want
to
do
it
is
that
we
will
be
building
this
general
pass
capabilities
coming
from
okd
the
open
shift
coverage
distribution,
which
actually
has
most
of
this
operator
based
implementation.
The
k8s
operator
based
information
is
what
they
have
used
for
that
the
same
will
be
extended
and
integrated
to
this
specific
functional
areas
which
we
have
talked
about
and
together
we
will
be
able
to
constitute
the
the
functional
aspects
of
telicos,
specific
standardizations,
so
we'll
be
considering
the
3gbp,
the
tmf
standards.
B
Also,
while
we
deliver
this,
so
this
is
what
is
a
key
work
and
roadmap
to
to
crystallize
and
put
it
crisp.
As
I
said,
the
quality
operator
based
enhancement
is
what
we
are
going
to
have.
We
are
mainly
looking
at
three
major
integration
points
as
of
from
open
source
collaboration.
One
is
the
okd
part
which
I
just
discussed.
It
will
be
the
past
platform
where,
on
top
of
it
spot,
will
build
the
complete
teleco
functionality.
B
B
The
cnf
o
orchestration
part
of
it
is
what
we
are
looking
at
integration,
the
other
integration
which
we
are
looking
at
and
analyzing
it
as
at
the
moment,
is
an
fu
which
is
a
new
project
which
has
been
launched
in
lfn
again
coming
from
google.
So
this
also
is
is
actually
having
certain
integration
points
which
we
are
right
now
analyzing
will
be
getting
back
to
you
more
with
more
details
by
h2
this
year.
The
cicd
pipeline
is
actually
in
progress.
B
We
have
almost
finalized
everything,
the
argosy
being
the
most
right
candidate
for
us.
We
are
also
looking
at
other
aspects
of
other
other
functional
areas
which
we
can
cover
again.
This
is
some
coming
terms.
Something
which
won't
extend
as
a
part
of
the
k
it
is
itself
I
mean
we
are
looking
at
again
a
cicd
pipeline
which
can
be
adopted
so
that
developers
can
actually
do
their
build
environments
and
all,
and
it
can
be
easy
for
them
to
adapt.
B
I
mean:
take
the
existing
code
and
then
put
in
more
functional
areas.
The
prototype
build
is
something
which
we
are
also
working
on,
where
extroversion
integration
function,
functional
integrations
with
general,
pass
information
and
deploy
and
build
a
prototype.
So
this
is
one
area
where
we
are
constantly
working
on
taking
the
inputs
from
different
operators.
B
B
The
other
important
thing
is,
I
said,
the
continuous
teleco
pass
functionality
adaptation
layer
where
we
want
to
give
much
more
demonstrations
to
using
the
instability,
that's
what
we
are
trying
to
have
it
from
h2
onwards
and
then
demos.
So
this
demo
right
now
we
are
having
the
the
seed
code.
That's
the
okd
person
at
the
cneps
as
to
start
with
again
I
want
to
emphasize.
We
are
not
building
a
platform.
B
With
that,
I
want
to
actually
give
up
the
key
information
from
hula
point
of
view.
The
conference
is
where
we
have
takeshiwella
has
its
own
github
xiv
has
its
own
wiki
in
under
the
elephant.
The
kc
meeting
actually
happens
on
every
tuesday
1
pm
utc.
Please
do
join
us.
The
meeting
id
has
been
provided
here.
We
have
two
different
ways
in
which
we
can
actually
communicate
with
xivera.
If
you
have
any
questions
or
not,
one
is,
of
course,
the
mail
chain.
B
The
other
thing
is
we
have
a
slack
channel
and
then
the
whatsapp
group
again
the
group
details
and
all
are
provided
in
the
wiki
and
the
github
is
where
we
actually
have
the
initial
discussions.
Before
we
were
part
of
lf
networking.
We
were
actually
having
the
github
as
as
even
for
documentation,
so
you
will
see
both
the
code
as
well
as
the
the
initial
discussions
in
all
in
github.