►
From YouTube: Towards the Cloud Native Telco: Learning from the Trenches - Josua Hiller & Ruben Merz, Swisscom
Description
Towards the Cloud Native Telco: Learning from the Trenches - Josua Hiller & Ruben Merz, Swisscom
At Swisscom, we are engaged in an ambitious technology and cultural transformation towards cloud-native readiness. We believe it is an essential component to keep on thriving in an increasingly competitive environment, and to further deliver reliable services, while accelerating delivery and improving efficiency. While the CNCF ecosystem is incredibly rich, its applicability to the development and operation of reliable telco service is in its infancy. Hence, in this talk, we want to share our observation from working for the past two years on the deployment of our 5G Core platform: in particular, while Kubernetes allows for full life-cycle automation of telco network functions, we see the need for four improvements areas: (1) independence between network functions and the underlying infrastructure; (2) increasing the maturity of configuration and state management of network functions; (3) some constraints of the 3GPP architecture; and (4) the need for service observability.
A
A
I'm
looking
forward
for
further
discussion
during
today
and
yeah.
I'm
happy
to
to
take
all
your
questions.
I'm
very
excited
to
tell
you
more
about
our
cloud
native
journey
with
the
5g
core
and
our
learnings
at
swisscom.
So
this
talk
will
be
useful
for
you.
If
you
are
interested
to
hear
about
our
experience
and
learning
from
our
cloud
native
telco
journey
of
an
ambitious
team
building,
a
5g40
converged
core
at
swisscom,
so
unfortunately,
ruben
is
not
able
to
join.
Today.
A
He
is
moving
from
swisscom
to
aws
to
pursue
a
new
opportunity,
but
nevertheless
we
prepared
this
presentation
together.
He
gave
me
a
lot
of
thoughts.
Ideas
help
me
to
to
get
to
the
essence
what
to
present
here.
So
I
need
to
say
a
big
thank
you
for
you
reuben
to
help
me
to
stay
here
today
and
yeah.
It
was
a
pleasure
to
work
with
you.
A
A
I
as
well
have
a
very
strong
passion
about
agile
and
lean
way
of
building
services
and
yeah.
During
my
time
at
telstra.
I
really
could
experience
in
the
daily
work.
How
agile
and
and
also
using
scrum
could
really
like,
improve
our
daily
work
and
have
more
be
able
to
be
more
innovative
as
well.
Yeah
have
more
fun
at
work
in
the
end,
so
yeah
who
we
are
so
swisscom
is
the
major
telecommunication
provider
in
switzerland
and
has
one
of
the
let's
say
best
network
worldwide
at
swisscom.
A
A
So
at
mobile
networks,
our
group
we
develop
and
operate
this
new
5g
4g
converged
core
yeah.
We
have
been
closely
working
with
our
network
function,
vendor
ericsson
in
an
agile
setup.
So
we
have
people
from
ericsson
in
our
devops
team
and
we
closely
work
together
with
them
to
to
build
and
deploy
and
operate
our
5g
core
in
the
end,
so
we
realized
very
early
that
it's
not
only
a
technology
shift.
It
also
is
a
transformation
on
skills
culture
and
how
we
collaborate
with
each
other.
A
So
there
we
yeah,
for
there
is
this
new
technology
paradigms
where
we
need
like
really
a
different
mindset,
culture
and
skills.
So
on
the
technology
challenge,
there
is
really
the
skill
gaps
we
see
in
the
telco
ecosystem,
so
there
yeah.
We
need
the
new
skills
which
are
more
software
engineering,
to
help
to
build
this
cloud
native
workloads
in
the
end.
So
there
we
have
this
transformation
journey
where
we
embrace
on
the
change.
A
A
A
A
So
what
we
do
so
I
would
like
to
tell
you
some
more
details
about
what
we
do
at
swisscom.
As
mentioned,
we
engage
in
ambitious,
ambitious
technology
and
cultural
transformation
towards
the
cloud
native
ready
readiness
to
be
successful.
In
this
we
started
to
to
build
a
new
like
domain.
We
call
this
cloud
native
mobile
cloud
native
services,
where
we
brought
together
a
software
engineer,
teleco
engineer
cloud
engineers.
A
We
even
found
new
teams
to
build
a
service
management
tool
which
I
will
came
on
later
and
really
have
from
a
design
view
to
an
operating
view
to
a
life
cycle.
Viewed
all
the
people
in
one
domain
to
make
this
successful,
then
yeah.
We
we
started
to
integrate
this
5g
network,
where
we
deployed
this
to
our
nfvi
cloud
for
now,
but
on
the
other
hand,
just
half
a
year
ago,
we
started
our
public
cloud
journey,
so
we
work
now
closely
with
aws,
where
we
collaborate
to
bring
our
5g
core
to
to
the
aws
regions.
A
In
the
end,
where
soon
they
will
also
open
a
region
in
switzerland.
As
well
then
said
before
we,
we
started
with
two
new
teams:
building
in-house
a
service
management
framework
or
tool.
So
there
we
at
swisscom
really
see
that
it's
key
for
an
operator
or
a
telco
to
have
this
capability
to
design
end-to-end
services,
so
not
only
like
the
5g
core
itself,
but
really
end-to-end
that
you
can
then
operate
network
slices
at
the
scale
and
then
also
what
we
started
this
to
to
go
in
a
githubs
journey.
A
A
Now
some
more
details
on
the
simano,
so
I
created
as
well
some
hashtags.
I
would
very
appreciate
if
you
could
maybe
tell
me
your
thoughts
about
this
and
and
yeah
also,
if
you
have
any
questions
around
this,
so
we
have
sema
here,
which
is
our
service
management
tool
which
is
based
on
etsy
ns,
or
we
can
design
nsds,
so
network
service
definition
templates,
which
then
can
talk
to
an
nfvo
in
the
middle.
A
But
on
the
other
hand,
this
semi
is
as
well
able
to
to
push
all
the
the
yaml's
that
value
or
the
stuff
you
need
to
be
able
to
configure
to
the
githubs
pipeline
or
to
git
in
the
end-
and
here
we
also
then
have
for
the
cnf
lifecycle
management.
We
have
the
vnfm,
which
then
do
the
deployment
towards
the
cars
and
as
well.
A
So
here
on
the
on
the
left
side,
we
get
the
software
from
our
vendors.
You
know
into
our
artifactory,
then
we
have
our
overarching
jenkins
pipeline,
where
we
have
different
supply
pipelines
to
source
software,
to
get
notification
and
trigger
other
pipelines.
Then
we
have
a
configuration
pipeline
for
the
application
configurations.
A
We
have
an
element
manager
pipeline
and
as
well,
some
test
pipelines
and
all
this
is
based
on
the
source
of
truth.
We
have
in
git
so
everything
which
we
configure
or
wants
to
to
add
to
our
environment
we
define
and
get,
and
then
we
use
in
for
the
deployment
of
the
containers
we
use
flux
to
deploy
like
an
amf
in
this
case.
A
So
it
takes.
The
config
from
git
then
goes
to
the
artifactory,
take
the
the
docker
images
and
the
helm,
charts
and
deploy
the
network
functions
and
then,
after
this,
it's
able
to
trigger
the
configuration
pipeline,
which
then
use
ansible
as
well.
Ansible
is
asking
it
for
all
the
day,
two
or
the
application
configuration
and
then
push
this
configuration
over
netconf
to
to
the
cnaps
in
the
end.
A
A
So
yeah,
during
our
journey
we
explored
different
things.
We
had
a
lot
of
learnings,
so
here
we
we
could
group.
We
can
group
this
like
in
four
different
pillars.
So
first
is
the
we
still
see
a
lot
of
vertical
integration,
with
the
appliance
towards
cash
and
even
underlying
infrastructure,
which
is
mainly
also
due
to
telco
specific
protocols
and
requirements.
In
the
end,
then
yeah
missing
configuration
management
capability
for
really
the
end-to-end
automation.
A
I
will
go
deeper
in
the
next
slides,
then,
from
the
architecture
side
there
we
still
see
that
from
the
standardization
point
there
is
still
like
a
very
monolithic
view
on
software
and
then
another
big
topic
is
the
whole
end-to-end
observability.
I
also
would
like
to
to
tell
you
more
from
from
our
experience
so
far.
B
A
A
There
is
still
like
a
vertical
integration
towards
kubernetes,
so
it's
in
our
view
not
to
not
fully
cloud
native
where
you
just
deploy,
kill,
deploy,
kill,
containers
and
even
like
have
immutable
containers
or
microservice.
In
the
end
it
also
we
we
saw
that
we
often
use
this
crds
which
in
the
end
had
dependencies
and
you
could
to
some
extent
not
deploy
just
any
network
function
in
the
same
kubernetes
cluster,
and
there
also
we
see
still
like
tight
integration
of
different
microservices.
A
So
this
means
that
you
could
deploy
a
network
function,
but
then
you
would
need
to
add
some
day.
One
configuration
that
other
pots
or
microservices
will
start,
and
this
is
something
yeah.
We
really
should
avoid
in
a
cloud
native
environment,
then
then
also
scaling,
especially
on
the
user.
Plane
function
is
still
very
limited.
A
It's
mainly
due
to
specific
telco
protocols
we
need
so
there
we
see
that
we
still
need
to
do
upfront,
a
very
specific,
like
low
level
design
to
be
able
then
to
at
least
to
scale
to
the
to
the
resources
we
define.
Upfront
then
also,
something
which
is
interesting
is
really
this
layer.
Two
segmentation,
we
in
the
telco
industry,
use
a
lot
of
vpns
to
separate
different
networks.
A
A
A
So
that's
something
yeah
which,
which
is
very
interesting,
so
we
mostly
just
discussed
about
deploying
all
the
cnfs,
but
then
it's
like
building
a
house,
but
in
the
end
it's
not
finished.
So
all
the
interior
is
still
missing,
like
kitchen
stairs
electricity,
which
is
like
the
day
one
configuration
or
the
application
configuration.
A
So
we
have
models
to
deploy
a
5g
core,
so
the
containers,
everything
but
then
to
configure.
There
is
a
model
still
missing
where
you
could
go
an
abstraction
layer
on
top
in
the
end,
so
there
we
we
see
that
every
network
function
like
upf
pcf.
They
have
their
own
business
logic
with
their
own
details,
their
own,
like
failover
scenarios,
and
this
is
just
making
us
a
lot
of
headaches
in
the
end,
then
there
is
still
this
yeah
net
con
versus
the
cloud
native
way
of
using
like
config
maps.
A
So
you
have
like
one
central
point:
you
configure
your
network
function
versus
more
the
immutable
capability.
Where
you
add
the
configuration
of
the
application
already
during
the
deployment,
so
so
netconf
in
the
end
is
great,
but
on
the
other
hand
you
have
very
tight
integration
and
it
makes
yeah.
It's
not
very
useful
in
case
that
you
just
can
start
kill,
start
kill
any
services.
A
So
we
didn't
take
this
too
serious
at
the
beginning,
but
now
we
try
really
to
deploy
this
5g
cores
in
public
cloud
and
there
they
don't
offer
all
this
telco
specific
capability.
So
there
we
need
to
find
solution
to
make
this
possible
and
really
the
last
point
don't
try
to
automate
excel,
really
focus
on
building
configuration
as
a
code
so
to
be
able
to
have
on
top.
A
A
So
we
say
that
the
standards
today
they
are
not
really
cloud
native,
so
they
get
in
the
way
of
decoupling.
So
there
is
still
the
trap
of
monolithics
applications
where
we
as
telcos
think
really
yeah.
There
are
all
the
boxes
like
upf,
amf
and
and
and
so
and
you
have
your
standardized
interface,
but
in
the
end
this
don't
help
us
to
really
build
a
like
more
distributed
systems,
just
a
lot
of
microservice.
A
In
the
end,
building
your
end-to-end
service
and
yeah
there,
we
really
should
go
more
towards
a
micro
service
design
instead
of
a
large
service
design,
as
we
have
today
with
the
sba
in
case
and
then
on
top.
We
have
this
complex
failover
scenarios
from
all
the
different
network
functions,
but
there
we
think
we
really
should
leverage
more
the
native
capability
of
of
some
like
service
mesh,
to
build
this
failover
scenarios
between
microservice
instead
to
build
a
layer
on
top
very
specific
to
telco
environments.
A
And
then
the
whole
observability,
so
we
are
very
happy
to
see
with
cloud
native
network
functions
that
observable
to
some
extent
observability
is
already
built
in.
So
it's
very
easy
to
retrieve
metrics
locks
traces,
but
still,
if
you
want,
then
to
get
the
end-to-end
view,
it's
still
very
hard
to
to
get
this
together.
A
So
there
we
we
need
to
find
the
right
solution
and
also
because
of
the
very
specific
telco
protocols
like
the
troubleshooting,
especially
in
in
distributed
system.
It's
it's
not
just
straightforward!
So,
for
for
some
protocols
you
cannot
just
use
jagger
for
distributed
and
tracing
in
the
end,
so
here
would
be
our
call
for
improvement.
A
A
So
we
try
to
troubleshoot
here
here
and
instead
of
just
deploy
and
if
it's
not
working
kill
it
deploy
it
again.
So
this
mindset
need
to
more
and
more
evolve
in
the
end,
so
really
avoid
vertical
integration
and
yeah.
Sometimes
we
really
need
to
redesign
network
function
from
scratch,
really
with
the
cloud
native
principles
in
mind
and
then
on
the
configuration
management
yeah.
A
We
really
see
the
need
as
an
operator
that
we
want
to
run
over
5g
core
workloads
on
any
cloud,
and
this
is
not
yet
really
working.
What
we
see
we
still
need
months
or
even
years,
to
implement
the
5g
core.
We
we
not
can
just
hit
the
button
and
then
it's
deployed
when
we
can
do
we
do
this,
then
we
already
spend
like
half
a
year
to
to
make
everything
working
and
really
also
something
where
I
saw
now
a
new
project
which
could
help
there.
A
So
with
this
I
would
end
so
that's
our
conclusions,
so
I'm
very
happy
that
we
started
early
at
swisscom.
We
really
put
automation
as
a
key.
So
when
we
started
to
build
this
cloud
native
environment,
we
said
we
want
to
start
automate
everything
from
day
one
and
we
really
invested
the
time
to
understand
the
technology
regarding
end-to-end
service,
orchestration
or
service
management.
A
C
B
A
Yeah,
what
we
see
is
still
that
we
have
this
telco
specific
protocols
like
gdp
which
don't
allow
for
netting,
and
there
also,
we
think
we
need
to
look
into
like
software
solutions
which
will
help
us
to
to
provide
there
more
flexibility
that
you
don't
have
there.
This
vertical
integration
in
the
end,
and
also
like
today,
we
we
still
n
need
to
use
like
astro
iov
to
for
the
hardware
acceleration
for
the
throughput.
A
I
think,
if
there
we
maybe
could
we
do
something
with
ebpf
to
make
this
much
more
flexible.
I
see
like
aws,
are
offering
solutions
where
they
claim
to
almost
achieve
line
rate.
So
I
think
there
it's
it's
really
on
the
on
some
network
plug-ins
for
kubernetes,
which
could
help
us
to
avoid
this
vertical
integration.
A
A
Yes,
we
are
using
it,
so
we
we
build
a
5g
4g
converged
core,
so
we
have
cnfs
which
are
including
microservice
doing
the
the
4g
as
well.
The
5g
part
in
in
the
same
cnf
in
the
end
so
have
different
interfaces,
and
maybe
even
this
is
maybe
sub-optimal
for
running,
like
really
independent
services.
In
the
end,
I
I
personally
also
see
like
we
have
this
very
narrow
way
of
defining
cnfs
like
upf,
pcf
and
all
this.
D
A
We,
I
would
say
we
started
two
years
ago,
where
we
like
builded,
a
first
team
looking
into
like
mainly
the
5g
assay
core,
so
we
started
to
build
this
from
our
network
vendor
the
first
they
were
like
they
just
started
to
deliver
this
5g
core
function
as
containerized
workloads
in
the
end,
so
that
was
about
two
years
ago,
but
I
need
to
say
so
today
we
don't
have
a
production,
productive
system.
We
are
still
working
on
because
we
said
from
beginning.
A
A
A
E
You
know
early
features
early,
but
then
at
the
same
time
you
know
if
you're,
creating
this
orchestration
layer
and
being
kind
of
first
to
it
and
that's
somewhat
challenging,
let's
say
like
the
telco
isv,
I
mean:
how
are
you
managing
that
relationship
like
how
you
bring
them
to
the
table
and
says
hey
we're
going
to
run
this
in
kubernetes
we're
going
to
do
this
and
this
and
then
they're
kind
of
stepping
back
saying?
Oh,
we
don't
support
that
yet
you
know
so
it'd
be
great.
If
you
could
like
unpack
a
bit
of
that.
A
So
we
could
start
very
early
to
learn
what
this
means
to
deploy
a
network
function
into
a
kubernetes
cluster
and
they
are
yeah
like
using
microservices
but
yeah,
it's
a
and
because
we
are
working
very
closely
with
our
network
function
vendor.
So
we
have
devops
team
where
we
have
our
network
function
vendor
as
well
in
the
teams,
so
they
are
as
well
devops
engineer.
A
F
F
A
A
Example
yeah.
Today
there
we
use
like
net
cool
for
all
the
more
the
observer
operation,
part
of
managing
the
the
different
incidents
and
everything,
and
there
we
now
like
started
to
use
like
patriot
or
obscenity,
which
is
much
more
built
for
devops
team.
But
then
we
still
need
to
see
how
we
integrate
to
the
existing
process
for
level
two
support
and
everything.
A
C
A
C
The
landscaping
you
have
a
lot
of
dependencies
as
well
with
suppliers,
vendors,
telco
protocols
and
so
on.
So
the
question
is:
where
do
you
see?
What
is
your
goal,
your
vision
and
have
you
quantified
that
when
I
reach
my
end
goal
that
I
have
short
of
my
challenges,
the
network
looks
like
something
right:
yeah
you
quantify
the
benefits
like
okay,
I
did
it.
I
fully
automated.
I
see
your
challenges.
What
is
the
finally
the
was
it
worth
it?
Finally,
and
what
was
the
benefit.
A
So
the
final
goal
would
be
really
that
we
can
use
our
service
management
infrastructure
or
tools
framework
really
to
deploy
our
workload.
We
need
to
to
provide
telecommunication
service
over
any
infrastructure,
so
we
want
to
be
able
to
design
in
this
service
management
and
then
what
is
available
where
we
get
the
best
resources
or
whatever,
to
be
able
to
deploy
it
and
as
well
to
life
cycle
it
so
the
whole
ci,
cicd
or
also
continuous
testing
is,
is
a
big
thing
in
in
this.