►
From YouTube: CNCF Reference Architecture Meeting - 2019-01-09
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
A
B
A
Are
largely
shouting
about
the
landscape,
but
other
related
kind
of
topics
as
well,
unfortunately
looks
like
10:00
has
not
been
able
to
join
yet
for
the
agenda
we
have
a
name,
it
is
from.
Verizon
is
going
to
tell
us
a
little
bit
about
some
of
their
architecture
work,
but
just
before
that,
I
did
want
to
give
the
overview
about
where
the
cloud
native
landscape
stands
and
I
want
to
introduce
I
know
looks
like
he
dropped
off,
though
there
is
Andre
to
the
to
the
group.
A
Andre
is
our
developer
contractor
in
Spain
former,
until
among
that
you'll
go
in
in
Russia,
who
has
done
the
vast
majority
of
all
the
coding
for
the
interactive
landscape,
and
so,
if
you
find
it
useful
or
have
ideas
on
how
to
make
it
better
or
such
he.
Some
who
want
to
thank
and
the
one
to
make
suggestions
to.
He
and
I
have
been
pretty
busy
over
the
last
over
the
holidays
and
the
last
month
in
refactoring.
The
application
to
be
an
upstream
NPM
module
and
I
had
included
links
to
this
in
the
email.
A
Don't
know
that
there's
a
lot
of
other
updates
that
we
have
I
mean
you're
very
welcome
to
bribe
to
the
feed
of
commit
changes,
and
you
can
see
every
single
change
that's
made.
We
are
making
several
different
changes
per
week
as
projects
come
in
or
companies
go
under,
or
projects
disappear
or
supplement
getting
committed
to,
and
so
there's
been
a
pretty
nice
pace
of
changes
and
updates.
A
The
one
other
comment
that
I
would
just
maybe
bring
up
to
this
group
per
second,
is
someone
I
forget
who
open
the
issue
mentioned
that
the
application
definition
an
image
build
section,
has
a
lot
of
very
different
stuff
in
it
and
I
thoroughly
agree
with
that,
and
it
does
remind
me
a
little
bit
of
what
previously
was
the
service
management
section,
which
we
then
were
able
to
successfully
pry
apart
into
the
remote
procedure,
call
service
proxy
API
gateway
and
service
match.
A
But
when
I
look
at
this
application
definition
and
image
build,
it's
not
instantly
clear
to
me,
which
of
these
are,
which
and
that's
splitting
it
trying
to
come
to
sub
things,
and
they
don't
have
to
be
exactly
those
to
how
we
would
go
about
doing
that.
So
let
me
maybe
call
on
Lee
for
a
second
or
Randy,
where
I'm
curious,
if
either
of
you
two
have
a
view
on
that
section
in
particular,
and
idea
on
how
we
might
clean
it
up
clean
it
up
a
little
bit
or
segmented
out.
C
C
Look
at
the
landscape
that
I
filter
on
definition
and
development,
okay,
yeah
now
I
know,
I,
see
my
high-level
filtered
and
and
and
the
the
three
projects
that
came
back
or
the
test
Nats
and
how
and
yeah
it's
it's.
Maybe
the
test
that
it's,
maybe
the
database
portion
of
this,
that
it's
the
cute
little
bit
forest,
which
is
I,
think,
is
what
you're
already
identifying
them
and
hey
what
you
know
is
there.
Is
there
a
pretty
existing
bucket
that
it
may
be
more
appropriately
fits
into.
A
A
A
So
see,
we've
now
made
the
form
the
static
landscape
totally
interactive
here,
so
it's
in
and
if
you
want
to
dive
in,
you
can
then
click
the
header
that
says
application
definition,
image
build
yeah
and
that'll
show
you
that
there
are
21
projects
in
this
space
and
I
mean
there's
a
lot
of
variety
between
helm
and
Packer.
Yeah.
C
A
Telepresence
and
opus
service
broker
API
and
open
API
initiative.
I
mean
the
open,
API,
so
I'm
definitely
not
trained
it.
So
my
concern
here
is:
oh,
these
are
kind
of
a
lot
of
different
things,
but
the
Oh
are
there
two
subcategories
that
we
could
easily
split
them
into.
It
hasn't
been
clear
to
me
yet
yeah.
C
Yes,
yeah
between
habitats,
well,
Cubert
mini
cube,
yeah
yeah,
because
some
of
these
are
just
some
of
these
are
just
definitions,
and
some
of
these
are
like
habitat
in
particular
uses
is
its
own
I.
Don't
know
if
you'd
say
run,
you
wouldn't
necessarily
say
runtime,
but
it
is
at
they.
It
isn't
ongoing
and
cube
verges
being
at
a
really
doing
API
I.
B
D
You
know
it.
It
gets
into
the
some
of
this
stuff,
some
of
the
stuff
to
sort
of
has
a
little
bit
of
a
crossover
with
configuration
management.
So
you
know
you
got
that
in
there
you
got
kind
of
Bosch,
the
kind
of
a
flavor
to
some
of
those
things,
and
you
know
I
wouldn't
like
at
first
blush.
It
wouldn't
have
any
obvious
like
oh,
that
that
just
shouldn't
be
there
or
this
is
a
bad
structure,
so
I
don't
think,
there's
any
you
know
critical
flaw.
Could
is
there
a
better
way
to
organize
stuff?
D
A
E
As
the
person
who
got
this
is
juicy
so
as
the
person
who
got
habitat
on
this
back
when
I
worked
at
chef,
the
challenge
that
we
had
was:
yes,
it
does
more
than
just
application
definition,
and
so
there
is
a
lot
of
day
to
components,
but
we
ran
into
the
locker
of
we
need
to
be
in
one
box,
so
I
mean
I.
Think
that's
just
the
thing
that
we're
gonna
continue
to
suffer
with
on
the
landscape.
E
E
A
E
But
I
think
to
your
plumb
like
having
this
NPM
module
gives
us
the
capability
to
go
back
and
there's
no
reason
why
we
couldn't
blow
up
application
definition,
an
image
build
into
subcategories
and
then
talk
about
which
one
each
one
does
what
each
tool
does
within
that
broader
scope
right.
Yes,
please!
So
if
you
could
drill
down
into
application
definition
and
image
build
and
then
inside
of
that,
you
have
sub
sub
categories
right.
A
Looks
like
Ken
just
joined
okay,
we
were
just
before
we
went
over
the
moment.
We
were
just
talking
about
application
and
definition,
image,
builders,
maybe
being
the
widest
category
or
the
most
expansive
category
that
we
have
on
here
right
now
and
recent
you're
looking
around.
Would
you
mind
just
popping
up
the
bell?
Fdl
link
that
I
shared
a
minute
ago
in
the
chat
window,
landscape,
dot,
no
FDL
dot,
IO
yeah,
it's
in
the
chat
window.
A
If
you
wanna
or
I,
don't
know
he
said
yeah
there
you
go,
and
so
this
is
just
a
obviously
totally
different
space
and
we
don't
need
to
spend
a
time
on
it
and
I'm
not
gonna,
try
and
defend
the
exact
category
choices
and
such
but
I
do
think
it's
pretty
cool
that
the
all
the
underlying
code
was
able
to
be
he's
continually
able
to
be
used
between
it
and
literally
the
only
difference
on
this
downstream
project.
You
can
click
on
any
of
the
boxes.
A
There
is
that
it's
has
a
different
llamo
file
for
the
landscape
and
different
images
loaded
in,
but
otherwise
everything
works
exactly
the
same
way.
A
D
A
Why
don't
you
go
ahead,
we'll
see
how
we
can
just
rewrite
the
whole
thing
in
the
next
career
form
is
fitting
that
we
can
mainly.
D
There
we
go
so
I'm
ready
yeah,
so
one
of
the
things
that
you
see
here
in
orchestration
and
management
in
that
layer
is
you've,
got
you've,
got
the
RPC
stuff
down
there
and
to
me
that
is
really
an
application
development
component
right.
If
I'm
designing
a
distributed,
application
I
might
decide
to
use
G,
RPC
or
Apache
thrift.
I.
D
D
These
are
these
are
communications
schemes
for
your
micro
services
and,
while
you
know
I
like
the
bucket
RPC
I,
think
that's
a
really
important
bucket
and
people
should
recognize
that
bucket.
It's
very
to
me
parallel
to
the
type
of
use
case
and
decision
process
and
kind
of
component
tree
that
you
would
have
for
messaging
the
two.
The
two
ways
that
you
know
you
you're
gonna,
have
your
micro
services.
Interacting
are
going
to
be.
D
You
know,
request
response
style
like
rest
and
RPC,
and
then
you
know
more
async
messaging
types
of
solutions
which
you
know
are
different
kind
because
most
of
the
messaging
systems
don't
involve.
You
know
the
client
talking
directly
the
server
there's
some
platform
components.
So
you
have
you
know
your
Kafka
brokers
or
your
Nats
brokers
or
what
have
you,
but
in
an
RPC
scenario,
you
know
they're
talking
directly
but
you're,
it's
more
the
technology
that
you're
selecting
for
that
interoperability
and
the
you
know
the
library
and
IDL
generation
stuff.
D
So
that's
one
thought
and
then
inside
the
RPC
I
would
I
don't
know
if
there's
anybody
who's
promoting
Avro
as
an
RPC
solution,
if
there
is,
would
love
to
chat
more
with
them
about
that,
but
being
an
RPC
buff
a
bit
every
time,
I've
looked
at
Avro
as
a
realistic
way
to
do
our
see.
I
have
found
it
to
not
that's
not
each
stick,
in
other
words,
I.
You
know
afros
great
for
serializing
data
to
disk
where
you
want
to
have
a
schema
embedded
with
the
data
so
that
you
can.
D
You
know
retrieve
it
many
years
later
without
having
to
remember
what
the
old
schema
was.
It's
it's
really
awesome
for
that,
but
that
approach
hasn't
worked
out
well
for
our
PC
and
a
lot
of
times
the
r2p
see
stuff
that
they
show
on
their
website
doesn't
actually
even
work.
It's
not
maintained
from
what
I
can
tell
so
I
I
would
say
that
pointing
someone
at
Avro
for
RPC
is
almost
you
know.
A
A
Yeah
I
mean
you
still
can
yeah
I
mean
that
my
issue
on
it
is
just
we
paste
it
in
we're.
Avro
does
claim
to
be
an
RPC,
but
to
be
a
to
not
fit
to
also
offer
RPC
I
totally
believe
you
that
they
don't
do
a
good
job
at
it
or,
but
it's
not
well
maintained
or
such,
but
it
just.
It
is
right
there
that
they're,
not
just
rich
data
structures
and
a
compact
fast
binary
format,
but
they
also
are
overlooked.
Teacher
call
so
in
that
sense
they
claim
to
be
wall.
D
Although
you
know,
if
you
look
at
the
print
above
website
before
GRP,
see
that
there
were
all
sorts
of
pointers
to
how
you
could
quickly
do
our
pc
with
it-
and
I
guess
you
know
if
you
wanted
I-
would
be
interesting
to
get
some
feedback
from
people
from
the
Avro
project.
If,
if
they
really
felt
like
it
was
a
good
idea
to
offer
Avro
out
as
an
RPC
solution,
because
I
really
really
yeah
and
I,
don't
don't
think
anybody's.
Actually.
A
Wanted
to
do
ray
and
an
email
exchange
with
folks
there
I
I
mean
I'm
very
happy
to
remove
them.
A
D
To
have
them
in
there
then
you're,
then
you're
kind
of
you
know
addressing
the
fact
that
they
are
great
for
serialization,
and
if
you
wanted
to
build
your
own
RPC
stage
scheme
or
try
to
make
the
one
that
they
show
work,
you
could
and
then
protobuf
would
be
kind
of
a
lot
more
of
a
you
know
a
center.
You
know
related
kind
of
a
project,
but
if
it
feels
like
we
should
have
been
there
somewhere,
I
don't
know.
I.
A
A
I
yeah
I
mean
I
think
the
reason
is
here
is
more
the
management
than
the
orchestration
and
then
just
the
belief
that
the
RPC
is
often
a
building
block
for
streaming
and
messaging,
even
though
it
can
be
a
direct
competitor
to
it,
but
I'm
curious.
If
anybody
else
wants
to
voice
an
opinion
on
the
topic,
I
mean
I.
Don't
disagree
with
you,
though,
that
RPC
cannon
is
also
used
for
app
definition
and
development
differently.
C
Like
the
notion
that,
like
part
of
what
Dan
just
said
that
resonates
with
me,
a
bit
is
that
is
the
notion
of
these
layerings
is
the
notion
of
you
know:
Hardware
him
potentially
Hardware
things
potentially
here
our
image,
the
notion
that
somebody's
get
layered
and
layered
on,
and
so
it's
good
to
take
in
their
context.
Yeah.
D
It
makes
me
absolutely
completely
it.
You
know
no
dependency
on
the
underlying
orchestration
and
development
platform.
I
could
run
that
same
app
on
docker
swarm
with
compose
or
in
nazo
soar
on
kubernetes
or
on
bare
metal,
and
yet
it's
using
RPC.
It's
a
it's
an
application
development
tool.
If
I'm,
if
my
application
that
I'm
developing
is
kubernetes
and
I
happen
to
choose
G
RPC
that
that's
fine,
but
now
you're
you're,
you're
sort
of
shifting
you're,
you
know
it's
an
orthogonal
vector
right.
What
you're
saying
my
app
is
the
orchestration
platform
so
I
get
it
G.
D
Rpc
is
important
to
people
who
build
distributed
application
platforms
because
those
are
essentially
micro,
service
applications
too,
but
it's
an
app
development
tool.
You
know
it's
not
it's
not
a
platform,
orchestration
thing
and
and
well
yeah.
You
should
be
able
to
instrument
all
calls
between
multiple
applications.
I
should
be
able
to
see
messages
flowing
from
a
paid
app
be
over
nets.
I
should
just
as
equally
easily
be
able
to
see
messages
flowing
over
to
your
PC
or
thrift
between
app
a
and
a
fee.
That's
you
know
that
object.
D
That
observability
is
a
cross-cutting
concern
and
that's
why
it's
in
the
tower
on
the
right,
so
that
that's
how
this
stuff
comes
to
me
right.
If
I'm,
an
app
developer,
I,
don't
care
about
the
platform.
I'm
gonna
consider
my
RPC
solution.
It's
gonna
be
an
important
part
of
my
decision-making
process
and
it's
going
to
be
one
that
I
make
very
carefully
because,
unlike
the
innards
of
my
micro
servers,
that
I
can
turn
over
50
times
without
affecting
anybody
else,
we're
talking
about
the
contract
between
systems
in
my
or
between
micro
services.
C
Mm-Hmm
yeah
interesting
to
reflect
also
on
the
the
constituency
of
the
other
groups
within
the
orchestration
and
management
layer
and
how
infrastructurally
those
feel
as
versus
Randy
I,
think
the
thing
you're
sort
of
highlighting
is
being
a
bit
more
developer.
Centric
concerned.
You
know
maybe
another
way
of
characterizing
things
and
looking
at
it
through
a
different
lens
is
you
know,
who's
the
core
persona
that
is
maybe
has
a
higher
degree
of
concern
for
that
layer
to
reflect
on
it.
So
Randy
you're
saying
this
is
pretty
developer
centric.
Those
absolutely.
C
D
And
and
one
of
the
great
things
about
service
mesh,
you
know
projects
like
on
boy
and
what-have-you.
Is
they
let
you
monitor
all
of
the
traffic
between
all
of
these
systems?
That's
their
job
and
the
observability
projects,
like
you,
know,
open
tracing.
Those
guys
are
the
plugins.
It
just
really
speaks
to
the
point
that
operators
don't
want
to
have
to
care
about
what
the
developers
have
chosen
to
use
right.
You
could
be
using
the
my
sequel
protocol,
but
on
the
backend
it
could
be
the
test.
It
could
be
actually
my
sequel,
it
could
be.
D
You
know
Maria,
DB
or
any
number
of
other
auroral
something
else,
but
the
the
hooks
that,
let
you
view
this
stuff.
You
know
they
need
to
know
about
those
things.
But
clearly
my
sequel
is
an
application
developer
a-level
construct.
It's
not
it's
not
like
those
things
are
independent.
It
should
be
completely
firewalled
off,
though
the
more
they
are,
the
nicer
it
is
for
the
operators
and
that's
what
you
know.
Tools
like
on
boy
bring
to
the
table
on
glue.
Yes,
does
let
you,
you
know,
gets
an
extra
juice
from
a
G,
RPC
interaction.
D
Then
it
would
over
something
else,
but
that
sort
of
just
goes
back
to
the
protocol.
Http,
you
know
being
mined
for
data.
You
can
do
the
same
thing
with
with
other
schemes.
Of
course,
if
you
have
you
know,
if
you
have
the
protobuf
specs
for
your,
you
know,
exchanges
that
are
protobuf
based,
even
if
their
messaging
oriented
you
know
your
your
instrumentation
can
decompose
those
and
grab
stuff
out
of
them.
D
So
you
know
there's
never
going
to
be
complete
independence,
but
when
it
comes
to
the
the
development
process
and
the
kinds
of
things
you
need,
you
need
to
pick
an
RPC
solution.
You
want
to
build
one
from
scratch,
so
you
need
to
pick
a
messaging
solution.
You
need
to
pick
a
you
know,
storage
solution
and
all
of
those
things.
D
A
Yeah,
it's
all,
but
it's
only
good
people
are
working
to
improve
it.
I
mean
that
the
fundamental
biggie
here
is
that
RPC
is
a
different
category.
That's
streaming
messaging
I,
don't
think.
That's
always
true
and
I
do
think.
G
RPC
is
very
much
used
as
a
streaming
solution
at
times
and
and
some
sometimes
NASA
G
RPC
are
directly
competitive
with
each
other.
So
I
do
see
the
argument
for
that
being
up
on
the
application
layer.
A
D
Yeah
parallel
there
in
that
in
the
OpenStack
world,
RabbitMQ
at
least
for
a
while,
was
the
way
that
all
of
the
services
talk
to
each
other.
So
you
know
you'd
have
to
put
streaming
and
messaging
down
in
the
platform
layer,
I
guess.
The
main
thing
to
me
is
that
there
are
some
fundamental
things
that
you
do
when
you're
building
a
micro
service
solution
and
one
of
those
fundamental
things
is
you
pick
an
async
messaging
solution
and
the
other
one?
D
Is
you
pick
a
request
response
scheme
which
might
be
rest
or
G
RPC
or
a
combination,
or
something
like
that?
But
those
are
so
parallel
and
to
your
point:
you
can
implement
messaging
on
our
PC
and
you
can
implement
RPC
on
messaging.
You
know
you
can
really
make
RPC
requests
over
Nats
if
you
want
to
so
there
they're
similar,
but
but
they
have
some.
D
You
know
if
you're
gonna
do
messaging,
you
sort
of
take
certain
fundamental
decisions
and
and
go
that
route,
and
then
you
you
you,
you
can
do
the
RPC
stuff
but
you're
a
little
less
efficient
at
it,
or
it's
a
little
bit
more
work
for
the
developers
and
then
flip-flop
for
the
other
side.
But
they're.
You
know
fundamentally
targeted
lead
if
uhrin
technologies
and
different
schemes
for
interaction,
but
they
operate
I.
Think
really
clearly
to
me
at
the
same
level.
A
D
A
F
My
name
is
Mehmet
OE,
with
Verizon
and
I'm,
really
very
new
to
the
group
and
the
first
thing
before
I
start
this
he's
there
a
document
or
is
there
a
link
that
you
can
send
me
about
the
current
status
of
the
or
where's
the
architecture
that
you
are
working
with
and
what
architecture
is
working
with
and
also
the
status
of
the
development
that
will
help
them
quite
a
bit.
So
far,
these
I
haven't
gotten
much
information
about
the
group.
F
So
what
I
am
going
to
present
is
certainly
very
high
level,
but
you're
going
to
see
the
connection
to
the
to
the
containers
and
what
I'm
as
a
service
provider.
What
I
am
really
looking
for
at
this
point
so
for
that
is
I
need
to
give
you
the
call
service
architecture
concept,
described
it
and
then
tied
it
to
the
containers.
F
F
So,
if
I
look
at
the
applications,
probably
most
of
the
applications
are
larger,
ritualized
or
software
written
in
software,
but
in
the
networking
you
will
have
non-motorized
component
on
top
of
so
I,
basically
put
all
of
them
like
in
one
chart
to
show
how
they
can
be
related
to
each
other.
Of
course,
it's
not
one
way
to
do
it,
but
may
mostly
hit
the
bottom.
F
You
will
have
a
network
as
a
service,
and
then
you
build
on
top
of
that
infrastructure
platform,
software,
communications,
security
and
maybe
others,
and
as
you
can
see,
either
you
can
build
on
top
of
each
other
or
maybe
you
can
skip.
For
example,
you
can
have
a
platform
as
a
service
on
top
of
the
NASS.
Now
that
doesn't
mean
you're
not
going
to
have
any
infrastructure
components.
You
will
have
it,
but
that
may
not
be
offered
as
a
separate
service.
F
So
if
you
look
at
the
characteristics,
characteristics
is
those
which
are
the
normalized
component
as
I
mentioned,
and
it
could
be
networks,
applications
and
also
the
connections.
Connections,
as
you
will
see,
between
a
service
subscriber
and
the
application
or
between
subscribers,
and
also
the
components
like
vnfs
and
the
PS
can
be
provided
by
one
operator
or
multiple
operators.
Again,
as
you
will
see
in
the
diagrams
and
well,
the
others
may
be
key
characteristics.
F
Is
the
elasticity
elasticity
in
terms
of
the
on
demand
service
configuration
even
self
configurations
by
the
subscribers,
and
also
the
collaboration
and
scalability?
As
you
know,
scale
in
and
out,
that
is
one
of
the
common
features
that
is
being
expected
and
also
service
level
specification.
So
there
are
some
quality
of
service
associated
with
it
with
the
end-to-end
service
and
maybe
other
parameters,
and
things
like
that.
F
So
there
are
Quattro
service
probability
with
the
service
and
also
the
uses
based
business
meeting,
and
that
is
the
really
depends
on
how
the
service
for
what
is
capable
of
supporting
than
another
word.
You
can
see.
Maybe
only
maybe,
by
minutes,
maybe
even
less
than
so,
depending
on
the
reader
capability,
they
will
have
the
usage
basically.
F
So
this
when
I
give
you
a
couple
examples.
This
is
one
of
the
common
example
that
you
have
a
customers
or
subscribers
using
the
public
internet
and
access
into
the
public
providers
such
as
Amazon,
Google
and
Tim
site,
and
there
is
also
the
private
networks,
the
customers
or
subscribers
do
use
the
private
networks
like
Verizon,
you
use
the
word
eyes
and
private
networks
to
get
to
the
public
cloud
providers
such
as
Amazon
and
also
the
combinations
they
may
use
the
private
networks,
but
also
has
the
backup
they
may
use
the
public.
F
There
is
also
another
variation
over
here.
That
is
the
the
SUBSCRIBE
it
may
go
through
the
private
network
and
they
access
to
the
private
cloud
providers.
Applications
such
as
Verizon
and
that
private
cloud
provider
may
have
actually
a
communications
or
connectivity
to
the
public
or
provided
such
as
Amazon
and
the
end
user
or
the
subscriber
things.
Actually,
they
are
using
the
Amazon's,
the
applications
on
the
Verizon,
but
they
may
actually
use
applications
on
Amazon.
F
Muscle
and
acronyms
so
is
also
the
subscriber
would
like
to
whether
they
go
they
used
public
internet
or
the
private
networks,
but
either
way
they
do
when
I
have
an
access
to
the
multiple
public
cloud
providers
from
the
same
names
and
one
more
is
the
cloud
exchange
gateway.
This
is
the
they
would
like
have
a
gateway
that
can
cloud
carries
called
carries
such
as
Verizon
could
be
counted
as
a
cloud
carrier
or
AT&T
is
a
cloud
carriers.
F
F
So
two
more
examples,
and
one
of
them
is
the
cloud
in
a
box
and
then
is
really
it's
a
customer
premises,
equipment
which
is
providing
the
virtualization
infrastructure,
and
on
top
of
that,
it
may
or
may
not
for
wider
applications.
So
it's
connected
to
the
cloud
service
provided,
as
you
can
see,
which
has
the
cloud
carry
and
also
the
cloud
provide.
F
E
F
Application
that
they
have
and
the
applications
offered
by
the
cloud
forward
and
and
other
simple
examples,
of
course,
the
subscriber
will
come
a
very
simple
device
and
basically
connected
to
the
cloud
carries
and
then
from
there.
Maybe
it's
a
simple
browser
access
to
the
various
cloud
applications.
F
So
with
that,
let
me
describe
this
one
and
then
I'll
stop
if
they
have
any
questions
so
far
and
they're
not
continuing
to
this.
So
this
is
the
describe
this
lag
and
describe
the
cloud
service
actors
and
on
the
left
side
you
see
cloud
service
subscribe
and
on
the
right
side.
Is
the
classes
provide
cloud
service,
provided
is
the
one
responsible
from
everything
really
for
the
service
so
from
the
provisioning
to
the
maintenance
and
plus
the
billing
and
single
point
of
contact
to
the
cluster,
subscribe
that
the
closer's
provider
may
or
may
not
own?
E
F
May
own
may
be
just
called:
carry
portion
old
and
so
on
so
forth.
But
in
summary,
is
you
need
to
have
a
cloud
carry
for
the
connectivity
and
also
you
need
to
cloud
provider
to
support
applications.
Now
you
know,
as
we
had
like
10
minutes
ago,
we
were
talking
about
applications,
so
I'll,
try
to
give
you
a
little
bit
inside
to
what
we
meant
by
the
applications
and
how
that
really
matched
what
you're
saying
that
what
we
have
discussed
companies.
F
F
First
of
all,
the
intent
was
why
we
came
up
with
this
thing
was
really
simplify
the
the
cloud
services
in
such
a
way
that
we
has
a
service
for
that.
We
can
manage
it,
and
also
we
can
hide
the
complexities
from
the
SUBSCRIBE.
That
was
the
main
intention
and,
of
course,
on
top
of
that
is,
can
we
use
the
tools
that
we
already
have
now?
F
That
doesn't
mean
we're
not
going
to
change
if
we
will
change
it,
but
at
least
we
may
end
up
with
the
minimal
changes
if
we
have
an
architecture
that
can
at
least
resembles
to
what
they
had
been
using
so
far,
so
the
key
objectives
are,
as
I
said,
hiding
the
implementation
and
also,
of
course,
allow
subscribers
to
have
sub
configurations
and
also
use
the
other
saw
detective.
What
is
this?
F
The
configuration
needs
to
happen
between
the
operators,
so
that
images
between
the
the
focus
areas
between
the
interfaces
of
two
operators
discordantly
so
and
of
course,
on
top
of
that
is
the
service
one
and
service
or
name,
is
really
half
check,
periodically
subject,
and
also,
maybe
the
loopback
and
those
kind
of
things.
Can
we
also
use
those
if
we
have
an
object
again
somewhat
similar
to
what
we
have
been
used
for
other
ships.
F
A
F
F
So,
of
course
the
there
would
be
some
differences
in
the
attributes,
but
nevertheless
generically.
We
would
like
to
call
that
containers
memories.
So
now
I
mean
the
cloud
application
interface.
So
for
us
is
how
do
we
interface
to
a
containers?
How
does
this
contain
and
talk
to
another
VM,
or
how
does
this
container
talk?
Another
contain?
F
It
is
very
important
and
again,
this
is
what
we're
trying
to
standardize
again,
not
just
for
the
containers,
purple
other
virtual
components,
the
NS
and
things
like
that,
but
nevertheless
we
need
to
really
identify
what
the
senior
phase
or
the
containers.
Now
there
is
one
more
interface
in
the
container
for
the
interface
that
we
are
for
the
container
that
we
are
interested
that
does
not
show
with
these
diversity
sliced
on
show.
That
is
the
interface
between
the
containers
and
economy,
so
that
interface
is
also
important.
F
We
need
to
standardize
that
so
that
we
can
use
the
you
know.
The
container
is
vnfs
from
various
vendors
to
be
able
to
run
on
top
of
the
the
kernel.
So
so
then
the
this
is
basically
operate,
the
interfaces
and
so
on
so
forth
it's
really
same
approach
even
to
operate
interfaces.
We
have
defined
the
application
in
your
face
and
the
connectivity
in
your
face
again
hoping
that
the
if
we
use
a
container
interface
that
will
be
the
that
will
comply
with
application
interface,
that
we
define
hate
for
these
services.
F
Again.
This
is
the
protocol
stack,
which
you
pretty
much
the
same
thing
and
and
then
comes
to
the
connections.
So
connections
is
if
I
ever
end
user.
Here
and
let's
say,
I
have
a
container
oles
or
you
know,
application
on
top
of
the
container,
then,
as
a
subscriber
I
establish
a
connection
is
called
the
cloud
virtual
connection.
C
F
This
connection
will
have
endpoints
collecting
the
cloud
virtual
connection,
endpoint
on
one
side
and
cloud
virtual
connection
endpoint
on
the
other
side.
So
if
this
is,
the
container
container
is
supposed
to
support
it
and
the
connection
can
be
provided
by
multiple
operators,
as
you
can
see,
and
if
test
cased
and
you
can
have
the
segment's
in
each
operator
that
we
treat
them
separately,
maintain
them
separately
as
ohms.
F
And
finally,
maybe
this
is
the
picture.
So
if
I
am
the
subscriber
over
here
and
receiving
the
service
from
cause
of
the
operators,
closer
is
provided
then,
as
you
can
see,
I
have
the
segment's
for
each
clause
operated
and
then
they
are
terminated
by
endpoints
and
same
thing
on
each
operator
and
they
form
the
end-to-end
cloud
virtual
connections,
which
the
services
basics
are
riding
on.
That's
basically
it
I
didn't
gonna
want
to
go
to
further
details,
but
I
stopped
and
I
want
to
hear
your
question.
Thank
you.
E
B
A
Cf
definitely
tends
to
look
at
kubernetes
related
solutions
as
to
trot
as
opposed
to
solutions
that
are
are
kind
of
abstracting
away
to
work
with
any
possible
technology.
So
now
that's
not
a
hard
and
fast
rule.
I
mean
we
search
and
I
guess
there
are
plenty
of
counter
examples
to
it,
but
I'm
curious.
If
you
run
into
the
network
service
mesh
work,
that's
being
led
by
Edward
Nikki
of
Cisco
and
the
project
legato.
F
A
Ok,
so
I
will
make
an
introduction
on
the
mailing
list
to
add
and
encourage
you
to
get
involved
with
that
group
I.
The
legato
I'm
speaking
about
is
on
the
I'm
pasting
this
into
the
zoom
chat
window,
but
it's
a
cloud
native
platform
for
developing
pluggable
Service
agents,
but
it's
essentially
a
format
for
out-of-band
signaling
on
in
kubernetes
to
allow
a
different
kind
of
pod,
networking
more
of
a
layer,
2
pod
networking
for
particularly
higher
performance
kinds
of
kinds
of
interconnects,
and
it's
it's
essentially
a
way
of
doing
carrier-grade.
A
Networking
that
is
implemented,
intranet
ease
is
a
custom
resource
definition
of
CRD
and
so
doesn't
interfere
with
all
the
ways
that
networking
works
today.
So
I
definitely
would
encourage
you
to
look
at
their
work
and
I
believe
they're
out
doing
weekly
calls
and
are
quite
engaged
on
it
and
I
think
that
might
be
a
good
group
to
try
and
engage
with.
But
maybe
you
could
just
talk
a
little
bit
about
one
of
the
outcomes
that
you
are
looking
for
here.
This
is.
F
E
F
This
so,
first
of
all,
I
appreciate
for
all
these
and
I
certainly
get
connected
to
Cisco
team
as
well.
What
my
intent
was
over
here
I
wanted
to
see
if
you
are
being
able
to
define
the
interface
to
the
containers,
is
there
a
way
for
us
to
standardize
that
that's
one?
Second
is
the
so
interface
between
the
containers,
interface
between
the
from
the
containers
to
a
kernel,
as
I
mentioned,
and
from
the
management
perspective.
We
are
not
clearly
tied
into
the
kubernetes,
it
could
be
kubernetes,
it
could
be
something
else.
F
A
A
So
I
would
really
encourage
you
to
go
out
and
work
with
Edie
and
that
in
that
activity
for
the
next
few
weeks
and
then,
as
you
kind
of
get
a
better
lay
the
land
of
the
container
world
to,
please
feel
free
to
sort
of
circle
back,
and
maybe
we
can
also
just
do
an
offline
call
to
talk
about
some
of
these
issues.
Acting.