►
From YouTube: CNCF TAG App Delivery 2021-08-04
Description
CNCF TAG App Delivery 2021-08-04
A
A
A
C
D
B
E
For
you,
yes,
sorry,
but
I'm
now
in
bit
was
in
between
meetings
here,
but
I
did
not
want
to
miss
this
one.
So
I'm
really
what's
very
much
looking
forward
to
this.
So
thanks
for
taking
the
time
it's
been
a
bit
yeah,
I
think
that
we
can
jump
right
into
so
now.
I
think
we
can't
have
jump
right
into
that
presentation,
as
you.
F
Okay,
well,
thank
you
for
having
us.
We
should
introduce
ourselves
first
yeah.
My
name
is
mark
fussell
and
I'm
one
of
the
co-creators
of
dapper
and
helped
start
the
project
two
one
one
or
two
years
ago.
I
currently
work
at
microsoft
and
have
worked
at
microsoft
for
a
number
of
different
years,
and
men
have
been
heavily
involved
with
developer
technologies.
For
most
of
my
career.
C
Yep
hi
everyone,
my
name
is
your
own,
also
co-creator
of
the
dapper
project.
I've
been
working
microsoft
for
five
years
before
that,
mostly
working
in
startups
and
the
cloud
native
space.
I
also
co-founded
the
kita
project
instead
of
microsoft
and
was
a
maintainer
in
the
past
yeah
and
I'm
also
a
maintainer
on
the
dapper
project.
Happy
to
be
here.
F
F
F
F
F
You
know
why
we
think
it's
a
good
proposal
for
the
incubations
and
sort
of
giving
sort
of
different
perspectives
feel
free
to
ask
us
questions
as
we
go
we're
kind
of
time
for
questions
at
the
end,
but
sometimes
it's
much
easier
to
ask
them
as
we
go
along,
because
you
know
we
have
the
context
of
that
particular
time.
But
at
the
end
of
this,
hopefully
you'll
have
an
appreciation
of
what
dapper
is
and
how
we
think
it
has
been
transformational
actually
in
the
developer
community
that
we're
seeing
in
sort
of
with
cloud
native
applications.
F
So
so
what
is
dapper
we
think
of
dapper
and
describe
it
as
a
sort
of
run
time
for
building
cloud
native
applications
focused
entirely
on
developers
how
developers
write
code
in
many
ways?
It's?
How
do
we
take
best
practices
and
turn
them
in
to
make
developers
productive,
but
at
the
heart
of
this
is
a
set
of
developer
friendly
apis
that
allow
them
to
reliably
connect
services
to
be
able
to
communicate
and
discover,
and
do
things
like
secure
communication
retries
inside
all
that
to
be
able
to
handle
long-running
stateful
services
better
handle
state.
F
So
you
create
long-running
tasks
and
inventor
failure
recover
and
then
handle
sort
of
events
at
scale.
Do
pub
sub
messaging,
handle
events
from
external
systems
and
communicate
about
external
systems,
and
when
you
put
these
easy-to-use
apis
together
and
build
it
onto
particular
platforms
like
kubernetes
or
docker
swarm
or
just
a
set
of
vms,
it
makes
developers
build.
F
And
at
that
point,
that's
where
things
really
started
to
take
off,
because
people
you
know
saw
a
stable
release.
They
understood
that
dapper
was,
you
know,
could
be
taken
into
production,
and
it's
really
since
february
that
we've
seen
a
lot
of
the
production
usage
take
off
and
some
bigger
fortune,
500
companies
and
larger
organizations
take
a
bet
on
it.
We
submitted
it
to
the
cncf
back
in
march
and
then
just
to
show
that
since
then
you
know
we
just
do
regular
releases.
F
You
know.
So
what
is
dapper
and
what
is
its
goals
at
its
heart?
You
know
we
took
a
lot
of
the
best
practices
that
we
saw,
people
struggling
with
when
they
built
cloud
native
applications.
How
do
I
communicate
between
services?
How
do
I
sort
of
even
handle
things
like
secrets,
management
in
my
applications
and
to
codify
them
into
sort
of
best
practice
building
blocks
and
the
key
is
dapper
is
really
focused
on
any
developer
and
any
framework.
F
F
F
You
know
effectively
these
http
or
grpc
apis
expose
a
set
of
what
we
call
building
blocks
and
so,
for
example,
the
service
to
service
invocation
building
block
allows
you
to
spin
up.
You
know
one
piece
of
code,
a
process
or
a
service
and
talk
to
another
piece
of
code,
and
it's
responsible
for
saying
you
know
these
two
pieces
of
code
have
sort
of
named
identities
to
them.
I
can
call
from
one
service
to
another.
I
could
do
that.
F
It
will
discover
where
those
pieces
of
those
services
are
running
say
inside
your
kubernetes
cluster
inside
you
know
your
pods
that
have
been
deployed,
it'll
do
secure
communication.
If
the
messages
fail,
it'll
do
retries,
and
so
it
takes
care
of
all
that.
You
know
hard
work
that
you
have
to
do
as
a
developer
or,
for
example,
take
state
management.
F
It
allows
you
to
have
an
api
that
saves
key
value
pairs,
so
you
can
save
the
state,
you
know
of
your
shopping
cart
or
of
a
workflow
process
or
like
a
gaming
session
state,
and
so
in
the
event
of
failure.
You
can
recover
that
state,
and
so
it
makes
it
very
straightforward
for
people
to
build
sort
of
stateful
long-running
applications
that
they
can
depend
upon.
Those
state
that
can
hook
up
to
any
state
store
of
their
choice.
It
could
be
gcp
firebase
or
it
could
be
aws.
F
You
know
what
are
they
joe's
state
stores
or
it
could
be?
You
know
an
azure
state
store
or
it
could
just
be
a
local
mongodb
if
they
wanted
to.
So
you
know
that
flexibility
allows
them
to
be
able
to
say
that
they
can
confidently
write
their
code
and
what
makes
it
so
key
to
them
is
a
code
becomes
portable,
so
you
actually
have
cross
portability.
F
So
then,
any
developer
can
use
these
apis
from
any
framework
of
their
choice.
They
can
just
call
them
over
http
or
grpc.
Adapter
also
provides
built-in
first-class
sdks
for
those.
If
you
want
a
particular
language
friendly
syntax,
so
we
have
java,
node,
javascript,
dot
net
and
all
sorts
of
other
apis.
In
fact,
php
was
one
that
was
developed
by
the
community,
so
you
can
have
a
sort
of
a
more
friendly
experience
and
then
the
hosting
infrastructure
adapter
will
run
on
any
host.
It
can
run
on
just
sort
of
vms.
F
C
C
So
you
know,
unlike
a
service
mesh,
for
example,
which
really
operates
at
the
network
layer
dapper
has
developers,
you
know
contacting
it
as
a
set
of
apis,
so,
for
example,
this
is
how
you'd
use
the
http
api
to
try
and
discover
a
different,
app
called
cart
on
the
first
line
there
with
the
method
of
new
order.
The
second
line
shows
you
how
you
can
get
state.
C
The
third
line
shows
you
how
you
can
publish
a
message
to
a
particular
topic
and
then
the
fourth
line
shows
you
how
you
can
you
know,
get
secrets
from
some
secret
provider
that
you
configured
in
this
case.
It's
called
key
vault
and
then
get
the
password
name.
So
this
is
a
very
simplistic
example
of
how
the
adapter
apis
are
being
exposed
to
the
application
through
the
sidecar.
C
Now,
because
the
sidecar
operates
in
in
localhost,
dapper
also
exposes
a
set
of
security
primitives.
This
is
something
that
you
know:
we're
not
gonna
touch
on
a
lot
in
this
conversation
today,
but
dapper
really
is
really
security
focused
in
mind.
We
also
had
a
security
audit
done
in
place
by
cure53,
which
did
a
lot
of
audits
for
cncf
projects,
and
we
take
like
inner
pod
communications,
also
something
that
that
needs
to
be
secured,
so
the
security
boundary
for
us
you
know,
is
also
inside
of
the
pod.
C
Just
because
you
know
you
have
these
apis,
that
you
call,
and
so
the
opera
also
provides
api
token
and
and
certificate
management
capabilities
for
both
outer
pod
and
inner
pod
communications.
So
this
is
the
way
that
the
application
would
basically
consume
the
sidecar
on
kubernetes
these
side
cars
are
injected
using
a
sidecar
injector,
which
is
a
control
plane
pod
that
we're
running
on
the
user's
kubernetes
cluster.
C
And
this
shows
the
extensibility
points
of
dapper.
We
mentioned
that
we
have
plugable
components,
so
you
know,
for
example,
if
you
want
your
app
to
be
triggered
by
an
event,
that's
coming
in
from
a
binding,
an
input
binding,
so
you
know
twilio
event
or
a
kafka
event
or
another
sqs
or
gcp
pub
sub
event.
Users
can
using
any
language,
can
just
configure
these
components
and
then
have
their
apps
triggered
by
these
systems.
C
For
example,
you
won't
find
that
in
the
open
source
implementation,
but
with
dapper,
we
actually
added
it
so
users
using
redis
through
dapper,
can
actually
get
these
advanced
features,
and
that's
just
one
example
of
these.
So
developers
and
operators
can
basically
set
up
these
state
stores
or
pub
subs
using
you
know
whatever
environment
they're
running
in
so,
if
you're
running
locally,
you
might
have
a
redis
container
set
up.
F
F
Yes,
yeah
yeah,
and
we
just
haven't-
put
it
on
this
slide,
but
no
actually
we're
completely
bought
in
on
open
telemetry.
In
fact,
really
all
we've
been
waiting
for
is
the
open
telemetry
go
sdk
to
get
to
stable,
1.0
and
as
soon
as
that's
done,
you
know
this.
This
will
be
included.
So
I
mean
that's
literally
what
we're
waiting
for.
C
Yeah
we
actually
work
with
the
open,
telemetry
collector
agent
today,
so
we
support
both
the
open
telemetry
protocol
and
the
zipkin
protocol
and
yeah,
like
mark,
said
we're
waiting
on
the
the
open,
telemetry
ghost
decay
2,
to
be
a
little
bit
more
stable.
We
started
out
with
open
sensors
in
the
beginning,
yeah,
and
also
you
know
this
observability
here.
What's
really
special
about
it.
Is
that
it'll
create
an
entire
call
graph
between
calls
that
go
through.
C
You
know:
different
services
like
service
a
to
service
b,
which
is
the
type
of
observability
you'd,
find
in
things
like
linkedin,
for
example,
in
service
meshes,
but
you
know
because
you're
also
you
know,
storing
state
through
dapper
and
and
have
pub
sub
dapper
can
actually
trace.
These
calls
through
an
entire
call
graph
right
so,
for
example,
think
about
a
message
that
comes
in
through
naps
or
wrapped
in
queue
for
service,
say
and
then
service
v
invokes,
sorry
comes
to
service
and
then
service
say
invoke.
C
Service
b
dapper
will
actually
trace
this
entire
call
flow.
So
you
know
it's
not
just
a
mesh
that
it
creates
it.
It
can
also
trace
things
that
do
not
traverse
the
mesh
at
all
like
bindings
coming
in
from
external
systems,
just
the
app
saving
statings
to
a
state
store
using
an
event
that
came
in
from
a
totally
different
system.
So
the
the
call
graphs
here
are
pretty
informative
for
developers
to
really
understand.
What's
going
on
in
their
system,
I
had
a
couple.
B
Go
ahead
so
I'll
just
refrain
and
keep
two
at
the
moment,
but
just
to
so
I
can
not
understand
the
the
pub
sub
model
when
you
are
managing
a
service,
whether
that
is
an
interface
in
front
of
redis
or
rabbitmq.
Do
you
manage
the
connection
pool
inside
of
that
order
to
just
dab
a
hand
over
the
connection
string
to
the
service
like
how
deep
does
that
go.
C
Yeah,
so
dapper
works
with
a
component
models
right,
so
the
dapper
implementation
for
that
specific
component
handles
the
connection
right
so
dapper
delegates
it.
The
developer
only
needs
to
know
about
apis
and
then
for
the
connection
string.
They
tell
dapper
what
the
connection
string
is
and
dapper
can
either
fetch
it
from
a
secret,
or
you
know
it
can
be
plain
text
if
you're
running
it
locally,
but
it's
very
easy
for
developers
and
operators
to
basically
say
this:
these
are
the
connection
credentials
to
the
service
and
then
as
a
developer.
C
All
you
care
about
is
the
publish
endpoint
and
you
know
the
subscription
endpoint.
You
don't
have
these
sdks
needed
in
your
code
at
all,
and
that's
how
you
know
we
see
a
lot
of
developers,
writing
dapper
applications
with
like
just
http
or
jrpc,
primitives
and
and
nothing
else
right.
They
don't
actually
need
to.
You
know,
manage
connection
pooling
they
don't
need
to
manage.
You
know
getting
the
secrets
handling
connection
strings
in
their
code,
like
all
of
that
is
being
delegated
to
the
diaper
center.
B
C
Yeah,
actually
we
don't
have
that
slide
over
here,
but
every
change
you
make
to
a
dapper
configuration
on
kubernetes
I'm
going
to
give
the
kubernetes
example.
You
basically
apply
it,
it's
a
crd
and
then
we
have
an
operator
that
basically
gets
notified
about
changes
and
it
propagates
them
into
dapper
sidecars.
C
So
what
we
heard
from
operators
and
developers
was
in
for
these
specific
components,
they
want
to
be
able
to
control
the
life
cycle
themselves,
so
they
want
it.
You
know
they
want
to
be
able
to
apply
the
new
resources
and
then
just
use.
Kubernetes
primitives,
like
rollout,
restarts
to
basically
control
when
the
apps
actually
consume
these,
so
you
can
add
and
remove
new
components.
But
when
you
change
components,
the
community
has
been
really
clear
about
they
wanting
to
control
the
life
cycle.
Okay,
thank
you.
No
problem.
F
F
F
So
that
was
dapper
in
a
nutshell:
there's
a
lot
more
to
it
and
that
we
can
dive
into
in
terms
of
how
it
works
in
terms
of
its
capabilities
and
in
fact
each
one
of
those
apis
yourself
has
sort
of
features
around
them
all
and
things.
But
you
know
I
want
to
spend
a
little
bit
of
time
talking
about
the
community
momentum.
F
You
know:
we've
seen
a
huge
interest
with
dapper
across
the
community
that
you
can
sort
of
measure
in
different
ways.
For
us,
of
course,
the
most
one
that's
importance
is
the
monthly
contributors,
and
particularly
since
the
1-0
release
that
we
saw
in
february,
you
can
see
on
the
right
here
the
monthly
contributors
that
we
have
had
and
how
his
number
of
it's
grown.
These
are
unique
contributors
and
it's
grown
from.
You
know,
731
in
february.
F
Up
to
now,
just
in
the
latest
number
that
came
out
to
july,
you
know
1157
unique
different
contributors
and
they
come
from
a
wide
number
of
different
organizations
includes.
You
know:
people
like
vmware
alibaba.
You
know
lots
of
you
know
big
cloud
providers
as
well
as
some
smaller
organizations
fortune
500
companies.
Some
of
these,
like
alibaba
of
intel,
actually
have
dedicated
engineers
working
on
dapper
exclusively
working
with
us
zeiss,
for
example,
and
bosch
have
just
engineers
who've
contributed
code
because
they
built
their
own
applications
in
production.
F
Other
ones,
like
man
group,
considered,
provided
a
very
key
piece
of
code
that
allowed
us
to
integrate
with
console,
and
you
know,
provide
dapper
running
on
multiple
different
types
of
environments
for
service
discovery.
So
these
contributing
organizations
have
been
really
key
in
helping
the
growth
of
dapper
and-
and
you
know
as
well
as
that
you
know-
we've
had
a
discord
channel
where
we
are
very
active
in
a
community
itself.
It's
actually
crossed
over.
I
think
they
it's
got
about
just
over
2
000
members
inside
this
now
and
that's
grown.
F
You
know
rapidly
in
the
last
year,
it's
very
active
community
that
allows
us
to
you,
know,
get
directly
answering
questions
to
people
and
the
docs
have
lots
of
views
around
them
all.
We
have
a
lot
of
good
feedback
about
docs
that
are
very
focused.
In
fact,
a
lot
of
our
contributions
come
to
documentation,
but
people
come
along
and
just
provide
new
contexts
and
new
documentation
for
how
they
see
using
dapper,
and
then
importantly,
then
we
see
your
monthly
emerge
piece
of
pull
requests.
F
You
know
over
150
of
them
typically
per
month,
then
you
can
measure
also
docker
pulls
around
this.
So
as
a
whole,
the
community
has
grown
pretty
rapidly
since
we
released
you
know,
kind
of
a
year
and
a
half
or
a
year
and
three
quarters.
Now.
I
guess
it'll
be
two
years
in
october,
and
you
know
you
can
also
sort
of
just
see
a
lecture
of
popularity
in
terms
of
github.
E
So
sorry
to
check
here
one
question:
when
you
talk
about
the
contributors,
do
you
see
them
mostly
contributing
by
providing
plugins
or
extensions?
However,
you
call
them
like
into
other
other
tools
out
there
and
or
like
how
big
is
the
relation
people
contributing
like
newer,
integrations
versus
those
doing
bug
fixes
versus
those
that
actively
contribute
to
to
core
components.
C
Yeah,
that's
that's
a
really
good
question
and
you
know
when
we
just
launched
the
project.
Obviously
we
saw
most
of
the
contributors
contributing
new
components
like
you
know:
new
databases,
new
pub
subs.
What
we're
seeing
now,
especially
after
the
1.0
release,
is
that
many
contributors
are
actually
contributing
major
runtime
features,
and
you
know
helping
us
with
bug
fixes
and
things
are
really
deep
in
in
the
code.
A
really
good
example
of
that
is
the
secret
management's
api.
That's
a
completely
new
dapper
api
that
was
contributed.
C
It
was
designed
proposed
and
eventually
merged.
You
know
by
the
community
and
we're
seeing
more
and
more
of
these
taking
place.
So
you
know
it's
a
shift
now
from
component
contributions
to
really
you
know,
hardcore
work
on
the
on
the
runtime,
which
I
think
is
a
pretty
good,
healthy
sign
for
the
project.
Yeah
I
mean.
E
It's
obviously
pretty
natural,
that's
how
usually
contributors
get
into
a
project.
They
might
start
with
with
a
bug
fixed
and
they
start
contributing
a
component
answers.
How
long
do
you
usually
see
contributors
sticking
around
so
how
many
of
your
contributors
would
you
see
like
they're
like
one
time
contributing
or
one
time
bug
fixing
versus
those
that
are
constantly
there?
That's
what
I
think
I
didn't
understand
with
the
monthly
contributors.
Are
these
like
the
ma?
This
is
the
monthly
growth,
but
do
you
really
have
like
now,
1
200,
almost
people
contributing
every
single
month.
F
C
Yeah
we
have,
we
have
a
pretty
healthy
amount
of
recurring
contributors,
and
you
know
new
contributors
coming
in
so
yeah.
We,
we
do
actually
see
a
lot
of
recurring
contributors
and
we
we
have
a
way
for
people.
You
know
to
take
on
more
substantial
roles
in
the
project
like
approvers,
community
members
and
then
also
maintainers,
and
we'll
talk
about
our
diversity
of
maintainers
in
the
next
slide.
I
think.
E
F
The
in
terms
of
our
partners
and
adopters-
you
know
this
is
just
a
small
snapshot
of
sort
of
the
ones
of
logos
that
we
actually
can
sort
of
put
on
here
and
use,
because
you
know
a
lot
of
the
time.
We
can't
use
logos
without
sort
of
missions
around
things,
but
we
see
a
spectrum
across
14500
companies
across
you
know
small
startups,
yeah
and
sort
of
some
of
the
larger
cloud
providers
like
alibaba.
F
When
we've
you
know
a
couple
of
ways
we
find
this
out
is
just
through
our
own
community
engagements
with
them
and
talking
to
them
directly.
They
we
have
a
way
that
they
can
sort
of
self-report
about
the
status
of
how
they're
using
dapper
inside
our
community
repo.
They
can
talk
about
whether
they're
sort
of
running
dapper
in
production
or
they're,
sort
of
developing
and
testing.
At
the
moment
you
know
through
this
adopters.md
and
you
know
what
and
you
know
we
see
both
keep
running.
F
There's
a
lot
of
customers
running
and
doctors
running
it
in
production
on
a
variety
of
different
platforms
across
aws
gcp
azure,
as
platforms
alibaba
as
well
as
on-premise
as
well.
So
we
see
them
just
deploying
it
inside
their
own
data
centers.
In
fact,
manu
group
is
like
that
as
an
example,
they
just
deploy
dapper
into
their
own
data
centers
and
things,
and
I
know
wide
varieties
of
different
types
of
applications
as
well.
Whether
it's
in
financial
application,
iot
runs
inside
manufacturing.
F
Just
as
another
perspective,
we
can
actually
see
you
know
about
100
of
the
top
fortune.
500
companies
actually
have
a
used
dapper
in
production
or
in
developing
testing.
In
terms
of
you
know,
deployments
that
they
have
in
place,
so
we
see
a
pretty
healthy
ecosystem
here
of
partners
and
people
adopting
data.
D
C
F
Just
as
a
point
of
how
does
dapper
fit
with
some
of
the
other
cncf
projects,
you
know
we've
been
very
keen
to
make
sure
that
dapper
takes
advantage
of
all
the
standards
and
apis
that
are
there
because
you
know
we
don't
want
to
sort
of
reinvent
anything
and
actually
want
to
be
part
of
sort
of
the
broader
ecosystem,
and
so
you
know
effectively,
we've
adopted
everything
that
we
can
adopt.
You
know
all
of
the
pub
sub
mechanism
between
dapper
is
based
upon
cloud
events.
F
We
take
heavy
dependency
on
grpc
for
the
internal
calls
for
services
for
unification
and
just
be
able
to
take
advantage
of
how
you
actually
expose
you
know.
Grpc
and
http.
Apis
spiffy
is
used
for
identity
management
and
identity
between
services
and
a
lot
of
the
security
acting
between
things
open
telemetry,
we
talked
about
you,
know
prometheus
and
integration
with
open
policy
agent.
That's
one
of
our.
F
You
know
the
plug-ins
for
the
pub
sub
and
sort
of
integrates
well
with
cada,
so
that
you
know
if
you
want
to
put
dapper
and
cater
and
do
auto
scaling
around.
You
know
event
driven
events
that
come
in
and
scale
out
your
instances
of
your
adapter
and
your
services.
You
know
we
actually
have
quite
a
few
customers
who
actually
sort
of
users
who
deploy
cada
and
dapper
side
by
side
inside
that
kubernetes
infrastructure.
B
C
Own
yeah,
so
right
when
we
launched
the
project
in
2019,
we
announced
from
the
very
beginning
that
it's
our
intention
to
do
an
adaptive,
vendor,
neutral
foundation
and
we've.
You
know
we
did
our
own
due
diligence
and
we
we
took
a
look
at
some
of
the
other
foundations
out
there
before
we.
You
know
we
came
to
a
conclusion
that
we
really
want
to
give
cncf
and
to
keep
our
community
really
inclusive.
C
We
put
an
open
governance
in
place
last
year,
which
really
allows
people
from
all
walks
of
life
and
companies
to
become
dapper
maintainers.
We
have
a
pretty
diverse
commuter
base.
You
know
over
250,
individual
companies
and
individuals,
and
we
have
maintainers
from
alibaba
apple
automatic,
which
is
the
commercial
entity
behind
wordpress,
microsoft
and
roadwork.
Where
you
know
roadwork
is
especially
is
a
maintainer,
I'm
really
proud
of,
because
he's
a
dapper
adopter.
C
C
F
Yeah,
so
I
think
for
us,
the
most
important
thing
is
making
sure
that
you
know.
Dapper
is
truly
vendor
neutral
and
inclusive
of
the
community
as
much
as
we
can,
and
it's
our
one
of
our
primary
goals
to
get
a
divorce
of
maintainers
as
much
as
we
possibly
can,
and
it's
something
that
we're
working
hard
on.
We
actually
we
have
some
current.
F
Now
you
know
people
who
are
contributing
to
it.
All
that
we're
working
closely
with
that
we're
trying
to
build
across
a
number
of
different
type
of
repos
does
have
a
diverse
set
of
repos.
Actually,
if
you
actually
go
and
look
at
the
actual
repo
itself
here
yeah,
you
can
actually
see
that
you
know
we
have
the
call
runtime
and
we
have
docs
and
cli
and
the
components
contribute.
F
F
For
example,
the
java
sdk,
you
know,
we've
we've
had
you
know
a
lot
of
contributors
who
you
know
java
specialists
help
us
design
the
apis
and
make
that
you
know
a
lot
more
java
friendly.
The
php
sdk
was
done
in
totally
by
you,
know
the
maintainer
from
automatic
and
things.
So
you
know
this
is
where,
across
all
of
these
repos
we're
building
out
maintainers,
that
we
want
to
make
sure,
contribute,
adapter
and
help
grow
the
whole
ecosystem
around
it
and
make
it
so
that
it
becomes
pretty
vibrant.
F
I
think
that
was
my
last
slide.
Yes,
you
know
it
was
my
last
slide
so
when
we
asked
questions
on
your
time
to
wonder,
thank
you,
but
you
know
we
can
dive
into
any
other
topics
of
this
or
things
that
we
think
that
we
haven't
covered
or
some
more
details.
There's
a
due
diligence
document
that
I
I
can
publish
in
the
link
and
that
adds
more
about.
F
You
know,
engineering
processes,
and
you
know
what
that
looks
like
and
you
know
and
release
life
cycles
and
versioning
dapper
has
you
know,
distinct,
versioning
and
support
policies
around
these
things?
You
can
actually
go
into,
for
example,
if
you
go
into
go
into
the
docks,
so
we're
going
to
docks.
F
Actually
let
me
just
switch
over
to
if
you
go,
for
example,
you
know
if
you're
going
to
this
is
our
docs
repo.
You
know
a
docs
repo
is
very
extensive
inside
here.
In
terms
of
you
know,
going
through
concepts
getting
started
guide.
You
know,
particularly
if
the
content
anything
around
support.
You
know
with
a
whole
topic
here
around
versioning
we're
versioning
across
apis
versioning
across
the
runtime
itself
and
cli
versioning
across
components
converging
across
sort
of
schemas
inside
this
all.
F
So
we
put
a
lot
of
time
into
how
versioning
happens
so
that
we
can
be
fully
backwards
compatible
across.
In
fact,
since
we
released
that
with
one
oh,
we
haven't
broken
and
we've
done
breaking
changes,
but
we
haven't
broken
any
app
deployments.
Yet
when
we
do
rollouts,
we
actually
work
very
closely
with
quite
a
few
customers
in
production
and
roll
them
out
early
releases
of
it
or
of
the
of
the
next
of
the
like
the
1.4
releases
coming
up
and
they
kind
of
test
that
in
production
first
and
do
some
rollouts.
F
We
make
sure
we
don't
do
any
breaking
changes,
we're
very
clear
about
our
list
of
supported
releases
here.
So
you
know
the
1.0
release
here
was
done
back
in
february.
You
can
see
that
actually
1.0
is
now
sort
of
rolled
out
of
support,
because
we
have
to
have
a
rolling
support
window.
You
can
still
use
it,
but
if
you
start
logging
bugs
against
this
thing,
we
say
well.
F
You've
got
to
move
to
the
1.2
release,
you
know
which-
and
this
is
the
time
frame
it
is
so
we
have
sort
of
rolling
support
windows
around
these
things,
as
virtually
numbers
across
the
sdks.
We
talk
about
what
your
upgrade
piles
look
like
we're
very
clear
about
how
deprecations
happen
to
that.
We've
already
did
one
particular
api
inside
here
that
we
wasn't
particularly
right,
but
it
won't
be
removed
until
the
1.4
really
gives
people
two
versions
to
go
through
things.
F
We
talk
about
how
you
can
upgrade
on
particular
hosting
platforms.
So
you
know
this
is
the
whole
sort
of
in
life
cycle
about
how
you
can
use
dapper.
We
talked
deeply
about
how
we're
reporting
security
issues.
There
was
actually
a
pretty
hefty
security
issue
that
was
in
one
of
our
dependencies
that
we
had
to
patch
fast.
F
F
One
point
one
time
frame
so
this
release
here.
You
know
you
see
here
that
we
did
a
release
in
april
sixth
and
then
literally
five
days
later,
we
did
a
rollout
for
hotfix
because
we
came
across
a
security
bug
in
one
of
our
dependencies
and
we
quickly
had
to
fix
that
and
roll
it
all
out
because
of
a
defective
security
relief
issue.
F
So
you
know
we're
very
attentive
to
making
sure
and
and
in
between
this
date
here
not
only
was
patch,
but
it
was
tested
on
for
our
customers
first
to
make
sure
that
we
didn't
do
any
breaking
changes
around
at
all.
So
so
this
is
kind
of
you
know
the
the
level
of
maturity
that
we've
got
to
in
terms
of
our
release
process
and
our
engineering
processes.
F
We
can
also
talk
a
lot
about
engineering
processes
in
terms
of
perf
and
end-to-end.
Test
runs
how
we
you
know,
do
builds
around
that
all
the
release
cycle
itself
and
checklists
around
that,
but
we're
very
careful
to
make
sure
that
you
know
a
1.0
release
is
a
significant
thing
and
you
know-
and
you
have
to
make
sure-
that
we
maintain
the
quality
and
the
the
objectives
around.
All
that
you
know
particularly
around
so
you
know
so
we
can.
D
An
area
of
interest
like
well,
I
want
to
get
your
your
opinion
on
it
at
least,
and
it's
there's
a
few
different
projects.
So
I'll
just
list
them
all
here,
but
I
kind
of
want
to
know
how
you're
thinking
of
relating
to
them
so
oam
open
application
model,
which
is
microsoft,
thing
and
then
crossplane
and
cube
vella
kind
of
under
that
category.
How
do
you
see
dapper
relating
with
those.
C
Yeah,
so,
let's
start
with
cube
velo
right,
cube.
Vela
is
like
an
opinionated
application
platform
on
on
top
of
kubernetes.
It
gives
you
you
know,
revisions
and
stuff,
so
dapper
is
really
a
developer
focused
set
of
apis.
That
being
said,
you
know
I
was
really
happy
to
see
that
cube.
Velar
is
now
integrating
dapper
inside
of
cube
vela.
C
So
like
the
the
integration
that
I
expect
to
see
from
the
projects
you
mentioned
into
dapper,
is
that
they
easily
enable
dapper-enabled
workloads
and
make
it
really
easy
for
users
to
basically
say
I
want
adapter
sidecar
and
these
components
to
be
controlled
through
my
deployment
mechanisms
and
to
be
able
to
configure
them
and
we're
already
seeing
it
with
cube.
Vela
there
isn't
anything.
You
know
specific
to
ohm
right,
cube.
Vela
is
an
implementation
of
ohms.
So
I
think
that's
the
connection
there
like.
I
don't
think
there
should
be
dapper
in
the
ohm
spec.
D
C
C
E
G
So
mark
just
one
last
question:
so:
okay
yeah,
I
will
just
go
one
last
question,
so
yeah,
I'm
waiting
for
the
slides
to
to
finish
like
like
I
I
take
that
like
dapper,
is
competing
with
like
spring
cloud
and
double
in
the
same
level
but
like
if
you
want
to
change
like
asked
developers
to
change
their
application
code.
It's
very
difficult!
F
So
when
you
say
change
of
code,
you
know
dapo,
we
expect
to
be
incrementally
adoptable.
If
it's
you
know,
if
you're
referring
to
that
here,
so
you
know
we
don't
expect
developers
to
throw
away
their
existing
code.
They
can
take.
You
know
what
they
have
today
and
start
to
integrate
dapper
in
a
part
of
their
code.
If
they
want,
you
know,
we
don't
expect
to
say
you
have
to
start
to
use
dapper
inside
everything
inside
this.
So
let's
just
take
an
example.
F
F
On
my
you
know,
whatever
my
process
is
of
code,
my
running
call
the
api
inside
that
for
adapted
retrieve
secrets,
but
I
don't
have
to
touch
the
rest
of
my
application
in
any
way
and
I've
just
integrated
it
with
a
piece
of
it.
If
I
decide
that
I
want
to
do
service
to
service
calls
using
dapper,
I
can
start
to
put
it
on
side
cards
on
the
other
application
and
start
to
integrate
it
more
at
that
level.
But
we
don't
expect
you
to
through.
In
fact,
we
we
do
the
opposite.
C
C
We
won't
treat
all
languages
as
equals,
and
we
really
see
this
as
the
thing
that
drives
dapper
adoption.
The
fact
that
it
appeals
to
developer
enterprises
everywhere
that
can
just
take
take
usage
of
these
open
apis
and,
like
I
mentioned
before,
we
do
see
developers
using
dapper
with
spring
cloud.
For
example,
you
know
I,
I
know
one
company
using
spring
cloud
using
dapper
to
fetch
secrets
from
hashicorp
vault
on
their
own
premises,
infrastructure.
C
F
E
B
E
A
A
Yes,
yes,
so,
yes,
we
have.
We
have
a
branch
in
the
in
the
head
repository,
which
consists,
which
includes
all
of
the
things
we
need
for
having
multiple
services,
microservices
and
so
on,
and
we
I
really
thought
that
it
would
be
nice
if
we'd
do
kind
of
a
merchandise
hackathon
to
get
all
of
this
to
get
this
into
master
and
to
adopt
all
of
the
all
of
the
tests,
including
this
sorry
include
that
they
adopt
the
deployment
mechanisms
in
there.
A
And
yes,
I
just
wanted
to
ask
if
some
of
you
wants
to
join
us
on
next
thursday
and
yes
we'll
all.
I
think
we'll
also
announce
this
on
the
on
the
slack
channels
and
it
would
be
cool
if
we
get
the
whole
stuff
into
master
mastermode,
because
then
I
think,
with
the
microservices
implementation,
we
would
have
a
lot
of
more
more
possibilities
to
deal
with
with
a
potato
head.
Let's
think
about
microservice
deployments.
Obviously,
let's
think
about
service
meshes
or
other
other
funny
things.
E
Yeah,
so
I
think
one
thing
you
should
do
first,
I
think
we
should
cut
at
least
a
release
or
attack
on
what
we
have
right
now,
so
that
the
existing
examples
keep
at
least
working
for
for
people
to
check
out,
and
then
we
should
start
the
merge
over,
and
I
think
we
should
also
reach
out
to
some
of
the
people
who
are
doing
the
examples
I
think,
would
even
be
a
nice
session
like
working
on
the
example.
Maybe
life
with
somebody
and
asking
them
whether
they're
willing
to
work
on
those
with
us.
E
D
D
A
D
E
But
the
good
point
is,
you
should
also
like
put
it
into
news,
and
discussions
like
there
was
one
question
about
discussions
as
well
yeah
and
I
think
also
reaching
out
to
the
original
contributors,
where
they're
willing
to
move
it
to
a
distributed
implementation,
and
that
would
be
nice
video
recordings,
because
it's
actually
show
me
life.
How
I
can
deploy
the
application
check
it
out
and
make
it
work.
E
D
E
So
the
initial
idea
was
maybe
how
the
whole
thing
started
came
out
of
a
talk
for
kubecon
last
year.
Last
fall
where
everybody
says,
like
the
cloud
native
landscape,
it's
a
total
mess.
The
people
built
the
deposit.
Well,
it's
actually
the
message,
the
different
ways.
You
can
do
things
and
I
always
it
there's
and
we
wanted
to
create
an
application
as
most
of
the
characteristics
of
a
micro
service
application
just
for
the
target
was
just
very
simple,
being
one
service
which
is
obviously
too
simple
for
real
world
applications.
E
This
is
a
collection
if
you
want
to
learn
how
to
use
different
app
delivery
tools.
Here's
like
15
ways
how
you
can
deploy
this
application
pick
and
choose
whatever
fits
your
needs
best
and
what
your
requirements
best
and
by
the
way.
Interestingly,
you
can
even
mix
and
match
some
of
those.
Obviously
you
can
use
the
helm
based
deployment
together
with,
say,
argo
cd.
E
You
can
also
combine
argo
city
and
cubel
if
you
really
wanted
to,
and
do
things
like
this,
so
that
was
the
whole
idea
that
we
got
also
the
feedback
from
some
people
who
were
using
it,
and
there
was
a
big
german
company
for
a
big
retail
company.
They
use
it
internally
to
train
people
and
frameworks,
and
they
passed
it
like
15
different
applications
and
rather
than
basically
have
like
one
and
you
can
just
play
around
and
just
learn
how
to
deploy
it,
how
to
use
it.
E
D
E
Yeah,
it's
a
it's
a
learning
and
demo
app,
so
it's
not
something
that
you
would
build
on
top.
So
unless
you
want
to
run
a
potato
head
and
configure
it,
the
idea
was
to
directly
export
this
as
a
t-shirt
running
successfully
at
some
point,
but
there's
other
contributions
that
we
have
in
there
like,
for
example,
adding
a
state
for
workload.
If
you
have
an
idea
how
to
add
a
state
for
workload,
that's
fine
also
things
we
wanted
to
put
in
there
like.
E
It
has
like
all
the
the
complexities
in
there.
You
do
for
a
kubernetes
cloud
native
based
application
that
they
have
to
take
care
of
shipping
this
application,
while
the
application
itself
is
really
simple,
like
showing
this
potato
head
character
and
rather
focusing
on
these
complexities.
Rather
on,
like
this
polyglot,
distributed
application.
E
E
Infrastructure
application
deployment
complexities.
This
is
what
people
were
asking
us.
Can
you
tell
me
how
to
do
this?
How
can
I
tell
you
how
to
do
it
like
we
had
stateful
workloads
or
quality
api
dependencies
passwords
we
had
in
there,
like
other
things,
that
people
usually
come
across,
that
they
find
kind
of
challenging
from
my
deployment
workflow.
D
Yeah
and
oh
so
that
where
I
was
kind
of
getting
those
at
the
blog
post,
the
audience
like
you
guys
are
kind
of
defining
it
as
platform
architect.
So
we
should
make
the
announcement,
like
hey
you're,
trying
to
decide
how
you're
going
to
do.
You
need
argo,
cd
or
weave
works
or
fl
whatever
they
all
are.
Here's
a
project.
Try
it
out
in
your
invite.
We've
we've,
you
know
paved
the
path
for
you
to
do
that.
Research.