►
From YouTube: Workshop on Defining a Reference Model for Cloud-Native Application... Alois Reitbauer & Lei Zhang,
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
Workshop on Defining a Reference Model for Cloud-Native Application Delivery - Alois Reitbauer, Dynatrace & Lei Zhang, Alibaba
The application delivery SIG has started to define a reference model for cloud-native application delivery and operations. In this deep dive session, we will start a journey from questions like “What is the Application?” to “The layers and phases through application delivery”, then all the way to the typical model and pattern of application delivery. We will use certain open source projects as concrete examples to explain how they fit into this model, their maturity level in each layer, what’s missing, and the direction the application delivery SIG is trying to pursue. The session will help audiences figure out not only “what project X is doing”, but also “in what layer project X is working” and “how it performs there.”
https://sched.co/WeWS
A
I
think
this
talk
is
actually
a
great
continuation
of
some
work
that
Brian
started
today
when
they
talked
about
making
the
benitez
easier,
and
it
should
just
be
I'm
the
developer
here
their
platform
take
my
application
and
run
deploy
and
manage
it
just
out
of
a
coincidence.
Brian
is
also
co-chair
of
the
CCAP
delivery
with
me
here
today
is
Harry
and
my
name
is
Alois.
A
Just
out
of
curiosity,
who
was
at
our
intro
session
yesterday:
okay,
that's
almost
half
of
the
people,
so
we
didn't
scare
you
away.
That's
amazing!
So
today
will
be
more
of
an
interactive
session
where
Harry
will
walk
us
together
with
myself.
Ozzie
well,
walk
us
through
that
reference
model
in
detail
and
really,
if
you
have
any
questions,
feel
free
to
ask
them.
A
A
One
of
the
first
outputs
really
from
the
work
that
the
sick
has
been
doing
molars
as
a
preparation
for
my
future
work
to
provide
a
structured
version
which
eventually
will
and
also
lead
into
a
landscape
for
cloud
native
application
delivery
and
with
this
I'd
like
to
pass
over
to
Harry
and
by
the
way,
if
you
think
that
here
breaks
down,
it's
not
a
stitch
to
squeaking
all
the
time.
So
we're
risking
our
life
to
present
to
you
today.
B
B
Sure
so
my
name
is
Lee
can
call
me
Hari
and
I'm
from
Alibaba,
so
this
began
and
if
you
take
a
look
at
it
to
get
the
the
extensive
landscape
above
the
application
and
management
in
today's
landscape,
you'll
find
okay.
There
are
so
many
projects
here,
I
just
leave
some
one
of
them
and
there
are
category
there's
two
parts
in
the
first
part
is
so-called
application
definition
and
the
second
part
is
category
the
SDI
and
a
CD.
B
It
makes
sense
to
some
extent,
but
if
you
take
a
closer
look
into
several
project
in
this
landscape,
you'll
find
something
interesting.
So
I
will
take
helm
an
example
and
a
lot
of
people
are,
you
need
so
who's
using
help
here,
maybe
should
be
everyone
cool,
so
yeah
helm
is
category
application,
definition,
incidence
of
landscape.
It's
true
because
helm
actually
gave
you
a
description
for
application,
including
metadata
about
the
application
which
we
defined
in
charge
mo,
for
example,
the
name
is
containers.
B
The
link
to
Starks
thing
like
that,
and
also
helm,
gives
you
the
ability
to
tracking
resources
compose
to
this
application
right.
So
if
you
take
a
look
at
the
templates
files
in
home,
charts,
you'll
find
ok
all
the
things
you
need
to
run
application,
including
the
deployment
description
services.
Description,
may
be
persistent
watering
description
all
there
right.
So
that's
how
you
check
your
resources
need
to
run
application
and
also
you
need.
You
can
also
be
able
to
defy
the
dependencies
in
a
chart
file.
B
So
you
can
okay,
say:
I
want
to
rely
on
some
other
trusts.
That's
fine!
But
if
you
take
a
closer
look
at
help,
you
will
find
something
more
interesting
because
it
has
several
several
functionalities
which
maybe
not
belonging
to
your
application.
Definition.
For
example,
it
actually
provides
you
functionality
like
a
package
management.
That's
why
you
can
search
and
download
the
charts
from
the
helm
hub
right,
because
it's
totally
some
some
some
somewhere
and
also
to
give
you
ability
to
do
parameter
in
a
configuration,
for
example,
helm,
temp
lending
right.
B
It's
give
the
ability
to
configure
your
home
trusts
to
different
environments.
So
if
it's
a
closer
look
of
helm,
other
functionalities
we'll
find
something
more
interesting,
such
as
release
management,
because
helm
can
upgrade
application
can
roll
back.
Your
cupcake
application-
and
it's
even
give
you
some
features
like
epic
management,
hooks
sanitation
to
Yarmouth,
also
say:
okay,
I
want
to
do
something
before
after
the
installation.
The
question
is:
are
they
all
part
of
the
application
definition?
B
This
is
actually
a
very
common
question
in
today's
stick:
application
delivery
because
people
like
me-
or
you
are
not
very
clear
about
what
a
project
is
really
about
here.
We
have
three
projects:
helm,
customized
and
occasion
aid,
even
though
they
can
all
do
things
or
run
your
Yama
house.
But
the
question
is:
are
there
or
application
definitions?
B
That's
why
we
want
to
try
to
figure
out
a
better
answer.
For
addition,
what
is
a
project
leery
about
in
seek
application
delivery?
We
began
to
proposing
this
this
kind
of
we
called
the
model
of
application
delivery
to
you
guys
because
it
is
trying
to
classify
the
typical
topics
in
the
sig
or
in
this
field,
into
verified
definitions
and
models
in
this
diagram.
I
will
walks
through
this
diagram
one
by
one.
So,
let's
begin
from
the
top
column,
we
know
that.
B
Please
note
that
we
have
top
:
and
top
1
/
5,
because
they
are
very
closely
related,
so
we
defined
like
this.
The
first
thing
is
application.
Definition,
it's
a
it's
about
hammer
right.
So
what
is
that?
The
application
definition
is
essentially
the
answer
for
what
to
run
right,
your
Yama
files
or
configuration.
They
are
old
answer
to
this
question
and
he
wrote
practices.
The
application
definition
are
mostly
expressed
as
application
descriptor
or
application
model.
So
what
are
they?
What's
the
difference?
B
Let's
talk
about
the
application,
descriptor
the
description
of
the
application
normally
including
two
parts.
The
first
part
is
your
metadata
of
the
application
which
I
have
shown
you
by
using
helm
right,
including
the
maintainer,
the
name,
description
of
application,
regardless
of
its
running
or
not,
and
the
second
part
is
it-
should
give
you
the
capability
to
tracking
all
the
resources
compose
application.
B
That's
that
also
means,
if
I
have
a
platoon
descriptor,
that
I
should
be
able
to
deploy
the
application
by
using
that
gamma
file
or
that
description
descriptor
to
any
environments
right,
because
it
should
be
a
description
of
your
whole
application.
All
of
the
resources
needed,
but
speaking
with
that
is
not
so
easy.
Your
application
definition
of
your
aura
application
description
may
be
simple
like
this,
but
the
real
resources
you
need
to
wrong
application
may
be
very
complicated.
B
For
example,
in
crouppen
it
is,
the
application
may
be
needs
a
lot
of
company's
resources
like
services
like
CRTs
in
grace
as
they'll
be
Arabic
rules,
images,
PVD,
persistent
volumes,
so
all
of
the
things
all
of
these
resources
are
part
of
the
application.
Definition
should
be
because
if
you
run
through
your
own
application
in
the
clustering
in
any
cluster,
you
need
to
defy
all
of
the
resources
very
well.
So
how
can
I
do
that?
It's
a
ye
real
word
application
descriptor,
could
be
very
complicated.
I
will
give
you
two
examples.
B
The
first
one
at
helm,
helm
is
essentially
composed
by
several
parts.
The
first
part
is
application
metadata
to
give
you
things.
I
have
taught
before
like
most
application.
What
is
a
multi-sport?
What
hadix
functionality,
who
is
a
maintainer
right,
but
also
it
provides
you
a
bunch
of
templating
files,
which
is
essentially
how
it
defies
both
Kublai's
resource.
You
need
run
to
run
application,
and
not
only
to
mention
it
also
give
you
capabilities
to
defy
okay.
B
What's
these
charts,
depending
on
the
others,
that's
how
helm
in
the
handling
application
definition
for
you,
if
you
trying
to
give
you
a
self-contained
application
definition
by
using
your
charts
for
application,
so
you
can
deploy
these
charts
to
any
class
value
bill.
The
second
deck
dump
I'm
listing
here
is
the
application.
Crd
will
show
you
the
proposed
incriminates
seek
application,
and
this
is
a
little
bit
similar
to
helm.
It
also
gives
you
application
metadata
here
in
this
in
this
in
this
place.
The
difference
is:
is
this
application
metadata
file
also
device?
B
What
is
the
equivalent
resources?
I
need
to
run
for
this
application,
for
example,
in
this
picture
it
shows
that
my
application
need
to
use
one
service,
and
once
they've
all
said
so,
this
is
actually
reference
to
the
real
various
resources
you
need
to
deploy
in
your
kubernetes
cluster.
So
this
is
how
applications
the
Rd
works.
B
Well,
this
is
application
descriptors.
They
are.
They
are
actually
you
that
you
can
see
as
the
metadata
and
give
you
some
means
to
checking
your
resources
right.
But
what
is
application
model
you?
Essentially,
they
are
quite
similar
to
application
descriptor.
The
only
thing
is
the
model
added
to
you
is
a
specification
for
you
to
defy
all
of
the
informations
about
how
to
define
how
to
describe
your
application,
edited
hub
duty
fly
or
resource
dependencies,
so
they
just
added
another.
Just
one
more
thing
to
your
application.
B
Descriptor
one
of
the
earliest
application
model
I
know
is,
is
a
surrealist
application
model
sin
which
is
proposed
by
ADA,
based
I,
think
in
2016,
so
it's
yellow
flowers
of
every
single,
just
give
you
a
specification
or
met
or
schema
for
you
to
define.
Okay,
I
want
to
deploy
a
hello
world
application,
and
the
type
of
this
application
is,
for
example,
in
this.
B
In
this,
in
this
diagram
is
a
service
function
on
AWS,
and
then
you
should
defy
your
properties
to
run
your
application,
that's
all,
and
when
you
deliver
this
Java
file
to
AWS
platform,
if
you
actually
provision
a
real
resource,
you
need
to
run
application
in
this
case.
Is
the
video
based
lambda
function,
which
name
is
hala
word
and
the
corresponding
EPR
kata
based?
So
you
can
village,
you
can
use
your
application
right,
so
this
is
stem,
but
with
this
kind
of
application
model
you
can
do
something
more
interesting.
B
For
example,
in
other
place,
you
can
upload
your
samyama
file
to
some
kind
of
storage,
so
other
people
can
download
the
demo
file
and
reproduce
the
application
in
their
own
environment
in
their
own
AWS
cluster.
Just
like
what
you
can
do
in
your
in
your
cluster
and
another
application
model
is
open
application
model,
ohm,
which
is
quite
new,
so
it's
quite
similar
to
stem.
But
the
only
difference
is
here,
so
it
actually
provides
two
different
IP
I
stays
two
different
users
for
developer.
B
It
will
be
responsible
for
them
to
defy
the
components,
yeah
morphology,
exactly
how
to
describe
what
to
run
and
for
the
application
operators,
however,
provided
them
with
another
API
state,
which
name
is
shade,
which
is
used
for
to
defied
operational
capabilities
like
how
to
scale
how
to
scaling
and
scale
out
how
to
do
all
the
scaling
how
to
do
ingress.
So,
as
a
user
of
the
deployer
of
the
application,
you
just
need
to
combine
those
concepts
together
by
using
application
configuration,
so
you
this
Yama,
actually
the
application
metadata
file
for
the
own
application.
B
So
you
can
just
delete
where
this
Yama
file
to
your
kubernetes
and
a
Koopa
dates
will
be
responsible
with
what
you
spawn
both
responsible
for
provisioning,
the
deployments
the
HPA
you
needed
in
this
application.
So
this
project
is
a
pretty
new.
So
if
you
have
any
questions,
you
can
ask
the
Microsoft
guys
over
there.
They
have
really
nice
t-shirt
for
you,
okay.
B
So
let's
go
to
the
next
topic.
Now
we
have
application
descriptor
right,
but
the
question
is:
how
can
I
use
the
same
application
descriptor
in
different
environments,
for
example?
I
won't
have
only
one
replica
in
testing
environment,
but
I
want
to
have
three
replicas
in
production
environment.
How
can
I
do
that?
That's
why
you
need
helm
or
something
like
this.
There
are
three
ways
for
now
for
you
to
configure
the
Yama
files.
B
The
first
is,
of
course,
template
which
is
widely
used
by
hell,
it's
very
easy
to
use,
but
from
my
opinion,
it
actually
break
a
little
bit
the
integrity
of
the
Yama
files,
because
essentially
your
yarmulkes
another
Yama
animal
is
actually
templating
files.
You
don't
know
the
real
value
of
these
templating
files
unless
you
have
rendered
this
Yama
file
right
and
that's
why
there
is
another
project
which,
namely
customize
it
use
the
overlay
technology
for
you
to
configure
the
AMA
files.
So
essentially,
you
have
based
on
Moe
and
Apache
on
mo.
B
So
it
helps
you
to
keep
the
integrity
of
your
mo
files
because
you
know
exactly
what's
the
value
of
replicas,
for
example,
in
base
m
FL
alveolar
the
in
Tamil
film,
and
you
can
store
them
in
kit
or
something
like
that.
It's
why
we
say
it's
pretty
good
ops
friendly,
but
it
actually
gives
you
a
higher
bar
to
learn
to
use
this
kind
of
a
mouse,
because
it's
not
essentially
how
we
think
in
human
mind.
The
human
body
cannot
do
patch
or
merge
we're
on
it.
B
We
are
not
keep
server
right
and
the
third
part
for
do
that
is
DSL.
Essentially,
there
are
programming
languages,
for
example,
Jason,
ed
keys
on
it,
and
it's
apart
they
are
very
powerful,
because
now
you
can
write
program
to
do
whatever
you
want
right,
there's
no
arm
of
us
anymore.
You
don't
need
a
handle.
You
don't
need
to
be
a
Yama
flower
engineer
to
handle
kubernetes
anymore,
but
it
gives
you
the
highest
and
learning
curve
because
it
essentially
need
to
learn
another
language
right.
So
this
is
difference
between
these
three
approaches.
B
But
there's
one
more
thing,
I
want
to
add,
is
a
very
interesting
project,
which
name
is
shape.
It
is
actually
using
a
customized
to
modify
the
armor
of
thoughts
that
ham
trust.
So
you
can
use
overlay
to
change
the
values
in
your
home
charts.
It's
very
interesting
because
try
to
come
by
the
advantages
of
both
helm,
charts
advertise
or
advertise
the
customized,
it's
really
interests.
You
can
take
a
look.
Ok,
so
let's
go
to
the
application
packaging.
Now
we
have
descriptors
or
models
and
we
have
abilities
to
to
customize
them
right.
B
So
the
last
thing
in
how
we
distribute
these
descriptors
in
different
environments-
it's
very
simple
and
very
straightforward,
so
you
can
just
use
a
zip
file
to
do
that.
Alright,
but
also
we
can
use
some
standard
way,
spend
the
registry,
for
example
the
OCR
artifacts
to
package
your
applications
and
see
Knapp
is
the
one
I'm
typical
example
for
you
to
do
that,
but
it
also
you
darker
image.
You
can,
of
course,
if
you
have
charts
the
helm
is
what
I
need
highlight
here,
because
it's
already
build
an
ecosystem
for
you.
You
have
helm
harp.
B
We
have
charts
museum.
You
can
build
whatever
you
want
by
still
have
your
own
home
chart
harp
in
your
own
environment.
So
that's
why
I
list
here
separately?
Ok,
so
here's
a
checkpoint!
Now
we
have
stable
project.
We
have
learn
about
how
the
top
cool
one
and
it'll
be
one
one,
one,
two
five.
So
what's
the
difference
of
this
project?
Let's
answer
this
question.
We
have
helm
customize,
kiss
on
it
and
ohm
and
Sam.
So
you
can
see
now
we
can
figure
out.
Okay.
B
So
this
is
where
it
had
a
little
bit
overlapped
with
helm,
but
they
do
not
have
overlap
regarding
to
the
application
definition,
customizing
kissing
and
do
not
care
about
what
you
write
in
your
llamo
film
do
not
care
about
what
you
define
them
of
them.
That's
the
difference
here,
but
for
ohm
and
stem
or
other
application
models.
They
only
care
about
how
to
provide
you
with
specification
for
you
to
defy
or
descriptor
that's
why?
It's
only
cares
about
application
mode.
B
It
do
not
care
about
how
we
modify
the
amo
files,
so
you
can
see
the
difference
here.
That's
why
we
say
this
model
application
modeling,
you
know
in
the
sig
will
may
help
you
to
defy
okay.
What
is
this
particular
worry
about?
Okay,
let's
move
to
the
next
topic,
and
that's
topic
is
about
application
while
enrolled.
B
It's
very
important
in
the
real
world
because
you
may
want
to
deploy-
or
you
may
want
to
up
with
or
wrote
an
application
without
breaking
your
end-users,
so
about
late
always
to
talk
about
this
part,
because
he
is
really
expert.
In
this
case.
Okay,
we
can
start
from
a
robot
tip
codes.
The
ICD
Poppa
here
yeah.
A
So
what
we
have
done
so
far
so
far,
we
have
more
less
defined
what
our
application
looks
like
and
we
have
defined
a
way
how
we
can
modify
it
for
different
environments
and
different
deployments.
One
deployment
might
actually
dip
diplomat
a
my
cluster
deployment
and
your
clusters,
of
course,
but
also
deployment
across
different
stages.
I
think
the
customization
problem
in
the
pyramid
decision
problems
immediately
occurs
once
you
deploy
it
across
multiple
stages
and
how
you
can
roll
it
out.
A
A
A
Technically,
we
need
a
bit
more
than
an
image
repo,
because
just
knowing
where
our
container
image
resides,
doesn't
really
tell
us
anything
what
to
do
with
it.
So,
on
top,
we
need,
like
all
this
application
description,
all
this
parameterization
and
our
deployment
steps
also
need
to
understand
how
to
modify
this
for
that
for
dedicated
environments.
So
you
see
you
get
this
very
strong
dependency
between
how
I
define
my
application.
A
The
key
here,
however,
is
what
we
want
to
do.
This
is
actually
the
first
time
where
we're
taking
whatever
we
have
as
an
application
definition
and
translating
it
into
platform
primitives
that
we
are
then
able
to
execute
which
might
be
deployment
services
if
you
have
meshes
these
type
of
configurations
and
we
keep
them
running
until
they're
terminated.
A
A
Obviously
nobody
is
deploying
workloads
just
but
even
Qube
control
apply.
Well,
you
might
do
it
in
the
very
beginning,
but
you
realize
you
have
to
do
more
around
it,
so
we
have
to
build
this
delivery
workflow.
First
of
all,
it
might
go
wrong,
so
you
have
to
do
something
about
it.
Secondly,
you
have
to
automate
it,
especially
if
you
want
to
scale,
and
last
but
not
least,
we
have
cloud
native
mechanisms
like
blue-green
deployments,
cannot
really
performance
and
other
things
where
we
also
want
to
take
actions
if
they
don't
work
as
as
designed
here.
A
So
on
top.
You
see
this
works
on
here,
where
we
first
find
the
image
then
deployed
in
Canary
mode
that
we
will
either
manual
approval
or
automatic
approval
and
then
deploy
it
to
the
next
stage
and
so
forth.
So
a
lot
of
this
is
usually
driven
by
get
self.
There
was
a
couple
talks
here,
obviously
on
github
on
github
switch
actually
actually
is
yet
another
repository
where
we
keep
application
configuration.
The
difference
here
is
obviously
the
configuration
we
actually
keeping.
A
This
is
usually
also
where
we
have
pipeline
definitions,
which
happens
to
be
in
younger
as
well.
This,
then
again,
massively
depends
on
the
tool
and
we
start
to
encode
a
lot
of
how
we
apply
these
different
things
across
the
pipeline's
there's,
a
project
like
tech,
town,
arago,
workflow,
spinnaker
and
others
that
actually
follow
this
paradigm.
There's
an
important
alternative
paradigm
from
another
project
called
captain
did
use
it
in
an
event
based
mechanism.
So,
instead
of
defining
the
pipeline,
you
define
lifecycle.
Events
have
tools
jump
into
this
lifecycle
events
and
then
provide
the
proper
transformational
actions.
A
So
another
example
here
is
what
we
put
in
flag
or
as
an
example,
so
you
can
actually
find
your
rollout
strategies,
and
this
is
also
something
where
the
app
delivery
you
get
delivery.
We
want
to
look
at.
We
all
talk
about
what
a
Bluegreen
deployment
is
or
what
a
cannery
release
is
if
we
might
have
some
agreement
on
what
it
is,
but
actually
this
is
kind
of
like
secret
knowledge.
A
If
you
look
at
also
a
lot
of
the
things
that
happen
in
the
application
definition,
because
we
have
defined
how
to
deploy
an
application,
but
we
have
never
specified
Candy's
application
actually
be
deployed
in
a
Bluegreen
mode.
It
should
be.
If
it's
a
cloud
native
application,
we
should
be
able
to
do
it,
but
we've
never
specified
it.
Can
we
actually
roll
it
back
and
if
we
roll
it
back
out,
there
may
be
some
dependencies
or
some
orders
of
stuff
that
here
how
these
things
have
to
be
rolled
back.
So
there
you
see.
A
Suddenly
there
is
this
overlap
in
our
deployment
processes,
depending
on
the
application
delivery
and
some
knowledge
that
is
actually
only
encoded
in
our
rollout
process.
That
wasn't
even
be
part
of
this,
so
one
example
here
is
obviously
using
something
like
flagger
and
just
to
make
it
more
complex.
We
don't
only
have
to
modify
the
deployed
entities
per
se
once
we
start
to
use
service
measures,
we
have
to
configure
a
number
of
other
components
in
there
as
well
yeah
you
put
it
on
the
side
here.
A
Smi
would
actually
be
super
helpful
because
then
we
are
suddenly
no
longer
dependent
on
the
underlying
service
mesh,
but
we
could
have
a
high
level
abstraction
in
here
in
how
to
do
it,
and
then,
obviously
we
have
coup
Benitez
as
the
controller,
that's
running
it
and
here's
an
example
of
how
flagger
is
handling
this
and
other
tools
out
there.
So
again,
what
you
see
here
is
more
code
like
here.
A
You
have
the
reference
on
top
for
the
workgroup
that
you're
running
at
the
lower
part
actually
contains
your
rollout
strategy,
which
again
is
a
different
file,
even
in
this
case,
store
again
in
a
different
tool.
So
it's
completely
separate
from
how
we
handle
application,
the
application
definition
piece.
B
Not
only
have
their
own
club
one,
the
topic
of
Anna
before
will
fly
some
thumbtacks.
If
we
take
a
closer
look
through
helm
again,
so
helm
actually
give
you
some
functionality
that
we
Adam
ation
like
awkward,
his
Shiro
back
and
the
lifecycle
who
carotid.
So
these
functionalities
are
more
fitting
fate
space
to
the
club
to
because
it
cares
about
the
application,
lifecycle
and
the
whole
instance.
It's
not
part
of
an
application
type
nation,
and
also
we
observe
that
being
helped.
We
have
released
it
the
Portuguese
trying
to
now
workers
only
a
topical
one
and
topic.
B
One
point,
five
more
so
I
think
it's
a
good
news.
Well,
let's
go
to
the
next
topic,
which
we
talked
three-eighths
about
workload,
instances
of
automation
and
operation,
so
the
were
closing
kubernetes,
including
many
things
like
deployments.
They
posted
demons,
a
job,
actually,
all
the
public
synchronize
the
gap
application,
but
it's
also
including
some
some
others.
Things
like
operator
right,
operating,
essentially
a
cosmetic
controller
with
the
main
knowledge
of
the
software
and
is
also
including
other
quarter.
B
Clacks,
open
crews
is
actually
a
bunch
of
customized
controller
for
you
to
to
to
forum
whoever
the
ones
the
staple
state
or
the
Vance
demons
they
its
thing
like
that,
but
he
may
ask
what
is
the
were
close
instances
right?
So
you're
close
instance
is
just
part
in
kubernetes
the
world,
but
you
should
know
that
it
can
be
something
else.
It
could
be
a
function
or
it
could
be
a
work
machine
being
some
other
cases.
B
So
just
one
example:
if
you
have
a
company's
deployment
with
replicas
equals
to
three,
you
basically
have
three
workload
instances
in
the
real
world,
they're
identical
to
each
other.
May
you
may
also
asking
other
questions
of
what's
the
difference
between
topic
two
and
topic
three,
so
it's
very
actually
straightforward
because
topic,
two
for
personal
application
level
operations
like
blue
green,
deploy,
narrow
deploy,
but
topics
three
workers
on
the
pod
level.
The
workload
instances
like
like
how
to
skilling
the
pods
how
to
scale
out
the
path
how
to
scale
up
how
to
be
the
state.
B
Certain
strategy
like
maximum
enables
what
makes
the
unavailable
stuff
so
another
function.
Contact
here
is
I,
don't
know
if
you
guys
for
about
the
epic,
a
zero,
the
author
of
the
project.
It
claimed
the
server
named
something
like
other
ones
deployment,
but
it's
not
a
deployment.
It's
a
topic
to
project
because
it
focus
mostly
on
the
application
level
management,
including
blue/green,
deploy,
narrow
deploy,
and
it
used
replica
stayed
from
kubernetes
to
handle
the
workload
instance
level
controller
which
is
top
3.
B
So
that's
why
we
can
see
it
is
actually
the
tip
called
topic
to
work
topic
through
project.
Ok
in
most
asked
question:
why
VP
couple
top
two
and
three
right:
just
we
don't
make
them
together
right,
for
example,
agarose
bloggers
are
all
work
together
right.
The
question
is:
can
we
do
flagger
canario
deployment
for
operator
based
applications
right
with
the
same
specs,
be
the
same
spec
spec
file?
Here
we
just
change
the
the
control
the
workload
targeted
wave
to
my
operator.
Can
this
work
I?
Don't
think
so,
but
it
should
work.
B
So
the
keep
one
here
that
today
applications
may
be
running
by
deployment
controller,
but
it
could
be
possible
by
stifle
set
or
even
operators.
So
how
can
we
wrote
these
kind
of
applications
by
using
the
same
strategy
like
an
arrow
deployment
for
operator
based
application?
They
should
work,
so
we
don't
think
it's
good
if
we're
under
the
narrow
cover
developers
by
using
over
topic,
2
capabilities.
We
don't
have
to
do
that.
This
show,
ladies.
The
developers
have
their
own
freedom
to
choose
whatever
workloads
they
want.
B
That's
a
keep
on
driving
that
one
to
de
Cobo
topic
2
with
topic
3
in
this
model
of
this
thing.
Ok,
so
let's
do
some
summary,
and
this
is
actually
interesting
question.
So
what
is
the
relationship
between
this
model
to
multi-cloud?
So
I
will
use
a
cross
plan
project
I've
example,
here
after
deep
dive
into
this
particular
two
bit
of
a
fund
that
the
multi
cloud
project
are
mostly
handling
this
part,
the
top
one
and
topic
1.5,
for
example,
at
least
a
hub
cost
plan
describe
its
application
here.
B
Essentially
it
it
bring
out
its
own
version
of
application
technician,
so
we
can
claim
ok,
this
is
the
llaman
fire
on
to
deploy.
This
is
the
CR
DS
I
want
to
deploy,
and
this
is
the
application
metadata
for
this
app
for
this
software,
so
that's
whole,
and
then
it
provides
you
with
the
top
two
one,
four
five
capability
for
you
to
package
them
as
an
application
stack
design,
cost
plan
itself.
Is
it
more
like
multi
core
scheduler,
so
it's
schedule
the
application
to
the
corresponding
cluster
by
using
certain
strategies
as
well.
B
That's
the
multi
cloud
project.
We
are
looking
at
today,
so
they're
actually
defining
application
technicians
for
you
that
and
we
are
look
at
application
packaging
for
you
and
then
deliver
this
software
by
using
this
definition
and
packaging
to
multi
called
to
multi
cloud
and
multicast
or
by
using
its
own
strategy.
So
this
is
relationship
between
these
kind
of
things.
Okay,
so
now
I
got
go
to
the
event
to
the
introduction
station.
A
So
we
will
just
ask
you
which
tools
you're
using
and
maybe
to
to
conclude
the
session
you
might
have
to
feeling.
Okay,
this
is
like
really
complicated
and
yeah.
It's
really.
Yes,
it
is
really
complicated
and
people
are
doing
a
lot
of
things.
So
what
was
the
value
of
really
creating
the
application
definition
model
here?
First
of
all,
we
wanted
to
cast
put
tools
in
to
a
specific
bucket
and
we
wanted
to
have
like
more
unified
language.
A
A
Hopefully,
you
get
a
good
cup
of
coffee
in
the
morning
or
tea,
whatever
you
prefer,
I
think
what
this
model
also
helps
us
to
do
when
we
define
our
own
processes
so
very
often,
especially
when
people
get
started,
working
with
a
platform
like
kubernetes
there
at
some
point,
super
happy
that
this
thing
finally
works:
okay,
first
of
all,
you're.
Finally,
the
super
happy
that
your
yellow
files
finally
work
and
you
can
deploy
them
without
any
errors.
Then
you
move
to
a
help
chart
and
it
is
super
helpful
early.
A
How
much
artworks
I
mean
super
then
you're
happy
that
the
parametrization
works
and
that
it
can
do
a
Bluegreen
deployment,
and
then
you
think
everything
is
great,
so
you
just
build
on
top
of
top
of
all
of
these
individual
entities.
I
think
you
have
never
really
thought
through
what
you
have
been
building
them,
but
this
model
helps
use,
maybe
to
separate
out
which
decisions,
whether
they
were
deliberate
or
not
deliberate.
A
You
have
taken
a
long
that
way
and
whether
there's
actually
a
clear
separation
or
a
certain
things
like
replacing
parameters
for
DD
application
packaging
parts
are
happening
as
part
of
your
deployment
strategy.
So
it
can
help
you
to
really
look
and
validate
what
you're
working
on
right
now
and
like
really
really
bad
weather
the
choices
and
the
separation
is
how
you
actually
want
it
to
be
with
what
you
might
have
today,
which
just
makes
you
very
happy
that
it's
actually
working
and
running
and
you
might
other
than
they
say.
A
If
you
just
collect
the
number
of
tools,
it
is
like
an
initial
input
on
what
will
eventually
go
into
a
landscape.
It's
not
going
to
be
the
final
one,
obviously,
but
just
for
us
to
see
which
those
people
are
using
out
there.
Instead
of
having
you
raise
your
hands
constantly
and
charting
tools
at
you,
so
I
think
we
have
a
couple
minutes
left
here.
So
are
there
any
questions?
So
we
also
want
to
make
this
interactive
at
this
point,
so
questions
comments
that
you
want
to
bring
up.
C
Thanks
so
I
mean
I,
really
appreciate
that
somebody's
actually
looking
at
this
because
I'm
finding
that
there's
not
enough
emphasis
put
on
this
particular
problem.
One
day
I
wanted
to
ask,
is
around
helm
and
you've
identified
several
areas
at
helm
plays
in,
and
you
know
one
could
say
that
it
kind
of
over
reaches
into
certain
areas
I'm
in
particular,
when
it
comes
to
things
like
get
ops.
If
somebody
wants
to
implement
a
get
ops,
delivery
model,
helm
generally
has
packaging,
so
it
has
its
own
versioning.
C
You
generally
need
to
publish
charts,
you
know
and
it
get
offs
model
you're
supposed
to
use,
get
and
therefore
use
commits,
and
so
you
know
when
you
draw
those
boxes
and
try
to
separate
things
out.
How
do
you
deal
with
those
types
of
things
where
tools,
in
particular
helm,
I,
would
say,
is
probably
guilty
of
this
more
than
other
tools,
kind
of
overreaches
the
boundaries
between
packaging.
C
You
know,
bundling
and
and
also
I,
would
say
so
helm,
especially
when
doing
you
know
air
gap
type
of
deployments,
you
need
more
than
helm
and
you
need
to
version
that
as
well
and
so
what?
What
is
the
cash
flow
general
approach
with
respect
to
existing
tooling
and
trying
to
align
things
in
a
way
that
makes
it
cohesive
going
forward?
C
A
You
might
want
to
get
back
on
the
help
piece,
maybe
before
we
talk
about
helm,
and
this
wasn't
supposed
to
be
a
session
against
helm,
but
overall
I
think
that
not
necessarily
every
tool
needs
to
play
in
one
area.
This
is
just
to
create
the
awareness.
Maybe
we
figure
out
that
certain
areas
are
so
closely
connected,
that
we
shouldn't
look
at
them
independently
per
se
and
also
have
like
tools
being
closer
to
camera
button
and
all
see
paths
are
what
are
you
mad
for
Mel
I.
E
If
you
don't
know
I'm
one
of
the
hell
maintainer
x',
so
this
is
one
of
the
things
we've
thought
a
lot
about,
and
in
so
at
least
in
my
view,
it's
not
so
much
about
breaking
it
down
into
parts
of
the
model.
Some
of
this
may
seem
a
little
bit.
You
know
the
UNIX
model
and
piping
tools
together
to
solve
problems
right.
But
what
a
lot
of
folks
need
is
something
that's
a
complete
solution.
That
does
thing
right.
E
E
E
And
so
it
doesn't
map
perfectly
to
all
of
these
things,
because
it's
solving
a
kind
of
a
usability,
a
user
combined
problem
and
and
there's
different
things,
whether
you're
doing
ops,
whether
you're
packaging
and
sharing
things,
whether
using
get
ops
or
whether
using
a
different
model
because
there's
a
bunch
of
models.
People
use
and
you're
gonna
use,
different
tool,
chains
and
I.
Think
figuring.
That
out
and
coming
up
with
good
solutions
is
going
to
come
up
with
lots
of
different
stuff
and
like
you've,
brought
up.
E
Air-Gap
helm
isn't
great
for
air-gap,
which
is
why
you
see
other
package
management
solutions
coming
along
like
C
NAB,
which
deals
with
that,
and
it
was
designed
specifically
with
things
like
air-gapped
in
mind.
So
I
think
when
you
start
looking
at
what
a
problem
is
and
how
do
you
make
all
holistic
solution,
it's
a
little
bit
different
than
the
tools
to
piece
together
in
a
UNIX
philosophy,
but
some
people
want
both
and
so
having.
All
of
it
is
probably
useful,
at
least
that's
my
take
I'm
happy
to
talk
more
about
it.
A
Did
you
have
a
question
yeah
while
I'm
working
over
there,
so
by
the
way
there
will
be
also
as
part
of
cqf
delivery?
There
was
a
lot
of
requests
also
yesterday
about
air
gapped
systems.
So
more
and
more
people
are
approaching
us,
so
we
will
have
a
dedicated
discussion
about
air
gapped
systems,
specifically
within
one
of
the
next
meetings
and
I
think
we
will
be
kicked
out
pretty
soon,
but
I
still
want
to
give
it
a
chance
to
ask
a
question.
F
So,
in
that
same
vein,
oh
there
there's
you
don't
check
your
built
containers
in
to
get
to
do
your
get
offs
and
and
helm
to
some
extent
a
help.
Akka
jizz,
a
coupling
of
the
the
packager
of
the
software
and
the
actual
deployment
thereof,
and
so
the
values
that
you
do
when
creating
a
release.
That's
the
thing
you
do
in
get
ops
and
the
development
of
the
helm
chart
is
a
separate
thing.
A
D
D
So
what
I'm
missing
in
the
application
definition
is
service
level
indicators
and
objectives,
so
you
need
a
way
to
check
whether
your
application
is
really
healthy
and
also
if
it,
if
your
application
is
in
protection,
you
need
some
way
to
to
trigger
a
remediation
action.
So
this
should
also
go
along
with
the
application,
and
this
is
not
managed
by
helm.
Yet
so
I'm
missing
here
some
input,
I.
A
B
It's
a
good
input
yeah,
so
this
party
I
think
are
missing
from
all
remote.
Oh,
so
we
are
thinking
about
that
because
it's
very
complicated
in
the
real
world
of
project
related
to
that,
but
they
aren't.
All
of
them
are
not
focused
on
that
part
of
single
by
by
themselves,
so
think
about
okay.
What
is
a
real
model
for
these
application
definition?
So
why
not?