►
From YouTube: Layer5 Community Meeting (Dec 18th, 2020)
Description
A review of the Open Application Model @oam_dev from @ryanzhang_oss of @alibaba_cloud.
A
C
A
A
A
A
A
A
Okay,
fair
enough
josh,
it's
nice
or
not,
josh
ryan
nice.
To
have
you
with
us
ryan.
Do
you
wanna,
there's
a
tradition
here,
anyone
who's
on
one
of
the
calls
for
the
first
time
they
get
to
introduce
themselves
and
you're
gonna
do
that
anyway.
But
do
you
want
to
give
a
brief
introduction
and
then
maybe
we'll
sort
of
roll
into
talking
about
oam
sure.
B
Definitely
so
hi
everyone,
I'm
ryan,
and
so
I
I'm
in
the
past
year
I've
been
working
on
the
project
called
oem,
which
is
loosely
speaking.
It's
application,
layer,
definition
or
abstraction
standard
that
we
are
working
on
on
top
of
kubernetes
and
its
goal
is
actually
more
than
kubernetes,
but
most
of
the
implementations
now
are
under
kubernetes
and
I've
been
working
in.
So
I'm
working,
alibaba
and
I've
been
working
alibaba
cloud
for
the
last
about
four
years,
and
before
that
I
was,
I
was
in
twitter.
B
So
it's
like
it's.
I
I
heard
of
layer
five.
I
accidentally
bumped
into
lee
with
a
google
student,
something
like
that
and
he
was
really
accommodating
me
as
a
mentor
which
I
would
but
I
didn't
really
take
advantage
of
that
chance.
So
it's
it's
exciting
to
to
come
to
learn
what
what's
going
on
in
the
in
the
mastery
world
and
see
if
there
are
any
collaborations
that
we
can
we
can
for.
We
can
forge
after
this
call
nice.
A
Ryan,
I'm
excited
about
this.
I'm
both
yeah,
I
guess
for
more
reasons
than
I
was
thinking
of
one
is
potential
collaborations.
I
think
that
there's
a
lot
of
merit
to
the
the
vision
and
the
goals
of
oem,
but
then
yeah
also
what
we
just
one
of
our
well
we've
got.
I'm
not
sure
we've
got
somewhere
north
of
five,
but
less
than
ten
interns
happening.
Right
now
are
internships,
which
is
to
say
there
if
that
continues.
B
A
You
know
as
much
as
you
we,
the
the
other.
We
can
there's
so
much
going
on
in
this
community,
that
we
can
talk
about
it'll.
Take
us
two
hours
to
cover
the
we're,
not
gonna
cover
all
the
rest,
so
that
that's
that's
fine,
so
take
as
much
as
as
much
as
it
takes
to
do
a
complete.
You
know
complete
picture
because
okay.
B
B
B
A
A
Some
of
you
have
spent
some
time
around
service
mesh
performance
around
smp
that
specification.
It
identif
it
characterizes
how
to
track
how
to
how
to
track
the
performance
of
a
service
mesh
and-
and
it's
made
up
of
it's
it's
a
specification.
So
it's
just
proto
files
or
it's
protobuf
files
or
it's
yaml.
If
you
will
and
as
part
of
describing
how
well
the
service
mesh
is
performing.
Well,
that's
dependent
upon
what
workloads
you're
running.
What
applications
are
you
running
on
the
mesh?
A
B
E
B
So
this
talk
is
mostly
about
running
the
next
generation
of
cloud
native
applications.
This
is
our
kind
of
our
goal
of
the
open
application
model.
I
guess
along
that
line,
should
align
with
the
layer.
Five,
that's
for
the
for
the
future
generation,
and
the
next
slide
is
so.
This
is
for
I'm
I'm
not
100
sure.
If,
if
layer
5
works
mostly
on
kubernetes
or
it
only,
it
also
works
on
different
runtimes.
B
B
A
It
is
a
question
yeah,
it
is.
Oh,
you
know
it
heavily
focused
on
heavily
focused
on
kubernetes,
because,
because
of
such
a
focus
for
us
on
service
mesh
and
that's
where
most
folks
will
start
their
service
mesh
journey
understanding
that
there
are
many
many
you
know
most
of
the
world's
workloads
are
outside
of
kubernetes
at
the
moment.
But
so
anyway,
we
start
there,
but
the
intention
is
to
focus
on
vms
and
workloads
outside
of
kubernetes.
Oh.
B
B
Stateful
set
demands
that
these
things,
those
are
not
applications
for
from
anyone
who
has
written
applications
and
but
unfortunately,
in
our
community,
like
the
the
so-called
cloud
native
community,
you
can
see
pretty
much
people
take
deployment
as
applications.
Recently,
we've
seen
a
whole
bunch
of
so-called
platforms.
Application
platforms,
like
I
don't
know,
if
you've
heard
of
that,
like
there's
waypoint,
there's
shipa
there,
there
is
rio
when
looking
to
that
it
pretty
much.
B
Everybody
say
when
they
say:
allow
you
to
run
application,
it's
a
deployment,
but
that
that's
not
not
the
end
of
the
story
and
from
the
from
the
developers
point
of
view.
We
want
micro
services.
We
we
want
to
run
rpcs
all
these
things.
It's
it's
not
clearly
reflected
in
the
in
the
kubernetes
world.
It's
just
the
nature
of
this
slide,
and
so
current
solution
is
just
like.
As
I
mentioned
people,
because
it's
kubernetes
is
so
developer
and
friendly.
B
They
we
built
many
teams,
individual
independent
teams
or
some
platform,
so
called
platform
teams
in
big
companies
or
medium
companies.
They
build
their
own
platforms
to
serve
their
developers,
that's
a
very
common
pattern,
so
they
they
build
this
thing
layer
of.
Can
you
see
my
mouse
or
cursor
right?
They.
B
Thing
layer
of
application
platform,
which
kind
of
recorded
past
loosely
past
that
expose
different,
like
really
developer,
friendly
concepts
outside
and
from
the
dev
side.
There's
like
from
source
to
image,
see
I
see
these
from
operation
inside
there's
capacity,
management,
rollout,
logging,
all
these
things.
These
are
like
pretty
much.
If
you
look
at
five
six
different
platforms
that
it's
pretty
common
there
and
it
mostly
works
like
otherwise
they
will
not
have
those
products
and
the
user
experience.
B
B
Basically,
if
you
look
at
most
of
them-
and
we
know
that
in
the
in
the
kubernetes
world
and
and
the
cloud
native
ecosystem,
where
you
put
up
put
it
in
a
more
marketing
world,
it's
it
has
way
more
capacities
and
it
it.
The
ecosystem
is
huge.
You
pretty
much.
Every
day
you
hear
different
projects
come
up
and
and
and
new
things
come
up.
So
how
do
you?
How
does
the
platform
build
building
team?
Try
to
incorporate
that
without
having
to
rewrite
their
systems,
basically
don't
log
into
their
existing
apis?
B
So
this
is
kind
of
our
our
goal.
So
so
we
have
this
application
model
so
that
it's
a
it's
standard
so
that
it
can
allow
application
builders
to
the
so
they're,
actually,
two
parts.
The
one
part
is
this
is
allow
platform
builders
to
build
developer,
friendly
application
platforms,
but
also
very
extensible.
B
So
in
the
sense
that
it's
not
tied
up,
I
will
show
that
that's
where
the
demo
comes.
It
will
show
how
how
does
how
do
we
make
it
work
that,
instead
of
having
a
locking
api
proprietary
api,
we
give
you
a
very
extensible
platform
that
pretty
much
you
can
incorporate
anything.
That's
why
I
think
the
the
layer,
5
or
any
mesh
mesh
service
would
work
here,
because
we
are
very
extensible.
It
should
be
really
easy
to
incorporate
that.
B
So
it's
it's
a
design
for
platform
builders,
I
mean
one
part:
it
is
the
another
part.
Is
we
actually
also
realized
that
we
want
to
have
a
more
developer
facing
part?
So
so
let
me
just
focus
on
platform
builder
first
here.
So
we
have
our
the
the
it's
great
for
the
platform
builders.
It's
allowed
platform
builders
to
build
a
framework
that
allows
them
to
bring
their
own
workloads.
That's
the
key
that,
for
example,
you
can
bring
in
your
own.
B
I
know
you've
heard
of
that
in
the
you
can
bring
your
own
workload
in
the
sense
that
you
can
put
a
service
just
very
really,
really
really
basic
ones.
You
can
put
a
service
and
deployment
together
and
make
it
a
micro
service
so
that
your
application
would
automatically
have
this
service
and
also
you
can
put
in
ingress.
You
can
do
the
basic
plugin,
plugin
and
play
and
kind
of
encapsulate
that
into
your
own
workloads.
B
You
can
define
each
workload's
own
characteristics
and
the
capabilities,
and
by
doing
that,
you
all
you
need
is
basically
get
all
the
I
put
in
a
real
technical
term.
I
mean
that
yeah,
it's
like
controllers.
You
can
group
a
few
controllers
together
and
expose
them
without
writing
any
code
and
make
them
a
workload,
and
also
another
thing
is
most
of
the
application
platforms.
Currently,
I've
seen
don't
really
focus
on
the
or
pretty
much
ignore
the
operator
operation.
B
No
traits
of
the
workload
say
you
have
to
expand.
You
have
to
you
have
to
do
metrics
you
have
to
roll
out
upgrade.
Those
are
not
really
reflected
in
the
system.
Yet
in
our
system
we
have
it's.
It's
called
trade
systems,
I'm
not
sure.
If
the
trade,
this
this
word
is
intuitive
enough,
but
you
can
think
of
it
at
basically
two
operations.
So
it's
not
just
the
application
you
deploy,
that
you
have
a
data
operation
characteristics
like
that
you
can
describe
so
you
can
put
on
a
law.
You
can
put
on
hpa.
B
You
can
put
on
a
routing
like
which,
which
way
the
http
to
service
routings.
So
that's
what
what
we
think
is
we're
still
trying
to
get
the
balance
between
the
extensibility
and
abstraction.
That's
why
it's
in
still
working
progress,
yeah,
that's
about
it
and
and
eventually
this
is
really
a
very
the
reason,
because
we
have
this
trade
system.
That
makes
it
a
lot
easier
to
build
a
so-called
serverless
platform,
because
basically
the
server
part
is
the
operations.
B
So
without
any
manual
interaction
with
the
server,
you
basically
can
make
it
very
easily
a
serverless
platform,
because
all
the
operations
are
described
in
a
trade
system.
So
in
an
ideal
world
all
you
need
is
just
apply
a
trait
and
all
the
operations
are
done
for
you
any
questions,
I
think
I
kind
of
I
covered
a
lot
of
ground
in
a
relatively
short
period
of
time,
and
if
any
of
you
have
any
questions,
don't
don't
hesitate
to
interrupt
me.
I'm
really
happy
to
explain
things.
Thank
you.
A
Ryan,
a
couple
I'll
toss
in
right
now,
which
is
the
paz
serverless
platform
that
that
aspect
I
I
probably
miss
I
miss,
I
probably
missed
what
you
were
just
saying
are
you
care?
Is
that
characterizing
oam,
as
as
four
teams
that
are
doing
serverless
things,
or
is
that
characterizing
oam
as
being
taking
on
characteristics
of
being
being
somewhat
serverless
itself?.
B
B
So
with
the
any
platforms
that
takes
on
this
abstraction
or
standard,
it
will
be
very
easy
to
build
a
system
that
is
a
serverless
platform.
So
oem
itself
is
not
any
implementation,
it's
just
a
standard,
but
it's
anybody.
Any
platform
builder
that
adopt
this
standard
will
make
them
very
easy
to
build
serverless
platform,
build
platforms
that
are
extensible
and
still
with
the
good
amount
of
abstraction
that
that's
that's
our
goal
and
and
to
make
it
clear.
B
We
built
our
own
platform
based
on
om
to
to
demonstrate
how
easy
it
is
to
build
nice.
Okay,
because
just
talking
about
abstraction
is
not
very
exciting
afterwards.
So
yeah
any
other
questions,
good
question,
yeah
any
other
questions
from
anyone
else
or
the
did.
By
the
way.
Do
you
call
yourself
like
measuring
or
it's
it's.
A
The
other
one,
the
the
layer,
five
so
yeah,
you're
right-
that
layer,
layer
five
is
a
community
of
open
source
contributors
that
have
a
few
different
projects.
Maybe
about
depends
on
how
you
count
them,
but
mesherie
is
the
biggest
project
or
the
longest
living
and
has
gone
on
for
some
time
measuring
itself
because
of
part
of
its
focus.
It
has
produced
or
conceived
a
spec
as
well,
not
complementary
to
oam,
which
is
in
part
like
the
part
of
the
considerations
that
we
might
chat
about
after.
B
B
What
we
would
envision
so
in
the
front,
there's
there's
this
ui
ui
ui
part
that
this
is
the
basically
the
real
developer
facing
part,
and
we
don't
actually
have
any
specs
on
that.
So
you
can
see
the
the
I
think
the
orange
part
are
the
ones
that
that's
not
part
of
really
part
of
the
om
spec.
So
this
is.
This
is
part
that
you
can.
B
You
know
it's
depend
platform
dependency
dependent,
but
in
in
in
the
center
the
the
core
part
is
this
oem
runtime
this
this
runtime
would
have
the
controllers.
Basically,
you
have
application
configuration
that
this
is
how
we
describe
an
application.
This
is
how
we
think
an
application
would
look
like
on
kubernetes
or
any
other
platforms,
and
components
are
basically
the
real
application
individual.
We,
if
you
talk
in
terms
of
microservice,
it's
basically
individual
services
and
the
the
most
interesting
part.
B
Is
this
part
we
have
the
capacity
capability
registry
or
we
call
it
capability,
centers,
that's
where
the
the
power
of
oem
any
any
oem
based
platform
is
that
you
can
register
your
workload
into
those
it's
kind
of
like
you
think
of
that
the
docker
hub,
you
know
any
java
maven
write
all
these
things.
So
if
you
have
have
that
any
platforms,
builders
can
basically
get
their
workload
from
the
registry.
They
can
register
their
own
workload.
They
can
get
regis
workload
from
others.
B
They
can
get
trade
from
from
the
standard
hub,
basically,
and
then
they
can
install
that
into
their
platform.
Now
their
users
can
easily
use
all
these
workload
and
trades
and
build
up
their
applications,
and
that
that's
that's
the
main
idea
again,
I
think
it's
it
might
be
a
little
bit
abstract
I'll,
show
you
the
demo
if
it
works,
and
then
you
will
see
what
I'm
talking
about
and
yeah.
On
top
of
that,
you
can
also
build
the
gate.
Ops,
you
can
build
the
flux.
B
Basically,
you
have
this
pipelines,
ci
cds,
all
these
things,
the
the
possibility,
is
basically
endless,
and
here
is
the
platform
builders.
This
this
part,
is
this.
So
every
platform
we
notice
that
you
need
this
logging
monitoring
and
some
maybe
auditing
scaling.
Those
are
the
capabilities
that
is
part
of
the
traits,
those
are
actually
all
traits.
So
maybe
this
graph
is
a
little
bit
confusing,
but
those
are
actually
part
of
the
traits.
So
the
platform
builders,
you
can
to
differentiate
yourself.
B
What
you
need
to
do
is
you
either
put
your
capabilities
into
this
hub
or
you
can
create
your
own
hub
or
just
because
it's
your
logging
solution
is
so
so
good.
Maybe
that's
your
technology
technical
advantage.
You
can
make
them
your
own
trades
and
and
make
it
private,
so
other
users
can
only
get
this
perfect
logging
experience
on
your
platform
and
that
that,
but
that's
still
part
of
the
trades
again.
If
anyone
has
any
questions,
feel
free
to
ask
okay.
C
B
It's
not
really
a
template,
I
mean
so.
The
om
itself
is
not
a
template.
The
template
part
actually
happens
here.
Actually
I
will
show
you
some
kind
of
template
here.
So
the
template
part
happens
here,
the
the
cloud
native.
Actually,
the
oem
runtime,
the
spec
is
actually
a
runtime
or
platform
agnostic
spec.
Although
currently
people
kind
of
critic
criticize
us
of
look
make
the
spec
look
like
a
kubernetes
spec,
but
it
is
not.
B
It
is
actually,
if
you,
if
you
look
really
looking
into
it,
it
is
pretty
much
a
generic
spec
and
that
there
is
kubernetes
implementation
there.
So
we
call
it
om
runtime.
We
have
a
oem
basic
kubernetes
runtime
implementation
that
implement
that
spec
on
a
kubernetes.
I
don't
know
if
that
answer
answers
your
question.
B
D
B
Yeah,
if
you're
interested
to
know
more
after
this
talk,
we
can
you
know,
connect
offline
and
try
to
see
if
there
are
more,
we
can
do
yeah
and-
and
especially
as
I
mentioned
again,
this,
the
om
framework
is
very
extensible
in
a
sense
that
it's
pretty
much
can
taking
anything
on
kubernetes.
Whatever
run
some
kubernetes
runs
in
om,
so
it's
it's
pretty
much,
I'm
pretty
sure
we
can
make
something
work
there.
D
B
B
B
There
are
three
basically
rows
that
they
don't
have
to
in
real
life.
Probably
probably
it's
one
person,
but
they
are
like
three
rows.
We
we
define
that
one
row
is
called
app
developers.
Basically,
it's
the
coders,
basically
programmers
and
then
there's
the
app
operators
we
define
them
as
basically
you
think
of
them
as
kind
of
sres.
B
So
we
have
to
kind
of
have
this
concept,
and
in
with
this
workflow
we
basically
say
your
developers
will
write
your
code
and
put
them
into
the
green
ones,
is
actually
defined
by
operator
by
the
infrastructure
operators.
They
would
define
this.
This
is
where
the
template
comes.
You
have
this
template,
you
have
this
application
code
and
then,
basically,
the
real
application
code
will
be
initialized
the
workload
that
becomes
the
component.
B
Then
the
component
would
have
this
upgrade.
Sies
will
put
some
trades
and
then
put
them
into
application
configuration.
This
is
really
the
real
applications
and
then
you
submit
that
into
the
om
runtime
and
it
will
run
and
also
it
will
have
this
operational
characteristics,
not
not
just
of
deployment
sitting
in
the
in
the
in
the
cluster.
That's
kind
of
the
idea,
a
high
level
idea
in
reality.
B
We
are
also
tweaking
this
a
little
bit
because
to
be
honest,
because
most
people
are
doing
devops,
it's
kind
of
hard
to
really
clearly
separate
the
developer
and
the
operator
part,
especially
when
you
get
to
the
application
configuration
part,
but
anyway
I'll
show
yeah.
Now
I'll
show
you
some
real
code:
okay,
here's
the
here's,
the
real
code,
so
the
order,
let's
see
so
this
is
the
most
developer
facing
part
of
this
spec,
which
is
called
components.
B
The
components
is
essentially
a
templatized
object
for
your
workload
that
that's
what
I,
but
that's
where
that
again
the
template
comes
from
so
here
you
can
see
the
so
that
this
is
the
workload
component.
The
kinase
component.
You
have
this
workload
here
here
is,
I
don't
know
if
you
can
see
my
oops
here
here
is
really
what
this
pretty
much
looks
like
your
kubernetes
deployment
right.
This
can
be
actually
can
be
anything,
but
we
basically
it's
for
now.
It's
embedded
put
it
in
a
kubernetes
term.
It's
basically
embedded
cr.
B
B
Okay
and
maybe
yeah
when
we
put
them
all
together,
then
that
will
make
sense
and
the
reason
we
have
this
component
is.
We
can
allow
you
to
do
anything
you
you
want,
you
can
put
any
deployment
you
can.
You
can
put
in
other
different
crds
for
this
example.
It's
called
containerized,
you
just
call
it
containerize
and
you
don't
have
to
fill
in
all
the
things.
That's
where
we
think
the
it's
not
developer
friendly,
because
anyone
who
is
new
to
kubernetes
will
be
really
confused
by
so
many
different
templates
labels.
B
All
these
things
and
there
there
are
actually
there
are
actually
hidden
constraints
there
that,
like
matching
labels,
needs
to
be
matched
these
labels.
Things
like
that
that,
if
you
are
new,
you
are
definitely
confused.
So
this
allowed
platform
builders
to
build
their
own
customized
resource
and
they
can
abstract
out
whatever
they
think
is
unnecessary
and,
for
example
like
here,
the
only
thing
they
they
want
to
expose
to
the
user
is
what's
the
image
name
like
where
it
is.
This
is
in
a
docker
register.
B
B
So
the
next
thing
that
that's
is
trait,
so,
as
I
mentioned
application
configuration
is
what
we
think
is
an
application,
real
application,
and
the
component
is
the
workload
that
we
just
mentioned.
That's
the
developer's
code,
basically,
and
then
in
the
application,
you
can
have
multiple
components,
just
like
any
microservices
and
then
between
for
each
component.
You
can
put
in
a
few
trades
and
for
each
trade,
it's
just
similar
as
the
workload
component
before
in
a
trace.
You
basically
can
embed
it
as
cr.
That's
again
in
the
oops
every
time
I
click.
B
It
goes
back,
embedded
cr
that
that
cr
is
just
whatever
you
want.
That's
where
the
you
see,
there's
networking
api
gateways,
the
traffics,
that's
where
the
the
operators
comes
from
and
the
each
trade
is
basically
a
controller
in
in
in
terms
of
really
kubernetes
way.
It's
a
controller
so
that
you
can
have
that's
that's
where
you
have
your
app.
You
can
have
your
developers
writing
the
code
group
them
into
your
own
workload.
B
That
workload
is
provided
by
the
platform
and
then
the
platform
also
provides
a
few
already
written
traits
maintain
traits
that
trades
say
here
is
hpa
traits
right.
It
will
tell
you
the
max
mean
I
didn't
put
in
a
cpu
threshold,
whatever
you
put
in
these
things
and
it
will
automatically
scale
your
applications,
or
at
least
for
here
is
scale
your
component
like
front
end
component
and
then
you
can
also
add
a
api
gateway
or
we
will
have
a
route
trade
tells
you
what's
the
host
name.
What's
the
path
yeah
just
like
like
that.
B
B
Oh
yeah
and
then
there's
there's
this.
I
think
this
actually
actually
is
the
most
critical
part
of
how
it's
extensible.
That's
the
traits.
That's
that's
the
definition
system.
That's
when,
where
I
I
mentioned
that
the
capability
center
part
is
how
do
you
register
all
your
capabilities
to
the
system?
That's
where
we
call
it
a
trade
definition.
B
It
can
be
actually
not
just
trade,
it
can
be
a
trade
definition
or
it
can
be
a
workload
definition
there.
Basically
and
and
there's
a
scope.
I
I
didn't
mention
it's
a
it's
a
another
concept
that
we
haven't
fully
developed
yet
so
the
registration
is
where
you
can.
Anyone
can
register
their
capabilities
into
the
system,
for
example,
here
the
trade
definition
will
tell
you
what's
the
name
of
this
trade,
it
doesn't
have
to
be
this
way
now
it
can
be
a
much
longer
a
more
readable
name
now.
B
At
that
time
we
will
still
have
some,
it's
basically
a
crds
crd
name.
Now
it
doesn't
have
to
be
like
that,
and
it
can
be
a
name.
It
will
tell
you
what
what
kind
of
workload
it
applies
to
what
kind
of
work
other
traits
that
conflict
with,
and
this
definition
is
the
schema.
This
is
where
the,
where
remember
you,
you
can
define,
say
containerized
workloads,
which
only
have
two
two
parameters:
that's
where
you
can
define
a
schema
and
we
actually
on
in
the
in
the
our
implementation.
B
We
actually
define
a
allowed
user
to
define
another
put
another
templatized.
Basically,
we
call
it's
a
q
language.
I
don't
know
if
we've
heard
that
heard
of
that
it's
called
q,
so
we
allow
user
to
define
the
real
interface
in
a
queue
language
and
the
user
can
further
abstract
out
all
the
details
of
this
definition
and
allow
their
developers
to
just
fill
in
a
few
parameters
into
it.
B
B
B
A
B
A
B
Okay,
so
so
now
we
have,
we
build
up
our
reference
implementation
called
kubi
bella
last
thing:
that's
our
envision.
We
basically
we
know
that
just
for
the
abstraction
layer
and
the
standard
out
it's
hard
for
people
to
really
grasp
the
power
of
this
abstraction.
So
we've
built
our
own
system
and
it's
called
kuberweyla,
and
in
that
system
we
have
this
concept
called
app
files.
B
That's
where
the
let
me
see
if
I
can
go
back
to
the
slides
here
here,
so
we
basically
instantiate
this
part
to
make
this
part
really
concrete,
because
the
the
standard
just
defines
this
part.
So
we
have
we're
putting
more
stuff
on
that
part
and
so
the
f5.
You
can
see
that.
Let
me
just
that's
where
the
it's
actually
in
underneath
it,
it's
application
configuration
just
as
the.
Let
me
just
try
to
yeah.
B
It
is
application
configuration
just
because
the
application
configuration
if
you
look
at
the
schema,
it's
a
little
bit,
it's
yamo
and
it's
kind
of
verbose.
We
don't
think
it's
really
a
developer
friendly
developer,
don't
want
to
write
200
lines
of
yaml
just
to
describe
their
applications,
so
we
simplified
it
a
bit
so
that
it
looks
like
this
and
in
high
level
you
can
see.
This
is
basically
the
name
of
the
application.
B
These
are
components.
If
you
still
remember,
components
basically
are
the
other
users
services,
and
then
this
is
one
service.
We
extract
out
a
few
things
like
the
image
here
and
build
is
the
source
to
image.
This
is
actually
not
source,
it's
going
from
docker
to
to
image,
and
then
these
are
the
traits
and
so
just
to
demonstrate
a
little
bit.
Let
me
see
if
I
can.
B
So
we
can
call
you
up
see
if
so,
this
is
basically
yeah
we're
building
all
this
building
up
this
darker
image,
building
up
the
image,
and
then
we
are
going
to
translate
that
into
applications,
components
traits
all
these
things
at
the
end
of
that,
let
me
let
me
show
you
okay,
so
that
this
works.
Let
me
show
you
this
so
so
for
this
to
work,
we
installed
the
application
configuration
controllers
in
the
kubernetes.
A
B
B
So
let
me
going
back
again,
so
the
idea
is
you
have
this
application
name,
you
have
each
services,
we
call
it
service
instead
of
components,
because
we
want
it
to
really
sound
like
microservices,
so
each
one
is,
we
call
them
a
service
and
inside
that
you
can
define
a
service.
You
can
do
basically
it's
image
built
to
source,
to
image
and
a
few
of
really
common
things
to
a
combined
port
number
and
then
the
key
thing
is
those
are
the
those
are
the
traits
each
and
each
trait.
We
have
a
definition
somewhere.
B
B
B
Yeah,
so
here's
an
example
of
this
route
chat.
You
have
this.
You
have
annotations
query
time,
blah
blah
blah
here.
Here's
what
I
mentioned
right.
You
have
applied
to
workloads.
What
kind
of
workloads
it
applies
to
it
will
tell
you
web
service
definition.
Reps
is,
this
is
the
the
crd
name.
Basically,
this
is
the
real
crd
name.
That
means
that
the
route
we
have
a
controller
behind
that
we
have
a
template.
B
B
B
Oh
too
many.
I
guess
this
is
the
same.
Oh,
this
doesn't
have
the
same
front,
size.
Okay.
I
cannot
really
show
you
together,
so
so
now,
for
example,
let's
redo
this
because
previously
I
just
deployed
the
application,
I
don't
have
the
I
didn't
define
ingress,
so
you
cannot
really
access
this
part.
Now,
let
me
add
a
route
trade
to
it
and
then
just
basically
upload
it
again.
B
B
F
B
B
Yeah
the
rest,
I
think,
to
be
honest,
I
there's
some.
There
are
some
technical
glitches.
I
know
that
is
is
waiting
for
me,
so
I'm
not
going
going
to
venture
into
those
and
the
live
demo.
I'm
still
debugging
these
things,
but
just
general
idea
you
can
see
we
can
also
put
in
auto
scale
you
can
put
in
scalar.
We
actually
have
auto.
You
have
a
roll
out
too,
like
when
you
want
to
add
to
upgrade.
These
are
the
things
you
can
put
on
to
the
the
applications.
B
Then
it
will
let
the
controller
automatically
do
this.
For
you,
the
key
key
part
is
ideally,
these
are
defined
by
the
application
of
platform
builders
so
platform.
That's
where
the
platform
builders,
at
least
in
our
view,
can
make
make
their
platform
attractive,
that
they
have
very
powerful
operation
operational
controllers.
Basically,
they
can
execute
very
complicated
logics
and
you
know
seamlessly
pull
off
upgrade
and
the
developers
all
they
need
to
do
is
just
look
up
their
platforms,
builders
capabilities
and
fill
in
those
really
simple
trades
and
things
would
work
out.
B
B
Yeah,
so
for
the
community,
so
oem
is
a
joint
pro
joint
project
between
microsoft
and
alibaba
cloud.
So
mike
we're
working
with
microsoft,
as
I
mentioned,
so
we
defined
the
app
file
part,
but
that's
not
part
of
the
om
spec.
Yet
so
we
are
working
with
them
to
get
a
more
developer
friendly
spec
into
the
into
the
om
and
their
cross
play.
I
don't
really
heard
of
that.
We
actually
collaborate
with
crossmember.
B
The
om
runtime
is
really
part
of
the
cosplay
now,
but
the
the
kobe
villa
is
not
because
we
want
to
write
just
with
the
om
runtime
itself.
Again,
it's
not
very
useful.
We
need
to
add
more
developer
layers,
make
make
it
a
real
full-fledged
reference
implementation.
That's
why
we
build
up
this
kobe
bella.
B
A
B
F
B
So,
for
example,
we
have
a
vpc
scope
of
a
virtual
private
network
scope
or
something
like
that,
so
that
multiple
components
can
reside
in
the
same
vpc
and
so
that
scope
needs
to
go
across
multiple
multiple
components
and
trade
only
applies
to
one
component
so
that
that's
that's
a
big
difference
and
we
are
thinking
of
putting
a
application
level
scope
too,
so
that
we
don't
have
to
put
scope
into
every
trades
every
every
component.
Sorry
that
does
that
answer
your
question.
B
C
Hey,
I
think
I
have
one
hey,
hey
lee
and
yeah
okay
as
well.
I
think
okay,
but
it
will
join
but
yeah,
hopefully
so
run.
I
just
sorry.
I
joined
in
the
middle,
so
just
a
little
ignore.
So
is
it
kind
of
templating
language
like
helm
and
if
not,
what's
the
difference
like
in
this
case
to
describe
so,
are
you
asking
like
a
kobe,
could
be.
B
D
B
It's
really
just
a
high
level
defined
of
the
object:
it's
not
even
a
yama
or
or
json,
although
we
assume
anyone
when
they
implement
that
we
use
java
json,
which
to
us
is
pretty
much
equivalent.
The
spec
is
really
just
the
object
level
definition
of
what
each
object
will
look
like.
What
are
the
fields
inside
that?
That's
the
om
spec
alone.
It's
like
that
in
terms
of
template.
Templating
part,
that's
on
top
of
that
is,
as
you
you
can
see,
and
you
sort
our
application.
Actually,
let
me
show
you
this.
B
Yeah,
so
so
remember
we
have
this
app
file
right,
so
this
default,
as
I
mentioned,
this
is
equivalent
to
application
configuration.
This
is
more.
This
was
was
heavily
templated.
It's
equivalent
to
that,
and
this
one
is
the
real
application
definition.
You
can
see
that
it
has
the
this
is
what
we
in
in
the
back
end,
basically
translated
into
application
definition.
B
B
You
have
these
specs,
and
then
they
have
status,
workloads
yeah,
so
so
application
configuration
in
in
our
implementation
looks
like
this
and
to
make
it
less
verbals
or
more
user-friendly
and
provide
this
power
of
templating
power.
The
abstraction
power
is
again
because
the
we
allow
the
the
platform
builders
to
build
a
very
powerful
controller.
Basically
you,
I
call
it
controller,
you
call
it
crd
called
whatever
operator,
but
but
the
the
many
times
in
the
in
the
design
phase.
B
There's
a
there's,
a
tug
of
war
between
how
powerful
you
want
to
provide
and
how
simple
you
want
to
provide.
You
want
to
provide
the
apple
thing
right.
Just
one
click
do
does
everything
or
you
want
to
provide
whatever
the
old
old-school
windows
thing
you
can
do
anything
you
want.
So
how
do
you
balance
this?
B
A
A
Nice
ryan,
thanks
a
bunch
for
this.
This
has
been
really
nice.
It's
really
good
to
be
introduced
to
the
project
and
see
to
understand
the
vision
and
scope
of
the
project,
the
purpose
for
it
without
having
to
try
to
decipher
that
from
written
word
on
the
on
the
web
pages
yeah.
It's
evident
that
there's
at
least
to
me
that
there's
a
few
there's
a
there's,
a
few
concepts.
There
are
problems
that
are
at
the
core
of
what
you're
trying
to
solve,
and
it's
some
of
that
has
to
do
with.
A
I
know
it's
a
broad
term,
but
some
of
that
has
to
do
with
just
ux
something
that
has
to
do
with
the
the
acknowledgement
that
well
it's
actually
I've
talked
man
boy.
I
bet
you
know
what
let
me
not
say
a
number
of
things.
I
I
think
I
a
lot
of
things
that
you
said
resonate
and
some
visions
that
you
guys
have
resonate
I've
spoken
on
that
this
subject
any
number
of
times
and
so
yeah
there's.
A
While
I
think
that
some
might
look
at
this
and
say
well
like,
but
aren't
you
just
kind
of
redefining
stuff,
that's
already
in
there
can
I
just
use
my
kubernetes
manifest
for
that
couldn't
die
like
capture
that
info
in
an
annotation
or
somewhere
else
or
something
something
like
the
thing
is.
If
you
look
at
the
problem
long
enough,
it's
it's
a
big
enough
problem
that
it's
it's
not
it's
not
addressed
or
like.
No,
those
annotations
are
not
enough
or
know
the
like,
there's
a
number
of
concerns.
A
And,
moreover,
if
you
break
down
the
problem-
and
you
say,
there's
there's
this
persona
that
persona
that
persona
there's
three,
that
we
kind
of
talk
you
talk
about
here
and
then
there's
there's
the
network
engineer.
There's
the
service
provider
network
engineer,
there's
the
people
trying
to
do
network
function,
virtualization,
there's
people
trying
to
do.
Operators
trying
to
run
service
meshes
very
well
and
they
go
very
deep,
there's
those
that
are
trying
to
do
serverless
and
function
things
and
they
need
different
day.
Two
concerning
like
it's,
it's
a
massive
surface
area.
Potentially
you
know
yeah.
A
So
this
is
exciting.
I
was
just
leading
the
cncf
some
sig
network
call.
Yesterday
we
were
talking,
I
mentioned
oem,
and
I
mentioned
the
fact
that
you'll
be
here
doing
this
because
part
of
what
half
of
what
our
conversation
was
on
that
sig
network
call
had
to
do
with
really
just
this
problem
statement
that
things
like
smi
are
somewhat
related
to
this.
But
smi's
surface
area
is
about
yay,
big
yeah.
B
And
so
yeah
yeah,
I
think
we,
I
think
we
have
a
demo
that
also
not
not
maybe
not
demo.
We
are
working
with
smith.
We
we
try
to
clap,
incorporate
smi
into
our
system
too.
We
have
something
semi
working
there,
but
yeah
would
be
great
to
collaborate
further,
more
definitely
at
least
get
something
really
working
there
to
to
to
to
round
up
this
whole
feature,
because
you
can
see,
we
don't
have
enough
network
features.
Traffic
features
there.
A
A
Thank
you
much
ryan,
all
right,
fair
enough,
so
it's
weird
we're
just
at
time.
Everybody
there
is
well
now
I
lost
track
of
the
meeting
minutes,
but
there's
probably
there's
only
one
quick
item
to
call
out
in
the
meeting
minutes.
Probably
and
that's
there's
a
number
of
things
for
us
to
chat
on,
all
of
which
can
wait
only
one
of
which
we
should
call
out
and
ruth.
Do
you
want
to
say
a
quick.
A
A
So
if
anyone
has
feedback
to
offer,
I
think
she's
soliciting
it
other
than
that
we
will
so
so,
very
briefly,
josh
and
others
on
the
call
that
are
focused
on
layer,
5
ng.
We
do
have
the
2021
goal
so
josh,
we'll,
let's
we
should
talk
about
meeting
tomorrow
and
set
up
a
time
and
other
than
that
so
like
I
said,
we
won't
meet
in
the
community
meeting
on
next
friday,
but
we
will
have
the
other
regularly
scheduled
other
meetings
throughout
the
week.