►
From YouTube: Kubernetes is Still Hard for App Developers, Let’s Fix That! - Aaron Schlesinger, Microsoft
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
Kubernetes is Still Hard for App Developers, Let’s Fix That! - Aaron Schlesinger, Microsoft
In this session, I’ll present two case studies that reveal the general needs of most small to medium size application developers. I’ll show that that these developers are severely underserved in the community and that we can drastically improve their experience and grow the Kubernetes community significantly. I’ll use these case studies to detail the technologies a new developer needs to learn before they can get their app running, and I’ll demonstrate the workflow most new developers follow to launch and maintain their app in production. I’ll then describe a hypothetical toolchain based on real world tools that would significantly simplify app creation and deployment for these users. The audience will leave with a deep understanding of a large class of underserved Kubernetes users and ideas for how to meet their needs.
To learn more: https://sched.co/GrTQ
A
Hello,
all
right
all
right,
we're
gonna
get
started.
So
thank
everyone.
So
much
for
coming.
I
know
that
there's
some
folks
fanning,
if
you
can
brave
the
middle
there's
plenty
of
seats
in
the
middle
of
both
sides,
Oh
feel
free
to
jam
in.
So
once
again,
thank
you.
So
much
for
coming
coming
to
chat
with
me
about
kubernetes
for
app
developers.
I'm
really
excited
to
be
here
today
and
talk
from
this
kind
of
perspective.
A
I
think
that
we
might
not
have
had
so
much
of
the
app
developer
perspective
in
sort
of
recent
years
who
vanetti
landscape.
So
a
little
bit
about
me
in
terms
of
kind
of
like
the
two
phases
of
Aron
I
made
a
career
change
this
year
right
about
the
middle
of
the
year
before
around
April
2018
I
was
an
engineering
manager
in
Azure
containers.
So
we
were
responsible
for
things
like
a
cast,
as
your
container
instance
and
I
focused
a
lot
of
my
time
on
connecting
clouds
more
integrated
with
clusters.
A
So
I
was
a
chair
and
the
stig
Service
Catalog
group,
which
you
can
there's
a
couple
of
sessions
around
that
conference.
That
I
highly
encourage
you
to
go
check
those
out
and
we
did
a
lot
of
work
with
brokers,
service
brokers,
trying
to
get
clouds,
can
you
steal,
yeah
and
trying
to
get
cloud
services
or
integrated
with
clusters?
A
So
since
then,
since
I
made
this
change,
I
went
over
and
became
a
cloud
developer
advocate
and
on
that
group,
I
focus
a
lot
more
on
app
developers.
I
actually
am
an
app
developer
now
so
I
look
at
things
now
in
the
uber
Nettie's
world
from
the
landscape
from
the
perspective
I
should
say
of
what
does
it
mean
to
write
code
and
then
have
to
go
and
get
that
code
running
in
your
cluster
in
production,
live
on
the
Internet,
so
I
actually
kind
of
have
both
perspectives.
A
A
Soy
DM
to
map
I
talked
to
him.
I
said:
hey:
hey!
Is
it
cool
if
I
use
this?
In
my
talk,
he
was
gracious
enough
to,
but
B
I
also
asked
him
well.
What
did
you
really
mean
by
this?
What
did
you
mean
specifically
by
us,
and
he
told
me
that
he
was
thinking
about
a
persona
about
personas
of
the
folks
who
are
using
kubernetes
and
specifically,
he
was
thinking
about
the
difference
between
an
app
developer
and
an
operation
first
DevOps
first,
and
that
really
got
me
thinking.
I
was
thinking
okay.
A
A
So
I
got
to
thinking
what
does
it
mean
to
be
an
app
developer?
I
drew
on
some
other
folks
experiences.
I
drew
on
my
experience
now
and
I
was
a
real-life
app
developer
a
long
time
ago.
So
I
drew
on
that
experience.
So,
like
everything,
software
I
tried
to
boil
it
down
into
three
below.
This
is
what
I
believe
an
app
developer
is.
This
is
the
persona
that
I'd
like
to
submit.
A
So
we
always
talk
about
business
logic,
business
logic
and
business.
Logic
is
the
stuff
that
actually
makes
the
app
out.
So
it's
everything
except
for
this.
The
bash
scripts
need
to
write
and
the
CI
yamo
for
your
and
the
underlying
sort
of
plumbing
code
and
really
in
modern
days,
it's
sort
of
like
your
business
logic,
stuff.
That
makes
your
app
unique,
plus
you're,
probably
writing
some
glue
code,
a
cloud
services
and
bind
them
together
right,
and
the
second
point
here
is
that
you're
focused
on
the
product.
A
Anything
else
that
you
do
besides
the
product
is
what
we
call
on
different
and
I've
heard
term
quite
a
bit
at
this
conference,
but
also
it's
sort
of
so
undifferentiated,
really
is
just
stuff
that
you
do
that
doesn't
move
the
needle.
So
it's
stuff
that
you
do
that
doesn't
really
help
your
app
and
it
doesn't
help
us
and
if
you
do
work
with
a
product
manager
or
you
do
have
a
Trello
board
of
some
kind.
It's
the
kind
of
things
that
aren't
gonna
move
those
cards
in
the
Trello
board
over
to
the
done
hall
extra.
A
So
for
a
developer,
that's
kind
of
painful
I
have
to
go
and
do
that
expert,
because
you're
not
making
progress
at
your
job
and
so
I
spend
a
ton
of
my
time
trying
to
convince
both
to
come.
Try
out
kubernetes
and
everyone
wants
to
try
it.
That's
the
good
news
for
all
of
us
there's
eight
thousand
of
us
here
today
for
this
whole
week
and
we
all
love
kubernetes.
We
all
want
to
do
vanetti,
but
the
great
news
is
outside
of
this
conference
hall.
A
A
So
that's
the
good
news.
The
bad
news
is
when
people
try
and
get
started,
they
hit
a
wall.
They
find
that
they
have
to
learn
so
much
stuff.
They
have
to
do
to
so
much
trouble
shoot
to
even
get
their
app
up
and
running
that
they
get
frustrated
and
they're,
not
frustrated
with
kubernetes
they're
frustrated
with
them.
Stella
fact
that
they
can't
get
their
app
running
where
they
think
they
should
well,
let's
dig
into
that
a
little
bit
more.
A
So
there
are
some
fundamental
problems:
here's
some
laughs
for
the
first,
but
that's
a
real
thing.
Okay,
if
you
submit
a
bunch
of
yeah
Mille,
let's
say
you've
got
a
hundred
lines
of
yeah.
Mille
kubernetes
manifests
and
you
submit
them.
Your
feedback
loop
is
pretty
difficult.
You'll
have
your
yeah
Mille
you'll,
submit
it
you'll
go
and
do
a
coop
CTL
get
pod
or
describe
pod,
or
something
like
that.
You'll
look
through
a
bunch
of
yeah.
No
that's
bit
out
on
the
command
line.
A
You'll
figure
out
what
happened
if
you've
got
your
image
tag
wrong,
or
maybe
you
had
a
typo
or
a
tab
or
something
like
that
and
you'll
resubmit.
That's
your
dev
test
cycle
that
can
get
fresh,
and
so
I
say.
Why
won't
the
reconciler
love
me,
because
what
you
do
with
coop
CTL
create
is
essentially
fire-and-forget.
Asynchronous
operate.
A
And
so
it's
on
you
to
follow
up
after
that
async
operation,
and
it's
on
you
to
go
figure
out.
Okay,
now
that
the
reconciler
took
over
it
tried
to
make
the
world
the
world
that
I
want
what
happened
and
that's
frustrating
you
have
to
do
that
over
and
over
and
as
a
beginner.
You
do
have
to
do
that
over
and
over
and
over.
You
might
be
doing
it
for
hours
before
you
could
see
something
running
in
a
pod.
That's.
A
That's
the
first.
The
second
thing
is
kubernetes
doesn't
really
clearly
define
what
an
app
and
that's
an
issue
you're
trying
to
build
an
app
on
is,
if
they
don't
define
what
an
app
is
they're,
not
paying
attention
to
the
app
developer
persona
when
I
say
they
I
mean
all.
If
we
don't
all
agree
on
what
an
app
is
and
there's
some
work
going
on
to
make
that
a
reality
yeah
and
what
did
happen.
A
But
at
the
moment,
if
we
don't
agree
what
it
is,
then
we
can't
provide
the
best
tools
to
build
and
maintain
out,
and
then
this
last
point
about
conceptual
overload
context.
Switching.
This
is
the
part
that
frustrates
ongoing
as
you're
maintaining
your
app
as
you're
extending
features
as
you're
growing
your
app
it's
super
popular
as
an
app
as
you
scale
up.
The
conceptual
overload
its
life.
A
So
a
great
example
is,
if
you
have
an
app
that
adds
a
couple
more
domain,
maybe
a
domain
for
your
HTML
front-end
and
a
domain
free
guy,
you're
gonna
have
to
learn
about
ingress
and
learning
about
ingress
self.
Not
a
huge
is
llamó
right
right,
yes,
doors.
You
know,
but
then
learning
about
ingress
rollers
is
difficult,
is
there's
so
much
choice
get
paralyzed
and
then
you
layer
on
a
concept
sort
of
on
top
of
it.
That's
things
like
how
do
I
provision
as
it
else
and
that's
things
like
what
cloud
load
balanced
right.
A
There's
a
lot
of
layered
pieces
there,
but
don't
necessarily
fit
together.
So
well.
Unless
you
read
a
couple
of
different
blog
posts,
then
maybe
a
couple
days
trying
to
get
this
stuff.
That,
in
your
mind,
it's
sort
of
the
right,
and
so
let's
dig
in
a
little
bit
to
that
exceptional
over.
This
is
the
approximate
list
of
thing
that
you're
gonna
have
to
learn
before
you
can
deploy
your
web
app
from
the
first
file,
so
you
go
from
just
code
to
kubernetes
running
in
production.
A
This
is
just
about
what
you
have
to,
and
it's
not
really
that
you
just
have
to
learn
like
gamal
right,
but
you
have
to
learn
the
constant,
so
quick
whole
show
of
hands.
Does
anyone
think
they
can
write
a
helm
start
right
now
about
going
to
Google?
That
includes
every
single
one
of
these
resources
raise
your
hand,
one
three
big,
four,
five,
six
I
think:
okay,
so
that
sticks
out
of
a
room
of
maybe
approximately
150
gonna.
Do
oh,
my
ass
right.
A
What
was
that?
Two
hundred?
Oh
it's
four
on
it.
Oh
thanks
for
coming
yeah,
all
right,
I'm
feeling
yeah!
Okay!
So
that's
what
sticks
out
of
400,
so
that's
telling
and
for
those
who
raise
their
hand,
I
salute
you.
You
have
memorized
a
lot.
You
have
exceptional
eyes
a
lot
up
there
and
but
it's
very
telling
that
everyone
else
yeah,
because,
if
is
what
you
need
to
deploy
a
web
app-
and
you
can't
remember
it
that
means
you're
going
to
da.
That
means
every
time
you
want
to
upgrade
something
you
want
to
add
functionality.
A
A
So,
let's,
let's
talk
about
llamo,
there's
a
lot
of
llamo
bashing
in
the
kubernetes
community,
a
lot
of
people
say:
hey,
we
should
get
rid
of.
You
am
L
gonna
make
the
world
better
a
better
place.
If
we
get
rid
of
llamo
a
lot
of
people
believe
that
I'd
I
would
love
now
I
have
to
write
yeah
Mille,
no
tabs
they'd
be
great,
not
setting
up
my
view
right,
a
felling
great
okay,
great.
A
A
So
you're
on
you're
gonna
have
to
end
up
writing
these
resources
and
understanding
these
resources
one
way
or
the
other.
Why
is
that?
Well,
that's
because
kubernetes
is
the
operating
system
for
your
data
center
data.
Centers
are
your
regions
or
whatever
you're
running
on
an
operating
system
exposes
primitives?
So
if
we're
gonna
compare
kubernetes
the
operating
system
to
Linux,
either
way
you
get
primitives,
you
get
sis
calls
and
network
access
and
RAW
files
and
stuff
like
that.
Well,
the
equivalent
in
kubernetes
is
this,
and
so
without
something
to
abstract
over
these.
A
Let's
call
it
a
framework
whenever
you
need
to
deploy
your
web
app,
you
have
to
build
your
own
framework
to
glue
this
stuff
together
and
so
that
you
can
conceptualize
it
in
a
human
consumable
way,
instead
of
a
kubernetes
consumable
way
and
I
think
it
said
many
times
that
abstraction
is
one
the
solutions
to
every
problem
in
computer
science.
This
is
no
different
okay,
so,
let's
pivot
a
little
bit
and
let's
talk
about
abstractions
okay,
so
we
don't
necessarily
need
to
abstract
over
every
single
one
of
those
resources
in
that
list.
A
That
would
be
a
lot
of
work
and
we
also
don't
really
know
exactly
what
that
abstraction
should
look
like
at
the
end
of
the
day.
So
let's
inform
that
abstraction.
With
some
case
studies
and
from
those
case
studies
we
can
pull
out
some
common
patterns
and
then
we
can
target
those
patterns
to
abstract
over
okay.
So
the
first
one
is
the
lowest
hanging.
Fruit
I
talked
to
quite
a
few
folks
who
do
use
Heroku
or
they
use
it--
or
name
your
favorite
pass,
and
the
one
amazing
thing
about
all
these
passes.
A
It's
literally
one
command
to
get
running
on
the
internet,
public
IP
a
lot
of
them
even
provide
you
with
a
sub-domain.
You
run
git
push
on
Heroku
x'
case
and
you've
got
your
app
running.
It
takes
care
of
everything
else.
You
can
get
fancier
if
you
want,
but
basically
that's
how
you
start
out
and
in
this
use
case
really.
This
is
probably
a
hobbyist
or
someone
who's
writing
a
building,
a
startup
or
something
like
that,
and
we
talked
about
undifferentiated
code.
These
are
the
people
who
are
the
most
allergic
to
undifferentiated
code.
A
These
are
the
people
who
are
most
sensitive
to
the
fact
that
when
they're,
writing
that
undifferentiated
code,
the
glue
code
and
the
infrastructure
code
that
they're
really
losing
time-
if
you
can
imagine,
writing
an
app
to
scratch
your
own
itch
on
a
Thursday
night.
Well
anytime,
you
have
to
learn
some
llamó,
that's
cutting
into
those
hours,
and
so
that's
why
people
reach
for
Heroku
and
other
passes
right,
so
I'm
not
suggesting
here
that
we
need
to
make
a
pass
on
top
of
kubernetes,
but
we
need
to
provide
a
solution.
A
That's
passed
like
to
someone
who
wants
to
get
into
kubernetes
on
sort
of
day,
one
of
their
app
ok.
So
now
going
a
little
bit
more
in
depth.
This
is
a
case
study
when
someone
is
running
inside
of
kubernetes
already
so
I've
talked
to
customers,
I've
talked
to
friends,
I
talk
to
acquaintances,
people
have
DM
me
on
Twitter,
and
the
common
question
once
you're
running
in
on
kubernetes
is
my
app
needs
state.
What
do
I
do?
A
A
So
how
are
you
gonna
provision,
your
database
in
your
cloud
portal
or
your
cloud
CLI,
and
how
are
you
gonna
get
those
credentials
and
that
host
name
and
that
username
down
into
your
kubernetes
world?
Are
you
gonna
copy
and
paste
it
I
love
copying
pasting
into
my
one
password
and,
having
that
be
my
key
vault.
Are
we
gonna
do
that
that's
reasonably
secure,
but
once
it's
in
your
secure
or
not
secure
place,
whether
you
write
it
on
a
post-it
note
and
transcribe
or
you
put
it
in
one
password?
A
How
are
you
gonna
get
that
into
your
kubernetes
into
your
helm,
char
or
somehow
into
that
kubernetes
secret?
Are
you
gonna
copy
and
paste
every
time
you're
gonna
have
that
one
person
who
has
the
one
password
open
on
their
machine?
Are
you
gonna
paste
it
into
a
private
github
repository?
Is
it
somehow
gonna
be
floating
around
there
and
your
CI
system?
Well,
there
are
kind
of
shades
of
security
in
there.
It's
on
a
spectrum,
but
regardless
of
what
you
do,
your
password
isn't
gonna
end
up
kind
of
splattered
around
your
universe.
A
A
That's
a
tough
problem
to
solve,
and
then
finally
injecting
the
password
into
your
app
is
not
the
biggest
deal,
because
we
have
secrets
and
we
can
mount
secrets
into
environment
variables,
folks
in
the
app
development
world,
I.
Think
probably
everyone
at
this
point
knows
about
12
factor.
Apps
or
most
people
knows
about
12
factor
apps
and
if
you
do,
but
you
can't
use
them
or
you
don't,
but
you
use
a
framework.
Your
framework
or
your
code
will
have
a
way
to
take
credentials
in
whether
it's
by
config
file,
whether
it's
some
fancy
environment
variable.
A
It
has
everything
it
kind
of
doesn't
matter
because
everyone
knows
how
to
get
credentials
in.
But
the
question
is:
what's
the
best
way
to
get
credentials
into
your
pod
spec
and
that's
a
fundamental
distinction,
and
there
are
a
variety
of
different
ways
to
do
it.
You
can
do
a
volume
mount,
you
can
use
vault.
You
can
use
your
cloud
specific
key,
vault
KMS
or
as
your
key
vault
or
whatever.
It
may
be,
there's
a
ton
of
different
ways,
but
we
don't
really
have
a
best
practice.
A
Every
single
team
has
their
own
best
practice
on
how
to
inject
that
stuff
into
your
app
and
while
we're
talking
about
databases,
let's
talk
about
database
migrations,
so
show
hands
who
has
done
a
database
migration
in
their
life
over
three
quarters?
Okay,
now
put
your
hand
up
if
you've
ever
crashed
your
production
app
doing
a
database
migration.
Okay,
it's
a
lot
less
hands
than
I
thought.
Okay,
raise
your
hand
if
you
appreciate
how
difficult
conceptually
it
is
to
do
a
database,
migration,
yeah,
okay,
so
I
thought
yeah
so
and
that's
before
kubernetes
right.
A
A
So
I
talked
to
actually
more
than
three
groups
at
helm
summit
earlier
this
year
in
February
I
asked
this
question.
Well,
how
do
you
do
your
database
migrations
when
you're
running
a
thousand
replicas
of
your
app
in
kubernetes
in
cloud
X
I
got
three
answers.
Three
people
said
nope.
This
is
the
right
way.
This
is
the
only
way
so
some
people,
just
with
each
replica,
runs
the
database
migration
and
one
wins.
That's
a
totally
valid.
A
lot
of
people
run
it
in
an
it
container.
A
I
followed
up
and
I
said
well,
what
does
the
init
container
do
exactly
and
then
how
does
it
know
to
end
and
what
happens
when
there's
a
thousand
init
containers
running
I,
don't
know,
and
then
this
one
is
my
favorite
personally
is
some
people
run
a
job
and
when
the
job
completes
successfully,
then
they
know
they're
ready
to
deploy
and
I
followed
up
with.
Well,
what
tools
do
you
use
to
figure
out
when
the
job
succeeds?
When
it's
done,
do
you
do?
Do
you
watch
the
event
stream?
A
Do
you
just
pull
with
Coop's
ETL
I,
don't
know.
So
all
of
these
things
work
clearly,
but
there's
no
sort
of
right
way,
and
even
if
there
was
a
right
way
or
all
of
these
things
are
fine
and
you
can
choose,
there's
really
no
tools
that
encode
how
to
actually
execute
these
actions.
It
ends
up
just
kind
of
reducing
to
a
bunch
of
bash
scripts
or
endeavouring
folks
will
write
a
go
tool
to
do
it.
A
And
then
the
last
case
study
is
Athens.
Now
this
is
a
project
that
I'm
a
maintainer
on
it's
a
global
proxy
for
the
new
NGO
dependency
management
system,
and
it's
deployed
at
a
bunch
of
aks
clusters
in
various
regions
around
the
world.
Okay.
So
it's
not
the
craziest
of
helm,
charts
it's
about
300
lines
of
llamó
when
I,
measured
at
the
end
of
November,
but
I
think
that
we
fat-fingered
just
about
every
one
of
those
lines.
A
Helm
lint
has
probably
caught
75
to
80%
of
those
fat
fingers
and
that's
great,
but
there
are
some
fingers
that
helm
went
didn't
and
shouldn't
have
to
catch
because
their
app
specific.
So
that's
things
like
we
forgot
that
the
doctor
image
tags
should
start
with
a
V.
It's
vo
dot,
one
zero
and
not
just
o
dot
one
dot.
Oh
oops
forgot
the
V,
or
maybe
we
fat
fingered
to
a
C,
which
is
right
now
we're
to
the
left
of
the
V
right.
How
Elm
lint
shouldn't
catch
that?
A
A
We
don't
quite
have
the
tooling
to
support
all
of
them.
The
best
thing
we
can
do
is
helm
lint
and
PR
reviews,
and
then
the
last
piece
is
well.
We
haven't
really
gotten
around
to
setting
up
CI
CD.
So
luckily,
this
thing
is
an
experimental
server
right
now
we
haven't
really
gotten
around
to
setting
up
CI
CD
yet
takes
a
little
while
to
do
so.
A
That's
a
bummer,
but
also
once
we
do
set
up
CI
CD
we're
eventually
going
to
end
up
with
a
for
loop
in
bash,
most
likely
that
just
does
helm
installs
on
each
different.
Each
region
we
checked
out
Federation
a
little
bit
and
Federation
is
kind
of
coming
along
and
I
think
we
can
use
it
eventually.
But
meanwhile,
there's
not
really
a
best
practice
for
app
developers
on
how
to
deploy
a
different
regions.
I've
read
a
ton
of
stuff
about
it.
I
know
what
some
folks
are
doing
successfully.
I
know.
A
What
some
folks
are
saying
is
the
best
practice
and
that's
cool,
but
I
have
to
figure
out
at
this
point
how
I'm
gonna
implement
that
best
practice.
There's
nothing
that
really
encodes
it
for
me
or
a
tool
that
helps
me.
Do
it,
and
so,
from
these
case
studies
and
more
patterns
start
to
kind
of
fall
out,
so
the
top
there
is
sort
of
for
the
hobbyist
right.
One
command
should
probably
be
able
to
get.
A
You
started
with
a
super
bare-bones,
simple
deployment,
probably
with
no
database,
but
you
know
something
that
shows
that
your
effort
paid
off
to
make
the
jump
over
to
kubernetes
and
then,
as
you
go,
you
should
be
able
to
add
things
like
that
database
or
maybe
add
things
like
that
new
host
name
for
your
API
and
then
we
get
into
configs
right.
We
we
know
yeah
Mille
is
tough.
A
If
we're
gonna
keep
writing
llamo,
we
should
keep
writing
tools
that
help
us
maintain
it
and
air
check
it
and
so
forth,
and
then
those
last
two
are
sort
of
tied
for
first
in
my
mind.
Well
so
when
I
think
of
connecting
databases,
I
think
of
state
and
state
is
crucial
for
any
app,
it's
the
most
important
piece
of
any
app
I
think
we
all
probably
could
agree
on
that.
A
That's
crucial
that
piece
about
rotating
passwords
is
like
the
de
60
concern
that
really
needs
to
be
thought
of
on
day,
one
and
hopefully
that'll
be
thought
of
by
someone
else.
Besides
the
app
developer
and
that's
what
I
mean
by
encode
things,
reading
blog
post
is
amazing
and
I'm
so
glad
and
grateful
for
the
community
for
writing
down
absolutely
everything
that
they
do
in
production.
But
at
the
end
of
the
day,
if
I
read
blog
posts,
I
need
to
figure
out
how
to
implement
that
stuff
and
encoding.
A
A
And
so
from
those
patterns
that
fell
out
I'm,
introducing
this
fictional
tool
called
tango
and
actually
tango
has
a
repo
with
a
three
line
readme
and
skeleton
CLI
in
it.
But
it
doesn't
do
anything
right
now,
but
I'm
introducing
it
as
sort
of
a
placeholder
for
how
should
we
encode
these
concepts
for
an
app
developer,
and
so,
let's
do
some
sort
of
readme
driven
development
in
this
talk,
let's
go
slide
by
slide
and
talk
about
the
different
commands
that
tango
should
have
and
which
one
of
those
patterns
it
can
address.
A
Ok,
so
we've
got
our
first
one.
This
is
the
entry
point
for
any
app
developer.
They
run.
Install
and
install
is
a
one-time
execution
per
cluster.
You
don't
have
to
run
it
every
time.
You
build
an
app,
you
don't
even
have
to
run
it
on
your
machine.
You
can
get
a
cluster
run
it
in
the
cloud
somewhere
and
you're
done.
The
cluster
is
ready
to
tango.
I
just
made
that
up
right
now,
I'm,
pretty
proud
of
it
and
so
tango.
Install
will
set
up
your
environment
to
do
your
docker
builds.
A
Maybe
you'll
do
it
on
a
hosted
in
the
cloud
hosted
somewhere.
Maybe
you'll
just
have
your
local
daemon,
maybe
will
be
a
mini
cube
or
use
que
native
or
whatever
can
be
all
abstracted
away,
and
then
it
can
also
set
up
a
bunch
of
in
cluster
things
that
enable
these
best
practices
that
tango
will
encode.
So
that's
things
like
tiller
for
helm,
charts
Jager
for
tracing
the
best
ingress
controller
may
be
Prometheus
for
metrics
may
be
wiring
up
metrics
to
some
hosted.
Metric
system
may
be
wiring
up,
Splunk
Logs
with
a
sidecar.
A
The
possibilities
are
endless,
and
this
is
a
really
important
abstraction
point,
because
this
is
the
place
that
you
set
someones
cluster
up
to
be
the
cluster
for
them
to
do
the
work
on
there's
nothing
else.
They
need
to
do
besides
this
and
then
they're
ready
to
go.
The
cluster
is
ready
and
has
everything
they
need
to
tango,
like
I,
keep
saying
because
now
I'm
really
proud
of
that.
A
Ok.
So
the
next
abstraction
point
is
a
knit
so
I
work
for
Microsoft
that
I'm
contractually
obligated
to
put
Clippy
somewhere
on
each
slide
just
kidding,
but
an
it
is
basically
the
wizard
for
each
app.
You
run
in
it
once
and
it
figures
out
almost
everything
that
you
need
to
make
that
app
follow
the
best
practices
of
kubernetes.
A
It
might
ask
you
for
a
few
things.
Maybe
it'll
ask
you
for
your
app
name
or
maybe
it'll.
Ask
you
what
kind
of
docker
file
you
want,
but
overall
it's
good
to
finger
most
things
out
for
you
and
it
might
write
a
bunch
of
files
into
your
git
tree
and
it
might
tell
you
you
can
check
them
in
and
that's
all
good.
But
you
shouldn't
have
to
look
at
what
those
files
have
on
day.
A
A
Ok,
the
next
up
is
deploy
this
one's,
probably
fairly
obvious,
but
what's
important
is
this
is
another
very
crucial
abstraction
point,
because
behind
deploy
can
be
a
very
complex
workflow
of
things.
Of
course,
it's
going
to
start
with
building
your
docker
image,
but
in
there
you
can
follow
some
best
practices
right.
It
can
encode
things
like
immutable,
docker,
image,
tags
or
canary
builds
things
like
that,
and
then
that
second
step
under
setup.
A
Well,
that
can
encode
tons
of
stuff
that
can
encode
new
monitoring,
setups
new
tracing
setups,
so
on
and
so
forth,
and
we're
going
to
skip
over
duplicate
duplicates
a
little
bit
more
complicated.
But
if
we
go
into
the
repo
which
we'll
do
in
a
second,
we
can
kind
of
see
how
that
works
and
then
delete
basically
does
the
opposite
of
an
it.
And
then
service
is
the
one
that's
near
and
dear
to
my
heart,
or
this
is
the
one
that
goes
from
provision
the
database
all
the
way
to
get
the
credentials
into
your
app.
A
So
those
are
sort
of
the
high-level
components
of
tango,
let's
say,
but
the
good
news
is
that
we're
not
trying
to
invent
anything
new
here,
we're
trying
to
curate
a
bunch
of
services
together,
put
them
together
in
the
right
way
that
follows
best
practices,
so
I
call
it
an
extraction
and
not
an
invention,
because
that's
what
we're
doing
here,
we
shouldn't
be
writing
a
lot
of
new
code.
We
should
be
writing
a
lot
of
glue
code,
so
I'm
gonna
mention
two
of
the
tools
that
I
believe
tango
should
probably
encapsulate.
A
One
is
draft
I
don't
have
time
for
a
demo
right
now
for
draft,
but
I'd
love
to
show
you
one
after
draft
is
the
dev
workflow
that
I
think
probably
tango
should
follow.
It's
two
commands
one
command
to
set
up
your
repo,
basically
tango
in
it
and
then
another
command
to
deploy
the
app
to
your
development
environment.
So
you
can
literally
do
remote
debugging
from
your
localhost
into
your
cluster
and
that
cluster
is
kubernetes,
so
it
can
be
running
anywhere
cloud
local
in
a
VM
doesn't
really
matter,
and
then
there's
Kiel.
A
So
Kiel
is
an
operator
that
runs
in
your
cluster
and
it
watches
for
new
docker
pushes
it'll,
listen
to
web
hooks
for
all
the
major
docker
repositories
or
it'll
pull
and
either
way
it
file
lets
you
follow
get-ups.
So
if
I
do
a
git
push
my
CI
CD
system
can
take
over,
it
can
do
the
tests,
it
can
run
the
docker
image,
build,
it
can
do
the
docker
push
and
then,
once
the
doctor
push
happens,
CI
CD
is
done
and
qu'il
takes
over
and
qu'il
pulls
the
docker
image
down.
A
And
if
you
go
to
CNC,
F,
dot,
IO
or
go
to
github
and
look
for
all
the
kubernetes
who
Burnett
easy
things,
there
is
a
tool,
one
or
more
tools
that
will
let
you
do
every
one
of
these
things
and
so
I'll
leave
you
with
this
when
you're
thinking
about
app
developers
on
kubernetes
really
think
about
these
two
personas,
the
ops
persona
and
the
app
developer
persona,
and
when
you
think
about
that
difference.
Think
about
the
divide.