►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
TAG App Delivery - Jennifer Strejevitch, VMware & Alois Reitbauer, Dynatrace
TAG App Delivery focuses on simplifying application delivery on Kubernetes as well as improving developer experience. This session will showcase recent development around operators, chaos engineering, application delivery methods and demo applications. Whether you are just getting started with cloud-native application deliver or getting up to speed on the latest this session will provide you with ongoing activities, recent developments and selected trends based on feedback from CNCF projects in the app delivery space.
A
A
B
A
So
let's
talk
a
bit
about
what
we're
doing
when
the
focus
is
where
it's
supposed
to
be
yeah.
If
you
have
any
questions
and
are
on
the
live
stream,
I
know
that
there
is
a
dedicated
channel
for
the
session
for
the
maintainer
track,
where
you
could
obviously
ask
questions
as
well,
but
usually
this
channel
gets
very
crowded.
A
So,
ideally,
you
go
directly
to
the
tag
app
delivery
channel,
which
is
where
most
of
the
app
delivery
work
is
happening
as
well,
and
it
will
also
exist
or
you
can
ask
questions
and
continue
them
after
the
conversation
as
well
so
yeah
before
we
get
started,
we
have
actually
an
awesome
logo.
If
you
didn't
notice,
maybe
you
notice
we're
in
the
keynotes.
This
is
the
kangaroo
now.
The
question
is:
what
does
tag
app
delivery
do
beyond
having
a
really
awesome
kangaroo
logo,
which
obviously
makes
sense
because
delivering
applications?
A
That's
a
bit
squeaky
here.
So
what
does
this
comprise?
First
of
all,
it's
application
definition
like
how
do
we
actually
find
applications
in
kubernetes
and,
if
you
think
about
it?
Well,
we
all
have
like
all
the
yaml
and
kubernetes
primitives
to
model
all
the
components.
But
how
do
we
define
like
what
an
application
is
like
defining
it
as
a
whole?
A
Not
just
the
services
that
we're
using
the
deployments
we're
using,
but
all
the
things
that
are
related
to
it
say:
storage
classes
that
we
need
passwords,
that
we
need
to
manage
access
to
external
systems
and
so
forth,
guidance
and
practices
for
application,
design
and
development
to
be
fair.
This
is
an
area
where
we
did
not
invest
a
lot
of
time
in
the
past.
A
I
think
we
don't
see
it
as
our
responsibility
to
tell
you
how
to
build
your
applications,
but
now
with
as
we'll
come
to
later
from
the
working
groups
that
we
have
right
now,
we
kind
of
are
getting
into
this
area
on
a
very
specific
topic.
So,
for
example,
now
how
we
can
bring
infrastructure
as
code
and
like
application
shipment
closer
together,
it's
one
of
the
areas
that
we
will
discuss
for
some
time.
A
We
had
a
working
group
that
then,
obviously
during
the
last
two
years,
because
people
were
too
busy
resolved
on
air-gapped
environments,
so
how
to
deliver
kubernetes
applications
in
an
air
gap
environment
which
brings
us
to
the
next
topic,
which
is
application
bundling
and
deployment.
So
how
can
you
bundle
an
application
and
ship
it
package
management?
A
Obviously
the
whole
application
delivery,
workflow
and
strategies.
So
these
are
the
100,
the
delivery
tools
that
you're
using,
but
also
defining
which
application
strategies
that
we
have.
There's
this,
I
think
now,
almost
famous
as
a
quote
from
kelsey
hightower,
he
said
used
to
say
he
can't
see
any
more
kubernetes
demos
doing
cannery
deployments.
A
Yes,
that
might
be
true,
but
still,
if
you
look
at
all
the
tools
that
are
out
there,
how
can
reads
are
actually
defined
and
how
they
are
deployed
is
highly
different
from
the
individual
tools
that
you're
using
yeah
and
configuration
source,
driven,
workflows
and,
last
but
not
least,
release
management.
So
we
really
don't
want
to
stop
where
just
by
shipping
the
application,
but
obviously
also
handling
the
application
until
its
retirement
from
production.
So
that's
like
the
broader
charter
scope
of
what
we're
doing
just
to
understand.
A
I
have
added
this
in
here
because
I
find
it
kind
of
like
super
helpful
to
describe
a
bit
how
like
the
application,
delivery
work
relates
to
everything
else.
That's
going
on
in
kubernetes.
This
was
actually
done
by
lee
sang,
who
used
to
be
co-chair
and
founding
member
also
of
tech.
App
delivery
like
how
like
different
bits
and
pieces
are
related
to
each
other.
A
So
what
you
can
see
here
like
on
on
the
lowest
level
you
have
like
the
platform
like
research
management,
the
container
life
cycle,
networking
so
pretty
much
everything
what
you
need
as
a
platform
to
build
your
application,
and
that's
also
the
part
that
we
say:
okay,
that's
out
of
scope
for
attack
app
delivery.
This
is
the
these
are
the
bits
and
pieces
that
are
handled
by
other
tags.
A
However,
the
first
three
topics
are
the
ones
that
we
actively
work
on.
I
already
mentioned
application
definition,
so
this
is
really
about
having
an
application
descriptor
having
an
application
model
like
how
do
we
model
what
an
application
is?
How
do
we
kind
of
package
it?
How
do
we
make
it
understandable?
There
are
some
projects
within
the
cncf
that
try
to
model
applications
that
try
to
refine
a
language
for
applications,
but
it's
not
like
widely
used
for
a
lot
of
people.
A
A
This
becomes
even
more
interesting
as
we
now
talk
about
secure
software
supply
chains,
obviously,
and
also
this
air-gapped
environments.
So
how
do
I
take
everything
that
I
need
to
deploy
an
application
bundle
it
and
ship
it?
This
goes
in
directions
of
obviously,
projects
like
porta,
for
example,
where
I
can
take
an
entire
bundle.
So
I
don't.
I
need
more
than
just
the
helm,
charts
and
some
of
that
information,
the
values
files.
A
I
also
need
to
bundle
in
the
containers
they
need
to
ensure
that
they're
in
the
proper
place
so
that
it
can't
be
installed,
then
obviously,
the
rollout
and
life
cycle
management,
so
everything
from
configuration
driven.
Obviously
we
will
be
talking
about
githubs
in
a
bit
then
rollout
strategies
that
we're
defining
and
also
how
we
deal
with
traffic
management,
which
is
obviously
closely
related
to
rollout
strategies
as
well.
If
you
think
of
like
cannery
deployments.
A
Yes,
you
have
to
deploy
the
application
properly,
but
on
an
ingress
level
or
load
balancer
level.
You
also
need
to
define
how
information
should
be
routed,
and
then
everything
from
regarding
to
this
is
where
the
overlap
comes
like,
with
the
platform,
about
instance,
healing
scaling
out
shorting
and
also
managing
the
life
cycle.
A
Also
for
your
involvement.
If
you
either
have
said
well,
we
have
built
this
and
we
think
we
have
built
something
amazingly
great
or
we
are
building
it
that
we
have
built
this
and
we
ran
into
certain
issues
which
we
think
should
be
solved
in
a
better
way,
also
feel
free
to
interact
with
us
either
by
sharing
your
use
case,
your
architecture,
your
model
that
you're
using
or
coming
to
us
with
your
questions
and
then
collaborating
with
other
people
on
these
topics.
A
There's
a
number
of
working
groups
within
tech,
app
delivery.
So,
just
for
your
understanding
before
I
pass
over
to
to
jennifer
I'll
just
show
you
what
all
the
bits
and
pieces
that
we're
working
on
usually
tags
do
mainly
two
things
that
support
the
toc
on
due
diligence
for
projects
which
we'll
talk
about
in
a
while,
and
they
also
look
into
new
areas
where
we
should
decide.
Okay,
there
is
some
work
that
should
needed
to
be
done
and
engaged
there.
A
The
first
one
was
the
operator
white
paper
working
group,
which
well
did
what
the
name
actually
comprised.
They
brought
the
white
paper
on
operators
who
of
you
here
in
the
room
is
using
operators
today
also
actively
developing
them
good.
What
we
did
here
was
well.
We
had
all
this
like
notion
of
an
operator
and
it's
like
kind
of
like
super
central,
but
there
was
no
detailed
white
paper
how
to
develop
them.
What
the
principles
are
and
so
forth
and
jennifer
can
give.
A
I
will
give
a
bit
more
insights
because
she
was
driving
a
lot
of
these
activities.
Then
there's
obviously
the
github's
working
group
there's
two
new
working
groups
that
are
currently
forming
the
chaos
engineering
working
group
like
really
covering
chaos,
engineering
from
a
very
wide
number
of
aspects.
A
The
corporate
delivery
working
group,
which
we'll
also
touch
base
on
which
thinks
of
how
can
we
bring
the
app
development
infrastructure
closer
together
and
solve
some
issues
that
usually
arise
there
and
also
the
potato
head
reference
implementation
that
came
out
of
a
cube
contact
which
we
did
a
while
back
that
more
or
less
allows
you
to
use
a
reasonably
complex
but
still
easy
to
deploy.
So
you
can
run
on
your
local,
laptop
application
and
test
out
different
tools,
test
out
different
strategies
and
jennifer
I'd
like
to
pass
over
to
you.
A
A
Well,
of
course,
you
could
wait
there
sure
I'm
doing
it
right
so
that
that's
actually
what
the
githubs
working
group
was
about.
So
they
wanted
to
build
a
spender
and
neutral
way
really
to
define
and
drive
the
adoption
of
githubs.
The
idea
was
everybody's
kind
of
doing
git
ups,
but
but
what
what
is
github's?
Really?
How?
What
should
you
do?
What
do
you
take
care
of?
What's
the
difference
between
just
more
or
less
doing,
a
cube
control
apply
from
what
you
have
in
the
git
repo
versus
actual
githubs
based
workflows
or
beat
ups
based
interactions?
A
They
also
created
the
open,
git
ops,
sandbox
project,
which
you
can
find
under
open
depth.
They
will
find
the
github's
principles
so
that
you
find
a
number
of
principles
like
what
a
github
solution
should
be
doing
they're
running,
obviously
a
lot
of
events.
The
idea
is
to
also
have
like
reference
and
training
material
that
they're
developing
around
it
and
there's
quite
some.
A
Some
companies
erectively
participating
in
there,
as
mentioned
the
github's
principles,
and
the
glossary
have
been
released
pretty
recently
and,
as
you
can
see,
there's
like
a
lot
of
conferences
and
work
that
they're
running
on
right
now,
like
git
ups
con
argo
con,
the
github's
one
stop
shop,
which
I
think
is
happening
at
the
end
of
october.
So
there's
constantly
events
related
to
pdops
as
well.
So
I
definitely
recommend
to
check
this
out.
They
also
had
a
session
here
and
that's
one
of
the
areas
that
we're
working
on.
B
Hi,
yes,
the
operator
working
group
is
very
exciting
to
me
because
it
is
how
I
joined
the
tag
up
delivery.
It's
finished
now,
but
we
achieved
a
great
milestone
very
recently,
which
was
the
operator
white
paper,
and
I
some
good
things
about
it.
Is
that
it's
really
it's
entirely
community
driven.
It
was
not
just
us
like.
We
received
a
lot
of
help
and
thank
you
everyone
for
that.
They
operator
white
paper
provides
a
deep
but
like
non-exhaustive
overview
of
operators
in
cuban
artists,
but
also
beyond,
not
just
thinking
of
kubernetes.
B
It
gives
you
a
definition
of
the
operators
of
operators
and
how
they
can
be
used.
It
also
dives
deep
in
the
security
issues
and
use
cases
which
was
a
help
from
the
tag
up
delivery.
They
like
contributed
massively
to
this
part.
Also
thank
you
on
that,
and
there
are
also
use
cases
for
operators
used
at
patterns,
but
also
somehow
to
look
into
the
future
because
it's
ever-changing.
B
Now
there
are
some
insights
into
the
operator
design
and
yeah
like
it's
made
for
as
well
as
for
the
people
who
already
are
familiar
with
operators,
but
it's
a
great
introduction,
because
it's
not
as
exhaustive
as
a
big
book
and
not
as
short
as
a
blog
post.
It's
really
it's
a
white
paper,
but
it's
a
great
starting
point
for
people,
because
it
also
links
you
to
several
resources
that
dives
deep
in
different
areas
that
are
most
interested.
So
there's
a
lot
of
sources
there
as
well
yeah.
B
A
Well,
we
have
the
short
definition
as
part
of
kubernetes
what
the
operator
pattern
is,
but
do
we
like
really
know
like
what
an
operator
is
and
what
it
isn't,
and
I
really
recommend
reading
it,
because
many
people
are
amazed
that
you
could
actually
build
an
operator
that
is
actually
not
running
in
kubernetes.
It
might
be
way
more
work,
but
you
could
also
use
the
operator
white
paper
there,
maybe
also
important,
if
you
find
anything
that
you
don't
like
our
all.
A
B
B
So
we
want
to
integrate
chaos
into
the
application
delivery,
workflows
such
as
continuous
delivery
processes,
and
we
also
want
to
show
good
practices
for
complex
testing
scenarios
such
as
multi-tenant
systems
and
hybrid
cloud
native
environments
and
yeah.
So
like
the
working
group
will
also
elaborate
on
what
users
and
organizations
in
the
cloud
native
world
mean
like
when,
when
in
terms
of
practices
when
they
have
adopted
chaos
engineering,
because
we
are
like-
I
adopted-
chaos
like
what
is
that,
and
there
is
like
a
good
definition.
We
want
to
get
into
a
definition
of
that.
B
So
the
working
group
is
working
on
that
by
talking
to
end
users
and
under
having
an
understanding
of
the
current
landscape,
and
they
will
also
focus
on
the
security
perspective
by
ensuring
resilience
is
maintained
at
all
times
and
also
develops
some
use
cases
for
security
chaos.
Engineering
to
validate
that
the
security
controls
are
changes
to
the
controls
happening,
that
rapid
fashion
to
mitigate
active
attack
scenarios.
B
A
Yeah,
I
think
that
they're,
really,
I
think,
jennifer
described
it
very
nicely.
This
is
an
effort
that
is
currently
just
like
getting
started.
So
if
you
are
interested
in
chaos,
engineering
or
planning
to
feel
free
to
contribute
and
again,
contributions
does
not
mean
that
you
actively
work
like
on
the
white
paper
or
anything.
Just
if
you
have
questions
say
hey,
we
are
currently
starting
to
get
work
work.
We
started
to
work
on
case
engineering
and,
like
these
are
five
or
six
top
questions
that
we
have
or
top
three
whatever.
A
A
This
works
hey.
I
understand
this,
I'm
a
bit
unclear
what
you
mean
here.
This
is
also
super
helpful,
so
don't
overthink
that
your
contribution
must
be
to
be
like
part
of
every
meeting
or
to
actively
write
something,
because
eventually
we
do
this
for
the
wider
community
and
if
you
think
well,
I'm
not
like
necessarily
understanding
what
you
hear
and
it
would
need
some.
There
are
other
questions
that
I
want
to
like
get
answered.
That
is
super
helpful
as
well.
A
This
is
going
to
be
a
super
challenging
activity
because,
as
you
can
see
here,
there's
like
a
lot
of
text
involved
so
jennifer
pointed
out
it
started
in
app
delivery.
Then
we
had
network
chaos.
So
that's
how
tag
network
got
involved
and
we
had
security
chaos.
That's
how
tag
security
got
involved.
If
you
think
about
attack
security
has
another
role
because
for
chaos,
engineering
most
of
those
experiments
have
massive
access
to
the
cluster
like.
A
How
can
you
simply
kill
parts
or
change
network
routes
or
do
all
those
funky
things
that
a
case
engineering
tool
can
do
like
from
a
security
perspective?
It's
kind
of
interesting
and
then
last
but
not
least,
tag
observability
got
involved,
because
you
want
to
know
whether
your
chaos
experiment
actually
works.
It
does
not
work,
so
this
is
going
to
be
a
very
interesting
activity,
the
second
one
currently
so
jen.
I
would
take
this
and
then
pass
over
to
you
for
the
project.
If
this
is
fine.
B
The
first
goal
of
our
working
group
is
to
understand
how
people
are
tackling
this
coordination
problem
right
now
and
create
examples,
and
so
in
the
future.
We
hope
that
we
identify
the
gaps
that
could
I
aid
new
solutions.
So
all
like
again,
community
driven
identify
the
gaps,
be
able
to
inform
everybody
and
show
the
examples
that
are
used
in
the
real
world
and
and
then
that,
then
maybe
people
can
come
with
different
new
projects
to
solve
those
problems.
A
Yeah
and
you
can
see
in
this
example-
there
are
lots
of
tools
out
there,
but
usually
they
focus
on
one
or
the
other
aspects,
so
some
focus
on
the
application
delivery.
That's
what
you
see
in
the
right
picture
here,
like
you,
have
argo
flux,
captain
spinnaker
and
then
you
have
the
more
infrastructure
focused
tools
like
cross,
plane,
anti-blow,
pollumi
and
lots
of
virus,
but
how
do
we
bring
them
together?
A
A
A
If
you
feel
that
you
have
questions
or
ran
into
problems
or
found
interesting
solutions,
just
get
in
touch
with
us
and
let
us
know
it
doesn't
need
to
be
super
formal,
but
let
it
know
yeah,
I'm
taking
this
one,
because
this
is
actually
a
funny
and
interesting
one.
Last
year,
kubecon
north
america,
I
did
a
talk
also
as
part
of
app
delivery.
You
know
like
there
was
this
whole
scene
like
the
whole
cloud
native
landscape,
it's
getting
so
bloated.
A
A
A
How
do
you
handle
configurations
in
there
how
to
update
in
a
canon,
redeployment
state
for
workloads?
These
are
problems
that
don't
require
an
application
to
be
necessarily
very
complex
from
the
co-perspective,
but
the
scenarios
that
you
need
to
handle
from
an
up
delivery
perspective
might
be
complex.
That's
why
we
saw
a
sock
shop,
was
not
the
ideal
fit
there.
So
we
wanted
to
build
something
more
lightweight
and
said:
okay,
we
built
a
new
application
and
what
are
you
going
to
build
as
a
micro
service
application?
A
Then
we
thought
it
is
yeah,
it's
done
it's
out
there
and
suddenly
we
saw
people
contributing
more
and
more
examples
to
it,
and
you
see
right
now,
there's
like
a
showcase
for
how
to
deploy
an
application
with
helm
with
customize,
with
sketch,
with
cap
with
flux,
with
argo,
with
captain
cnip,
with
porter
even
offline
with
cubevela,
with
gimlet
and
more
and
more
of
those
coming
up
as
people
are
constantly
adding
them.
Initially,
it
was
just
like
one
very
small
services
now
like
the
individual
body
parts
and
so
forth,
are
individual
services
again.
A
This
was
contributed
by
the
community
and
it's
currently
actively
developed,
and
there
are
companies
today
who
told
us
that
they're
using
this,
the
potato
head
application
to
educate
their
teams
and
how
they
can
use
different
tools
or
to
easily
evaluate
them
so,
rather
than
like
going
to
15
tools
looking
at
their
demo
application.
It's
like
this
one
spot
where
you
can
experiment
with
a
demo
application
which
we
will
also
use
in
in
other
scenarios,
and
so
far
everybody
thinks
it's
also
a
pretty
funny
way
of
doing
application
delivery.
A
And,
yes,
you
can
do
really
funny
things.
You
can
do
cannery
deployments,
as
you
can
see
on
this
picture
here
where
the
left
foot
is
different
from
the
right
foot
and
you
would
even
see
it
here
as
well
and
again
you
can
run
it
on
your
local
machine.
You
can
run
it
in
a
mini,
cube,
cluster
and
experiment
with
it,
because
it's
not
really
heavy.
A
These
are
like
tiny,
tiny
go
binaries
that
that
you're
running
that
you
can
work
with
also,
obviously,
if
you're
interested
feel
free
to
contribute
to
take
one
of
those
issues.
So
there's
now
constantly
ongoing
development
another.
If
you
pick
an
example
incubating
projects
jennifer,
do
you
want
to
talk
about
the
projects
that
we
were
working
on.
B
Yeah,
so
they
these
projects,
they
have
presented
their
proposals
under
the
tag
up
delivery.
Some
of
them
have
graduated
to
incubation
already.
So
this
is
a
little
overviews
like
we
provide
some
recommendations.
We
help
them
throughout
the
process.
It's
done
by
the
toc,
but
we
like
we
give
help
when,
whenever
needed,
with
the
due
diligence
process,
so
they're
currently
incubating
projects
well
cross
plane
is
being
has
passed
already
at
the
time
of
this
slide.
So
there
is
that
dapper.
There
is
argo.
B
That's
applying
for
graduation
as
well
limited
scales,
that's
applying
for
incubation
and
captain
as
well.
That's
in
like
incubating
phase
yeah.
So
if
you
like,
you'd
like
to
get
more
involved
in
any
of
these
projects,
you
can
also
review
their
proposal,
pull
requests
on
github
and
show
your
support
as
well.
That's
like
also
helps
them
a
lot
and
yeah
like
watch
their
the
presentations
that
they
have
on
their
own
hour
tag
meetings.
A
Yeah,
I
think
that's
a
very
good
point
so,
especially
if
you
want
to
stay
up
to
date
on
projects.
The
the
channel,
because
we
have
bi-weekly
meetings
is
like
super
helpful,
because
you
see
new
projects
that
are
presented.
Also,
if
you
yourself
have
a
project,
we
also
have
presentations
from
projects
that
don't
necessarily
want
to
become
a
cncf
project,
but
that
some
people
have
just
worked
on
or
a
tool
that
you
have
worked
on
also
feel
free
to
come
and
present.
A
So
maybe
you
find
people
who
are
also
interested
in
it
find
some
contributors
there
find
other
people
who
might
be
using
it
like
we
had,
for
example,
a
this
is
a
nice
tool
called
gimlet
that
was
presented.
That
came
in
like
we're
contributing
to
potato
head,
and
we
had
it
in
as
part
of
the
meetings
and
people
got
interested
and
also,
if
you
want
to
like,
really
see
what
some
projects
are
doing,
feel
free
to
join
our
look
at
the
recordings
where
we
have
some
of
this
information
available
as.
A
A
A
A
Maybe
you
do
a
15-minute
short
presentation,
nothing
fancy
as
part
of
the
the
meeting
so
that
other
people
can
learn
what
how
other
people
have
built
their
stack,
what
problems
they
were
running
into
which
how
they
solve
certain
problems
also
generally
come
and
share
your
knowledge
feel
free
to
say
well.
This
is
a
question
that
I
have.
This
is
something
else,
so
we
can
either
join
as
I'll
show
in
a
minute
our
slack
channel
or
the
mailing
list
or
just
just
come.
Ask
a
question.
Start
a
discussion
or
slack
channel.
A
You
can
help
by
con
to
contribute
to
to
documents,
as
I
mentioned,
if
you're
afraid
to
write,
that's
totally
cool,
you
don't
have
to
trust
me.
Reviewing
documents
is,
in
some
cases
a
much
harder
job
than
getting
the
first
version
done,
and
people
who
review
contribute
and
help
with
this
super
helpful
as
well,
and
if
you
want
to
write
code.
That
is
great
too
help
us
work
on
the
examples.
A
So
whatever
concerns
you,
where
do
you
find
us
again?
We
have
a
great
logo
as
the
kangaroo.
If
you
go
to
github
on
github
cncf
tag
app
delivery,
you
find
pretty
much
every
information
about
where,
when
our
meetings
are
happening,
charters
of
the
working
groups
documents
like
the
operator
white
paper
is
available.
There
there's
also
a
slack
channel
for
tech,
app
delivery,
which
you
would
like
meant
to
join.
There
are
also
by
the
way,
dedicated
slack
channels
for
the
individual
working
groups.
A
So,
if
you're,
looking
like
for
the
cooperative
delivery
one
for
the
chaos
engineering,
one,
you
will
find
dedicated
slack
channels
there
as
well,
so
that
people
can
have
dedicated
conversations
as
well,
but
if
you
just
need
help
to
find
your
way
around
to
figure
out
how
to
engage
here.
Just
let
us
know-
and
we
are
more
than
happy
to
help-
and
I
think
with
this
we
have
theoretically
minus
three
minutes
for
questions.