►
Description
Lessons Learnt Developing and Deploying a Cloud Native Network Function - Paul Graham, Matrixx Software
Paul Graham will present MATRIXX Software’s experience with implementing a 5G ready Cloud Native Charging Function, the lessons learnt and how other organizations can replicate the success.The CHF has been validated in several public cloud providers along with the corresponding K8s variants.The CHF has several legacy network aspects,so the challenges of implementing these in the mentioned environments will be discussed along with pragmatic solutions. The details of issues that have been overcome such as providing carrier grade availability, incorporating into CI/CD environments, the migration from legacy networks, security, scaling as well as the changes required in process and mindset. Paul will also discuss developing a green field Cloud Native Function which was identified as a critical element required to aid the migration between 3G/4G and 5G networks. Several key design decisions were undertaken during its implementation which can be shared with the audience. Also, the CNF was validated using a test suite developed in collaboration with the Cloud Native Foundation, so the details of this will be discussed.The session will complete with a discussion on the lessons learnt.
A
My
name
is
paul,
graham
I'm
from
matrix
software
director
of
uk
engineering,
we're
a
silicon
valley
based
online
charging
company
heavily
involved
in
cloud
native
and
5g.
It's
great
to
be
here.
Presentations
so
far
been
excellent
lots
of
useful
information
and
I'm
pleased
to
say
my
presentation
exactly
lines
up
with.
What's
already
been
said,
and
I
feel
this
is
a
great
way
of
ending
the
day,
because
I
will
be
emphasizing
some
of
the
points
that's
already
been
said.
A
So
our
original
goal,
when
creating
the
cnfs,
was
we're
taking
a
4g
online
charging
and
putting
it
into
the
strange
new
world
of
5g
and
cloud
native
that
involves
implementing
the
5g
rest.
Spa
has
always
already
been
highlighted,
containerizing
the
services
and
then
moving
it
to
a
fully
compliant
cloud
native
network
functions,
as
we've
already
heard
today.
This
is
challenging
there's
issues
that
come
up
along
the
way
and
that's
what
I'll
be
discussing
today.
A
So
it's
what
you
know
as
a
4g
monolith
on
bare
metal
that
the
boxes
in
vms,
as
discussed
earlier,
we're
then
involved
in
multiple
trials
and
installations.
So
companies
like
dyson
in
the
us
with
the
5g
18t
mexico,
telstra
tpg
in
australia,
big
globe
and
swisscom
the
name,
but
a
few,
a
lot
of
experience
there.
So
we
are
a
vendor.
We
have
to
work
what
the
operators
want.
So
we
have
had
to
work
in
all
sorts
of
google
cloud
is
here:
aws
openshift.
A
We
have
experience
of
working
everything,
and
this
is
a
constant
learning
experience
and
a
constant
improvement,
and
what
I've
done
in
this
presentation
is
really
highlighted.
Some
of
the
pain
points,
summer
learning
exercises
and
what
we
need
to
do
in
the
future
to
keep
moving
along,
and
I
say
I
particularly
like
some
of
the
earlier
presentations
from
joshua,
michael
because
it
really
emphasizes
these
points
we're
right
in
there.
So
where
are
we
as
a
charging
company
business?
A
A
A
I
started
my
career
28
years
ago,
doing
iron
and
voice
fixed
line
and
that
evolved
to
mobile.
So
this
concept
of
separation,
of
control,
plane
to
user
plane,
I'm
familiar
with
that
and
there's
lots
of
angles
and
aspects
from
the
previous
generations
that
still
need
to
be
supported
in
this
world.
So,
even
though
we
have
5g
core
there's,
things
are
missing,
like
the
voice
support
things
like
sigtran
and
other
aspects
like
charging
for
messaging
and
those
sort
of
things.
A
So
this
is
the
challenge
we
have
so
when
we
took
the
existing
online
charging
system
and
containerized
it.
We
ended
up
with
this.
This
is
a
simplification,
of
course
it's
very
much
complex,
but
this
gives
an
indication
of
how
complex
the
problem
is:
we're
not
talking
about
one
cnf,
we're
talking
about
taking
many
parts
of
the
system
and
how
I'm
going
to
put
it
into
our
own
cluster,
and
this
is
ongoing
activity
to
the
left.
We
have
the
networks,
we
have
the
support.
A
We
have
a
talk
to
the
oss
and
bss
systems
and
it's
interesting
being
here
in
the
charging
world.
Where
do
we
sit
because
we
have
to
work
with
the
network
side
and
we
have
the
oss
bss
and
these
two
domains
have
can
have
very
different
requirements
in
the
cloud
and
cloud
native
and
an
assortment
of
other
systems
like
billing
payment
gateways
and
the
things
that
typically
come
with
a
complete
charging
and
billing
system
for
telco,
and
we
do
find
occasionally.
You
know
it's
an
afterthought.
A
As
we
know,
if
we
spoke
about
before
we
are
in
telco,
so
we
have
a
list
of
these
requirements.
We
absolutely
must
adhere
to.
We
have
high
availability,
we
talk
about
the
five
nines,
but
that's
taken
very
seriously.
No
down
time
we
have
years
and
years
of
legacy
requirements
that
each
generation
we
have
to
pull
along
with
us
lots
of
business
rules
in
the
uss
systems.
A
lot
of
networking
a
lot
of
interworking.
A
This
all
has
to
be
accommodated
as
we
move
to
the
next
generation
of
telco.
It's
5g,
it's
highly
regulated.
That's
already
been
mentioned.
You
know
where
we
put
data,
how
we
treat
data
in
charging
its
monetization,
even
more
regulation
on
top
of
what
we
already
have
in
telco,
so
that
presents
a
significant
challenge
to
us
as
well.
A
Stan
is
based.
We
have
to
head
here
to
the
standards
and
sometimes
in
the
other
world's
web
scale.
For
example,
you
can
invent
your
own
things.
You
actually
must
adhere
to
these
standards,
which
we
have
to
keep
taking
forward
with
us
and
yeah.
It
straddles
iot
and
networks
which
have
different
cloud
requirements,
and
we
could
almost
sometimes
be
deployments
where
the
networks
are
in
one
type
of
public
cloud
and
the
iot
and
oss
systems
and
different
other
public
clouds.
A
So
this
is
the
challenge
we
have
when
dealing
with
charging
systems,
I
mean
out
of
interest
who
here
would
say
they're
in
networks.
We
want
to
raise
your
hand,
your
networks,
yeah.
Anybody
else
in
the
id
space
want
to
raise
your
hand
yeah
okay.
So
we
have
a
mixture
of
people
to
kind
of
understand
the
different
domains,
we're
playing
in.
A
A
So
it's
usually
a
gradual
migration
and
we've
seen
hybrid
approaches
where,
in
that
diagram,
you
saw
that
the
networks
are
5g
sba.
Well
that
started
off
in
cloud
native,
because
the
nature
of
it
with
the
rest
interfaces,
but
some
of
the
legacy
stuff
stays
on
bare
metal
in
the
and
in
the
previous
approach
you
end
up
the
kind
of
a
high
bridge
architecture
which
is
gradually
moving
to
pure
cloud
native
one
approach.
Another
project
be
build
a
green
field
and
migrate.
A
A
Why?
While
we
go
in
to
cloud
in
the
first
place,
well,
we
know
in
telecoms,
innovation
can
be
slow,
so
we
want
to
be
able
to
adopt
the
kind
of
the
crcd
approaches.
Rapid
upgrades,
not
those
six-month-year
installation
projects,
as
somebody
said
earlier,
let
us
do
the
upgrades
install
it.
Leave
it
there
for
a
couple
years,
come
back
again
right.
The
reason
we're
doing
this
is
we
want
to
move
to
a
more
rapid
upgrade
approach,
and
so
we
could
be
introduced
more
innovation
into
the
services
quickly
and
things
like
data.
A
A
So,
as
I
said,
we've
got
challenges
on
the
telco
side
of
things:
the
traditional
taco,
I
don't
know
how
many
people
here
are
familiar
with
like
cat
protocol
with
sigtran
sctp
has
been
mentioned
earlier
on,
and
the
issues
around
that
this
is
a
big
issue
in
the
online
charging
system,
we'd
like
to
think
we're
just
dealing
with
data
and
everybody's
going
to
move
the
whatsapp
for
voice
calls
and
these
sort
of
things
that
isn't
going
to
happen
across
the
world
and
all
the
operators.
Most
people
are
still
on
voice.
A
A
big
number
in
telco
is
still
in
emerging
markets
where
they
support
voice
and
these
protocol
and
the
traditional
aspect
still
had
to
be
supported,
but
in
cloud
natives
sctp
in
kubernetes
is
getting
there,
but
we
can't
say
it's
in
every
variant
in
every
public
cloud
that
we
come
across.
So
this
proposes
a
significant
challenge
but
say
that's
already
been
mentioned
today.
A
But
as
we
mentioned,
we've
got
the
multi-homing
and
multi-pathing
issues
with
sctp
that
have
to
be
supported
and
things
like
multiple
cni's
in
containers,
using
tools
like
mortise
are
being
brought
in,
but
they're
still
not
there
yet.
So
in
my
domain
of
moving
traditional
telco,
this
is
one
of
the
biggest
challenges
I
see
at
the
moment,
and
we
still
have
to
kind
of
go
forward
cautiously,
look
at
every
use
case
and
see
how
we're
going
to
implement
it
and
say
it's
work.
That
still
has
to
be
done.
A
A
The
other
big
issue
in
telecoms
is
state,
and
this
is
where
the
pure
cloud
native
people
start
chucking
things
at
me,
because
you
know
we
want
everything
to
be
stateless,
but
realistically,
when
you
step
back
into
the
legacy
world
of
telco,
there's
a
lot
of
state
in
there
and
that
point's
already
been
highlighted.
I
think
by
michael
this
morning
that
you
know
if
you
have
like
a
system
with
lots
of
components.
A
Microservices,
like
I
put
up
earlier,
and
you
want
to
upgrade
one.
Then
you've
got
these
dependencies
because
you
have
state
throughout
the
system.
If
you're
doing
voice
calls
voice
calls
have
states
the
voice.
Scores
are
asserted
with
a
charging
session.
That's
two
sessions.
You
have
in
the
system
the
voice
cap,
the
charging
reservations
that
you
typically
have,
and
then
you
start
having
the
state
in
the
system.
A
A
Now
an
interesting
thing
we
did,
we
did
develop
a
pure
cnf,
so
this
is.
This
is
kind
of
like
a
brand
new
component
that
was
developed
as
a
pure
cnf
and
that,
ironically,
it's
a
charging
bridge
to
help
us
migrate
from
the
old
world
into
the
new
world.
So,
as
I
said
typically,
when
you
build
your
5g
core,
sometimes
you
find
components
left
behind
and
this
can
be
the
ocs.
So
you
have
a
4g
ocs
which
still
supports
diameter
and
then
suddenly
it's
not
compatible
with
your
5g
core.
A
A
You
then
have
a
diameter
client
up
into
your
ocs,
but
interestingly,
this
was
a
good
way
of
of
building
building
a
a
pure
cnf
and
then
being
able
to
engage
with
a
conform
suite
which
I'll
talk
about
a
bit
later,
and
it's
already
been
discussed
today
and
here
at
matrix,
we've
played
a
big
part
in
the
the
conformancy
suite
because
we
had
a
pure
cnf.
We
owed
a
start
from.
A
A
It
goes
through,
whatever
your
service
mesh
into
diameter
clients
talking
to
ocs,
and
this
was
able
to
be
developed
as
a
pure
cnf,
which
was
able
to
be
compliant
with
the
test
suites,
and
we
use
this
as
a
way
of
taking
the
cloud
native
teleco
test.
Suites
running
the
tests
against
it
and
developed
working
with
the
team
to
develop
the
conformity
tests.
Suites.
A
So
we
end
up
with
a
conformity
test
suite.
So
if
you're
not
familiar
with
it,
it's
a
project.
That's
been
running,
it's
a
set
of
auto
testing
scripts
and
it
adopts
all
the
principles
of
cloud
native
function
so
to
demonstrate
conformancy
implementation
of
best
practices.
It
does
mean.
If
somebody
wants
to
develop
a
atarco
cloud
native
function,
they
can
get
this
test
reader
at
github
and
they've
got
kind
of
something
to
build
against.
It
gives
them
a
sort
of
a
framework
to
try
it.
A
And
this
has
been
quite
a
fruitful
exercise
because
it
means
you've
got
a
kind
of
a
reference
point.
You
can
work
between
organizations
and
it's
a
point
where
you
can
agree
on
how
these
cns
are
going
to
look
like,
and
if
you
have
an
agreement
on
what
they
look
like,
then
you
can
have
a
way
of
putting
them
into
your
pipelines
and
a
standard
structure
of
using
them.
A
A
Installation
where
you
will
have
some
components
as
cloud
native
functions,
some
may
be
some
on
bare
metal
as
you
pour
them
through,
particularly
in
the
kind
of
the
signaling
side
of
the
networking
sctp
and
as
sort
of
kubernetes,
and
the
ecosystem
catches
up
eventually,
you'll
be
able
to
replace
everything
and
yeah
we're
waiting
for
kubernetes
to
approach
maturity
for
telco,
and
that's
us
we're
working
on
that
we're
pulling
it
forward
and
keep
working
on
it.
Another
one
it's
already
been
mentioned
is
the
logging
observability
and
telemetry
and
yeah.
A
A
A
I
think
today
we
probably
identified
them
when
you
start
building
something
for
real
and
you
hit
a
gap
or
something
you
think
well,
this
isn't
quite
working
as
we
want
it
to
work,
we're
going
to
have
to
work
on
developing
these
things
and
pushing
the
community
to
to
build
them
for
us
or
work
together
to
build
them
and
yeah
test
automation.
Again,
that's
already
been
mentioned
in
your
pipelines,
I
think
is
increase,
is
key
to
getting
that
cadence.
A
You
know
we're
moving
to
5g
for
a
reason.
That
reason
is
we
want
to
put
things
in
the
cloud
we
want
to
increase
the
rate
that
we
can
do
upgrades
installations
and
that
enables
quicker
innovation
and
coming
back
to
that
sort
of
six
months,
installation
upgrade
project
it
takes
so
much
effort
to.
We
then
have
to
leave
it
a
couple
years
come
back
to
it,
that
hinders
innovation.
A
A
So,
what's
the
road
ahead?
Well,
yeah:
we've
going
to
fill
these
gaps
required
by
traditional
telco.
If
we're
going
to
move
everything
into
cloud
native
right
things
like
the
protocols
sctp,
that's
a
bit
of
an
anchor
for
us
at
the
moment.
It's
dragging
us.
We
need
the
support
of
them,
but
it's
going
to
stop
us
going
pure
cloud
native.
A
We
need
to
gain
trust
to
move
to
seated
models
right.
I
guess
we'll
mix
of
operators
and
vendors
we've
got
to
develop
trust
where
we
can
have
that
rapid
upgrades
where
the
cns
get
pushed
out,
go
into
automatic
testing
and
then
get
deployed.
You
know,
we've
got
to
all
work
together
to
develop
that
system.
So
we
do
get
that
increased
rate
of
change
and
upgrades,
which
is
you
know,
the
biggest
problem
in
the
industry.
A
B
A
B
B
I
mean
putting
all
that
together.
Do
you
not
see?
One
of
the
missing
components
here
is
that
the
business
needs
to
see
that
the
end
customer
isn't
just
the
consumer
with
the
sim
cards,
the
plans
and
everything
that
is
actually
like
the
public
cloud
is
the
developer
and
that
that
servicing
into
over-the-top
offerings
like
whatsapp.
B
If
you
could
sell
in
an
ims
solution
that
you
could
build
in
carrier-grade
voice
in
these
over-the-top
offerings
and
then
from
a
charging
perspective,
you
can
you
know,
model
those
technical
products
towards
developers
and
that's
only
available
because
or
enables
the
operator,
because,
if
they're
built
on
cloud
native
technology
that
they
can
actually
do
this,
you
know.
Do
you
not
think
that
there's
something.
A
Yeah,
I
do
absolutely
like
no
yeah,
because
the
whole
point
of
cloud
native
is
it's
not
just
about
building
a
5g
core.
It's
having
a
cloud
that
you
can
put
other
things
into
yeah
and
once
you've
got
in,
you
build
up
the
trust
and
you
increase
the
performance
and
reduce
latency
right,
because
everything's
bound
together,
telco
doesn't
like
anybody
just
going
into
their
networks
and
changing
things.
Yeah.
B
A
There's
a
there's
quite
significant
dmz
between
the
telcos
and
the
charging
systems
and
the
over
the
top,
and
at
the
moment
it's
a
gap.
This
big
yeah
I
mean,
and
yes,
we
we
we're
in
online
charging
absolutely
right.
We
we
want
to
bring
in
the
the
the
whatsapps
and
the
netflix's
and
build
a
charge
combined
into
your
telco
plan.
A
B
A
The
moment
yeah
telco
is
just
charging
data.
It
should
be
in
that
micro
payment
space
working
with
these
over
the
top,
and
I
I
completely
agree
with
you,
because
you
know
telco
keep
their
their
their
stuff
in
their
their
silos
in
their
bunkers.
It's
their
machines
and
you've
been
nowhere.
You
can't
get
anywhere
near
it
right.
A
third
party
cannot
get
the
apis
into
that
telco
space.
A
This,
however
cloud
native,
I
mean
there
is
a
network
exposure
elements
in
the
5g
core
that
can
be
used
to
open
up
to
third
parties
like
what's
happening
over
the
top,
and
we
can
do
that
with
charging
as
well
yeah.
Absolutely
that's
what
we're
doing
right
in
this
room.
Yeah,
it
shouldn't
be
just
telco
people.
It
should
be
those
guys
as
well.
B
Yeah
yeah
because
I
mean
they've
got
no
more,
let's
say
horses
anymore,
be
on
the
sim
card,
the
plat
piece
of
plastic,
the
plan
and
everything
yeah.
If
they
know
that
you
can
enable
developers
through
building
on
cloud
native
technologies
and
that
becomes
an
offering
a
technical
offering,
then
they
will
pull
the
network
people
into
saying
hey.
We
need
this,
you
know,
and
so
the
monetization
I'm
talking
about
you
know.
A
Yeah
yeah
yeah,
you
know
yeah,
I
totally
totally
agree
monetization
of
telco
and
monetization.
Everything
else
is
too
separate:
yeah
because
the
the
telcos
don't
give
access
to
these
other
third
parties
to
use
those
monetization
systems
yeah
right
now.
What
you
want
is
a
kind
of
apple
relationship
right.
What
apple
provides
the
third
parties
with
the
charging
platform
yeah
and
telco-
should
do
that.
B
Too
yeah
but
but
anyways
you
know
just
to
wrap
up
like
I'd
love.
If
there's
some
critical
conversation
with
you
know
the
group
that
cncf
has
kind
of
developed
in
this
cloud
and
everything
because
what's
missing,
there
is
the
developer
and
the
developer
that
has
that
relationship
with
the
consumer.
You
know
which
is
kind
of
eaten
away
from
the
operators,
because
right
now,
operators
just
have
infrastructure
in
the
brand
and
that's
it
yeah
they're,
just
the
pipes
which
are
getting
cannibalized
but
are
not
monetizing.
On
top
of
that
cannibalization
you
know,
and
I'm
wondering.
A
B
A
Mean
I've
been
in
telco
28
years
right
and
I've
been
in
research
in
r
d
and
everybody
comes
up
with
these
services,
but
nobody
thinks
how
do
I
monetize
that
service?
Yes,
if
we
had
monetization
at
the
beginning
of
the
process
and
give
the
developer
the
access
to
the
monetization
platform
while
they
build
their
service,
that
would
happen.
Yeah
yeah,
true,
but
we
don't
have
the
we
just
don't
have
the
structure
or
the
apis
to
be
able
to
do
that.
Yeah.
B
B
A
B
And
that's
what
I
just
wanted
to
so
that's
the
thing.
If,
if
we
enable
the
gsma,
for
example,
to
take
ownership
on
this,
then
we
will
be
willing
to
kind
of
let's
say
to
telco
on
boarding
on
this.
You
know,
because
so
but
yeah
thanks
very
much
for
opening,
I
don't
know
longer,
but
if
anyone
wants
to
continue
the
conversation
more
than
happy
to
share
my
views
on
it,
yeah.