►
Description
We are joined by Ellen Körbes for this episode, where we focus on Kubernetes and its tooling. Ellen has a position at Tilt where they work in developer relations. Before Tilt, they were doing closely related kinds of work at Garden, a similar company! Both companies are directly related to working with Kubernetes and Ellen is here to talk to us about why Kubernetes does not have to be the difficult thing that it is made out to be. According to them, this mostly comes down to tooling. Ellen believes that with the right set of tools at your disposal it is not actually necessary to completely understand all of Kubernetes or even be familiar with a lot of its functions. You do not have to start from the bottom every time you start a new project and developers who are new to Kubernetes need not becomes experts in it in order to take advantage of its benefits.
The major goal for Ellen and Tilt is to get developers code up, running and live in as quick a time as possible. When the system is standing in the way this process can take much longer, whereas, with Tilt, Ellen believes the process should be around two seconds! Ellen comments on who should be using Kubernetes and who it would most benefit. We also discuss where Kubernetes should be run, either locally or externally, for best results and Tilt's part in the process of unit testing and feedback. We finish off peering into the future of Kubernetes, so make sure to join us for this highly informative and empowering chat!
For the show notes and transcript: https://thepodlets.io/episodes/021-kubernetes-sucks-yes-no
Feedback and episode suggestions:
https://twitter.com/thepodlets
https://www.notion.so/thepodlets/The-Podlets-Guest-Central-9cec18726e924863b559ef278cf695c9
info@thepodlets.io
Guest
- Ellen Körbes https://twitter.com/ellenkorbes
Hosts
https://twitter.com/carlisia
https://twitter.com/mauilion
https://twitter.com/embano1
B
C
B
D
I'm
al
I
do
developer
relations
at
tilt.
Tilt
is
a
company
whose
main
focus
is
development
experience
when
it
comes
to
Cuban,
IDs
and
multi
service
development.
Before
tilt
I
used
to
work
at
Garden,
they
basically
do
the
same
thing.
It's
just
a
different
approach,
so
that
is
basically
the
topic
that
we're
gonna
discuss
the
fact
that
Cuban
at
ease
does
not
have
to
suck
for
developers.
You
just
need
to
you
need
some
hacks
and
fixes
and
tools,
and
then
things
get
better
yeah.
C
I'm,
looking
forward
to
this
one
I've
actually
seen
tilt
being
used
in
some
pretty
you
know,
high-profile
open-source
projects
like
I've,
seen
it
being
used
in
cluster
API
and
some
of
the
work
we're
seeing
there
and
and
some
of
the
other
ones.
What
are
some
of
the
larger
projects
that
you
are
aware
of
that
are
using
it
today.
Oh
boy,.
D
That's
complicated
because
every
company
has
a
different
policy
as
to
whether
I
can
name
them
publicly
or
not.
So
let's
go
around
that
question
a
little
bit.
You
might
notice
that
lift,
has
a
talk
at
cube
con
where
they're
gonna
talk
about
tilt.
So
I
can't
tell
you
right
now
that
they
use
tilt,
but
there's
that
so
hopefully
I
found
a
legal
loophole
here,
so
I
think
they're,
the
the
biggest
name
you
can
find
right
now.
D
Closer
API
is,
of
course
huge
and
and
plus
rupiah
is
fun,
because
the
way
they're
doing
things
is
very
different.
We're
used
to
seeing
mostly
companies
that
do
peps
in
some
way
or
another
like
websites,
phone,
apps,
etc,
and
then
closer
api
is
completely
insane.
It's
it's
something
else.
Totally.
There's
tons
of
other
companies
I'm,
not
sure
which
ones
that
are
large
I
can
name.
Specifically.
There
are
smaller
companies.
So,
oh
no
motors
it,
they
do
electric
motorcycles,
it's
a
company
here
in
Berlin
they
have
like
25
developers
you're
using
tilt.
D
We
have
very
tiny
companies
like
mine
space,
their
studio
in
Tucson
Arizona.
They
also
use
tilt
and
it's
like
a
three-person
team.
So
we
have
the
whole
spectrum
from
very,
very
tiny
companies
that
are
using
docker
for
Mac
and
pretty
happy
with
it
all
the
way
up
to
huge
companies
with
their
own
fleet
of
development
clusters
and
all
of
that
and
they're
using
tilts
as
well.
E
Yeah
quick
question
Allan,
so
the
title
says
developers.
What
is
the
like
developers
is
a
pretty
broad
name
and
I.
Have
people
saying
that,
okay
to
communities
to
roar
it's
kind
of
more
like
a
linux
kernel's?
We
want
this
past
experience,
so
our
business
developers,
our
application
developers,
are
developing
in
there.
So
what
is
how
would
you
describe
the
developer
interfacing
with
kubernetes,
using
the
tools
that
you
just
mentioned?
Is
it
the
traditional
enterprise
developer
or
more
kubernetes
developers
like
developing
on
kubernetes,
no.
D
I
specifically
mean
not
kubernetes
developers,
so
you
have
people
work
in
Cuban,
IDs
proper,
for
example,
the
closer
API
folks
they're
doing
stuff.
That
is
Cuban
IT
specific.
So
that
is
not
my
focus.
The
focus
is
your
back-end
developer,
your
front-end
developer,
you're,
the
person,
configuring
I,
don't
know
the
databases
or
whatever.
So
basically
you
work
at
a
company.
You
have
your
own
business
logic.
You
have
your
own
product,
your
own,
app,
your
own
internal
stuff,
all
of
that,
but
you're,
not
a
Cuban,
Aires
developer.
D
It
just
so
happens
that
if
the
stuff
you
are
working
on,
it's
going
to
be
pointing
at
Cuban
Aires,
it's
gonna
target
Cuban
at
ease,
then
one
you're,
the
target
developer.
For
me
for
my
work
and
two
usually
you're
gonna
have
a
hard
time
doing
your
job.
So
we
can
talk
a
bit
about
why
so
one
issue
is
development
clusters.
D
If
you're
using
cuber,
Nettie's
and
proud
rule
of
thumb,
you
should
be
using
kubernetes
and
dev,
because
you
don't
want
completely
separate
environments
where
things
work
in
your
environment
as
a
developer
and
then
you
push
them
and
they
break.
So
you
don't
want
that.
So
you
need
some
kind
of
development
cluster
and
the
type
of
cluster
that
that's
gonna
be
is
gonna
vary
according
to
the
level
of
complexity
that
you
want
and
that
you
can
deal
with
so,
like
I
said,
some
people
are
pretty
happy
with
docker
for
Mac
I
hear
all
the
time.
D
This
complains
that
oh
you're
running
kubernetes
on
your
machine.
It's
gonna
catch
fire
and
okay,
there's
some
truth
to
that,
but
also
it
depends
on
what
you're
doing
no
one
tries
to
run
Netflix,
let's
say
the
whole
Netflix
on
their
laptop,
because
we
all
know
that's
not
reasonable,
but
people
try
to
do
similar
things
on
their
mini
cube
or
doctor
for
Mac,
and
then
it
doesn't
work
and
they
say
oh
you're,
bernardi's
and
the
laptop
doesn't
work
no
yeah.
D
It
does
just
not
for
you
so
that
that's
a
complaint
I
particularly
dislike,
because
it
comes
from
a
it's
kind
of
a
blanket
statement
that
has
no,
let's
say
no
facts
behind
it.
So
yeah,
if
you're,
a
small
company
darker
fur
Mac,
is
gonna
work.
Fine
for
you
like.
Let's
say
you
have
a
beefy
laptop
with
30
gigs
of
RAM.
You
can
put
a
lot
of
software
in
30
gigs.
D
You
can
put
a
lot
of
micro
services
in
30
gigs,
so
that's
gonna
work
up
to
a
point
and
then
it's
going
to
break
and
when
it
breaks
you're
going
to
need
to
move
to
a
cloud
you're
going
to
need
to
do
remote
development
and
then
you're
gonna
go
to
GCP
or
Azure
or
Amazon
you're
gonna
set
up
a
cluster
there.
Some
people
use
the
manage
to
keep
your
Nettie's
options.
Some
people
just
spin
up
a
bunch
of
machines
and
wire
up
cuban
IDs
by
themselves.
D
That's
going
to
depend
on
basically
how
much
you
have
in
terms
of
resources
and
in
terms
of
needs,
usually
keeping
up
a
remote
cluster.
That
works
is
going
to
demand
more
infrastructure
work
like
you're,
going
to
need
people
who
know
how
to
do
that
to
keep
and
keep
an
eye
on
that.
There's
all
the
billing
aspect,
which
is
you,
can
run
docker
for
mac
all
day
and
you're
not
going
to
pay
extra.
But
if
you
leave
a
bunch
of
running
on
Google,
you're
gonna
have
ability
under
the
months
that
you
need
to
pay
attention
to.
D
So
that
is
one
thing
for
people
to
think
about
another
aspect
that
I
see
very
often
that
people
don't
know
what
to
do
with
is
config
files.
So
you
scroll,
Twitter,
you
scroll,
kubernetes,
Twitter
for
five
minutes
and
there's
a
joke
about
llamo
and
we
all
hate
addressing
llamo.
But
again
the
same
way.
People
make
jokes
about
using
about
kubernetes,
citing
your
laptop
on
fire.
D
I
would
argue
that
you're
not
meant
to
add
it
Kuban
at
ezmo
by
hand
and
the
tooling,
for
that
is
arguably
not
as
mature
as
the
tooling
when
it
comes
to
Q&A
disclosers,
to
run
on
your
laptop.
So
you
have
stuff
like
helm
templates.
You
have
case
on
it,
I
think
there's
one
called
customized,
but
I
haven't
used
it
myself.
D
So
what
I
see
in
every
company
from
the
two-person
team
to
the
600
person
team
is
no
one,
writes
kubernetes
ammo
by
hand,
so
everyone
uses
a
template
solution,
a
templating
solution
of
some
sort,
and
that
is
the
first
thing
that
I
always
tell
people
when
they
start
making
jokes
about
yeah
Melissa
if
you're
addressing
ammo
by
hand
you're
doing
it
wrong.
So
you
shouldn't
do
that
in
the
first
place.
It's
something
that
you
set
up
once
at
some
point
and
you
look
at
it
whenever
you
need
to.
B
D
Let
me
show
you
one
last
thing,
then,
because
that
is
what
I
do
personally,
so
one
more
thing
that
we
can
discuss
is
the
development
feedback
loop,
so
you're.
Writing
your
code,
you're
working
on
your
application.
You
make
a
change
to
your
code.
How
much
work
is
it
for
you
to
see
that
new
line
of
code
that
you
just
wrote,
live
and
running
for
most
people?
It's
a
very
long
journey.
I
asked
that
on
Twitter,
a
lot
of
people
said
it
was
over
half
an
hour.
D
A
very
tiny
amount
of
people
said
it
was
between
five
minutes
and
half
an
hour
and
only
a
very
tiny
fraction
of
people
said
it
to
us
two
seconds
or
less
and
the
goal
of
my
job
of
my
work.
The
goal
of
tilt
the
tool
which
is
made
by
the
company
I
work
for
also
called
out
ice
to
get
everyone
in
that
two
seconds
range
I've
done
that
on
stage
and
talks
where
we
we
take
an
application
and
we
go
from
okay.
Every
time
you
make
a
change,
you
need
to
build
a
new
docker
image.
D
You
need
to
push
it
to
a
registry.
You
need
to
update
your
cluster
bubble
bar
and
that's
gonna.
Take
minutes
whole
minutes,
and
we
take
that
from
all
that
long
and
we
dial
it
down
to
a
couple
seconds.
So
you
make
a
change
or
save
your
file,
snap,
your
fingers
and
poof
it's
up
and
running
the
new
version
of
your
app.
So
it's
basically
a
real-time
perceptually,
real-time,
just
like
back
in
when
everyone
was
doing
Ruby
on
Rails,
and
you
would
just
save
your
file
and
see
if
it
worked
basically
instantly.
B
Gonna
love
to
jump
into
the
how,
in
a
little
bit,
I
want
to
circle
back
to
the
beginning.
I
love
the
question
that
Michael
asked
at
the
beginning
what
is
considered
developer
because
that
really
makes
a
difference
first
to
understand
who
we
are
talking
about
and
I
think
this
conversation
can
go
in
circles
and
not
that
I'm
saying
we
are
going
circles,
but
this
conversation
out
in
the
wilds
can
go
in
circles
until
we
have
an
understanding
of
the
difference
between.
B
Can
you
as
a
developer,
use
kubernetes
in
a
somewhat,
not
pain,
pain,
painful
way,
but
should
you
and
I'm
very
interested
interested
to
take
to
get
your
take
in
micro
interface
tags
as
well?
As
far
as?
Should
we
be
doing
this
and
should
all
of
the
developers
will
be
using
kubernetes
throughout
through
the
development
process?
And
then
we
also
have
to
consider
people
who
are
not
using
kubernetes,
because
a
lot
of
people
out
there
are
not
using
communities
and
for
developers
and
special
they
hear
our
kubernetes
is
painful
indefinitely
enough
for
developers.
B
So
obviously,
that
is
not
always
going
to
qualify
kubernetes
as
a
tool
that
the
going
to
look
in
so
it's
just
now
motivating.
So
if
there
is
any
editing
that
that
would
make
people
motivated
to
look
into
coronaries,
that
would
be
official
for
them,
not
just
for
you
know
using
kubernetes
for
kubernetes
sake,
but
would
it
be
useful
basically
why
why
would
a
beautiful
I
think.
D
From
the
point
of
view
of
a
developer,
you
should
try
and
stay
away
from
cuban
ids
for
as
long
as
you
can
see,
burn
IDs
comes
in
when
you
start
having
issues
of
scale.
So
it's
a
production
matter.
It's
not
a
development
matter,
so
I
don't
know
like
a
devops
issue
operations
issue.
Ideally
you
you
put
off
moving
your
application
to
cuban
at
ease
as
long
as
possible,
and
this
is
an
opinion
we
can
argue
about
this
forever,
just
because
it
introduces
a
lot
of
complexity.
D
And
if
you
don't
need
that
complexity,
you
should
probably
stay
away
from
it.
But
to
get
to
the
other
half
of
the
question,
which
is,
if
you're
using
cuban
at
ease
and
production,
should
you
use
cuban
at
ease
and
development?
Now
here,
I'm
gonna
say
yes,
100%
of
the
time
blanket
statement.
Of
course
we
can
argue
about
minutiae,
but
I
think
so
because
if
you
don't
you
end
up
having
separate
environments,
so,
let's
say
you're
using
docker
compose
because
you
don't,
like
you,
burn
at
ease,
so
you're
using
Cuban
IDs
in
production.
D
So
in
development
you
are
going
to
need
containers
of
some
sort.
So
let's
say
you're
using
docker
compose
now
you're
maintaining
two
different
environments.
You
update
something
here.
You
have
to
update
it
there
one
day
it's
going
to
be
Friday
you're,
going
to
be
tired,
you're
going
to
update
something
here,
you're
going
to
forget
to
update
something
there
or
you're
gonna
update
something
there
and
it's
going
to
be
slightly
different
or
maybe
you're
doing
something
that
has
no
equivalent
between
what
you're
using
locally
in
what
you're
using
in
production
and
then
basically
you're
in
trouble.
D
So
I've
seen
I've
heard
from
many
companies
that
the
main
reason
they
decided
to
use
Cuban
IDs
in
development
is
that
they
wanted
to
mimic
production
as
closely
as
possible.
One
argument
we
can
have
here
is
that
oh,
but
if
you're
using
cuban
at
ease
in
development,
that's
gonna
adds
a
lot
of
overhead
and
you're
not
going
to
be
able
to
do
your
job
right,
and
I
agree
that
that
was
true
for
a
while.
D
But
right
now
we
have
enough
tooling
that
you
can
basically
make
Cuban
IDs
disappear
and
you
just
focus
on
being
a
developer.
Writing
your
code,
doing
all
of
that
stuff
and
Kira
Nerys
is
sitting
there
in
the
back.
You
don't
have
to
think
about
it,
and
you
can
just
go
on
about
your
business
with
the
advantage
that
now
your
development
environment
and
your
production
environment
are
going
to
very
closely
mimic
each
other,
so
you're
not
going
to
have
issues
with
those
potential
disparities.
D
B
Right,
so
another
thing,
too,
is
that
I
think
we're
making
an
assumption
that
the
developers
we
are
talking
about
are
the
kind
of
developers
they're
also
responsible
for
deployment.
Sometimes
that's
the
case.
Sometimes
that's
not
the
case
and
I'm
gonna
shut
up
now,
but
it
would
be
interesting
to
talk
about
that
too.
Between
all
of
us
is
that
what
we
see
is.
Is
there
like
the
case
that
now
the
developers
are
responsible,
it's
like
developers.
Devops
is
just
so
ubiquitous
that
we
don't
even
consider
differentiate
between
developers
and
people
all
right.
C
What
a
different
spin
on
it
I
think
that
it's
not
necessarily
that
developers
are
the
ones
operating
the
infrastructure.
The
problem
is
that,
if
your
infrastructure
is
operated
by
a
platform
that
that
may
require
some
integration
at
the
application
layer
to
really
hit
its
stride,
then
the
question
becomes:
how
do
you
as
a
developer
become
more
familiar?
What
is
a
user
experience
as
if
or
what
I
should
say?
What's
the
developer
experience
around
that
integration
like?
C
What
can
you
do
to
improve
that,
so
that
the
developer
can
understand
better
or
play
with
how
service
discovery
works
or
understand
better
or
play
with
how
the
different
services
in
their
application
will
be
able
to
interact
without
having
to
kind
of
redefine
that
in
different
environments,
which
is
I?
Think
what
Ellen's
point
was
yeah.
D
But
the
most
basic
level
you
have
issues
as
such,
as
you
made
a
change
to
a
service
a
year.
Let's
say
on
your
local
darker
compose
and
now
you
need
to
update
your
kubernetes
manifests
on
your
cluster
for
things
to
make
sense.
So,
let's
say
I,
don't
know
you
change
the
name
of
a
service,
something
as
simple
as
that.
Even
those
kinds
of
things
that
sounds
silly
to
even
describe
when
you're
doing
that.
E
Was
the
same
with
Wilson
drift?
Maybe
even
if
you
use
kubernetes
locally,
you
might
run
a
later
version
of
kubernetes,
maybe
use
kind
for
local
development.
But
then
your
cluster,
your
remote
cluster,
is
on
on
three
or
four
versions
behind
shouldn't
be
because
of
the
version
support
policy,
but
it
might
happen
right
and
so
then
api's
might
be
deprecated
or
you're
using
different
api's.
E
You
could
mimic
lambda
runtimes
locally,
but
essentially
it's
gonna
be
thrifty,
it's
gonna
be
different,
and
so,
but
that
that's
also
a
common
complaint
in
in
the
world
of
AWS
and
cloud
development,
which
is
it's
really
not
that
easy
to
develop
locally,
where
you're
supposed
to
develop
on
the
platform
that
that
the
code
is
being
shipped
and
run
on
to
because
you
cannot
run
the
cloud
locally
yeah.
That
sounds
crazy,
but
it
is,
and
so
even
I
think
the
same
is
with
kubernetes.
E
Even
though
we
have
the
tools
I,
don't
think
that
every
developer
runs
kubernetes
locally.
Most
of
them,
maybe
don't
even
have
to
offer
locally.
So
they
the
use
of
spring
tools,
and
then
they
have
some
pipeline
and
eventually
it
gets
shipped
as
a
container
part
in
kubernetes
and
that's
what
I
wanted
to
throw
in
here
is
a
more
like
a
question
experience,
especially
for
you,
free
URL
and
with
these
customers
that
you
work
with.
What
are
the
different
profiles
that
you
see
from
a
maturity
perspective
on
these
customers?
E
D
So
when
it
comes
to
who
operates,
kubernetes
who
deploy
to
kubernetes,
definitely
most
developers
push
their
code
to
Cuban
Ares
themselves.
So,
of
course,
this
involves
CI
and
testing
and
PRS,
and
all
of
that,
so
it's
not
like
you-
can
just
go
crazy
and
break
everything
when
it
comes
to
operating
the
production
cluster,
then
that's
separate.
So
usually
you
have
someone
writing
code
and
someone
else
operating
closer's
and
infrastructure.
D
Sometimes
it's
the
same
person
but
they're
kind
of
clearly
separate
roles,
even
even
if
it's
the
same
person
doing
it,
but
usually
you
go
from
your
IDE
to
PR,
and
that
goes
straight
into
production
once
the
whole
process
is
done
and
now
we
were
talking
about
workflows
and
lambda,
and
all
of
that
so
I
don't
see
a
good
solution
for
lambda
like
a
good
development
experience
for
lambda
just
yet
so
it
feels
a
bit
like
it
needs
some
refinements
to.
When
it
comes
to
kubernetes,
you
asked:
do
most
developers
run
kubernetes
locally?
D
Do
they
not
and
I?
Don't
I,
don't
know
about
the
numbers,
the
absolute
numbers
like?
Is
it
most
doing
this
or
most
doing
that
I'm,
not
sure
I?
Only
know
the
companies
I'm
in
touch
with
definitely
not
all
developers,
run
kubernetes
on
their
laptops,
because
it's
a
problem
of
scale
right
now.
We
are
basically
stuck
with
30
gigs
of
ram
on
our
laptops.
If
your
app
is
bigger
than
that
stuff,
like
you're,
not
going
to
run
it
on
the
laptop,
but
what
most
of
helpers
do?
D
Is
they
still
maintain
a
local
development
environment
where
they
can
do
development
without
going
to
CI
I?
Think
that
is
the
main,
the
main
question,
so
they
they
maintain
agility
in
their
development
process.
So
what
we
usually
see
when
you
don't
have
the
Kuban
IDs
on
your
laptop
and
you're,
using
remote
q
Brunetti,
so
a
remote
development
cluster
in
some
cloud
provider,
what
most
people
do-
and
this
is
not
the
companies
I
talk
to
this-
is
basically
everyone.
D
What
most
people
do
is
they
they
make
their
development
environment,
be
the
same
or
work
in
the
same
way
as
their
production
environment?
So
you
make
a
change
to
your
code.
You
have
to
push
a
PR
that
has
to
get
tested
by
CI,
it
has
to
get
approved
and
then
it
ends
up
in
the
kubernetes
cluster.
So
your
feedback
loop
as
a
developer
is
insanely
slow
because
there's
so
much
red
tape
between
you
changing
a
line
of
code
and
you
getting
a
new
process
running
in
your
cluster.
D
Now,
when
you
use
tools,
I
call
the
category
MDX
and
I
basically
coined
that
category
name
myself.
So
MDX
is
multi
service
development,
experience
tooling,
when
you
use
MDX
tools
and
that's
not
just
tilt
it.
Still,
it's
garden
where
I
used
to
work.
People
use
telepresence
like
that.
There
is
a
scaffold
from
Google
and
so
on.
There's
a
bunch
of
tools
when
you
use
a
tool
like
that,
you
can
have
your
your
feedback
loop
down
to
a
second
like
I,
said
before
so.
D
I
think
that
is
the
major
improvement
developers
can
do
if
they're,
using
cuban
artists
remotely
and
even
if
they're,
using
Cuban,
IDs
locally
I
would
guess
most
people
do
not
run
Cuban
artists
locally.
They
use
remotely
like
we
have
clients
our
clients.
We
have
users
who
don't
even
have
darker
on
their
local
machines,
because
if
you
have
the
right
to
lean,
you
can
change
the
files
on
your
machine.
You
have
suffer.
You
have
tooling
running
that
detects
those
five
changes.
D
It
syncs
those
five
changes
to
your
cluster,
the
cluster,
then
rebuilds
images
or
restarts
containers
or
syncs
live
code.
That's
already
running,
and
then
you
can
see
those
changes
reflected
in
your
development
cluster
right
away,
even
though
you
don't
even
have
darker
in
your
machine.
So
there's
all
of
those
possibilities
do.
E
D
Kubernetes
itself
has
enough
options
that,
if
that's
a
concern
to
you,
you
can
make
it
secure
most
people
don't
worry
about
it
that
much
because
it's
development
clusters
they're
not
accessible
to
the
public.
Usually
there's
like
you
know,
you
can
only
access
it
through
a
VPN
or
something
of
that
sort.
So
we
haven't
heard
about
security
issues
so
far,
I'm
sure
they're,
gonna
pop
up
at
some
point,
I'm,
not
sure
how
severe
it's
gonna
be
or
how
hard
it's
gonna
be
to
fix.
D
C
It
also
opened
me
up
to
the
idea
that,
like
you
know
like
it,
was
an
improvement
over
things
like
having
to
commit
a
new
log
line
against
a
particular
function
and
then
push
that
new
function
up
to
a
place
where
it
would
actually
get.
You
know
some
use
and
then
be
able
to
go.
Look
at
that.
A
lot
of
line
and
see
what's
coming
out
of
it
or
like
do
I
actually
have
enough
logs
to
even
put
together
what
went
wrong.
C
You
know
and
that'll
you
know,
set
of
use
cases
I
think
is
somewhat
addressed
by
tooling
like
this,
but
I
do
I
do
think
we
should
talk
about
like
how
did
we
get
here
and
like
how
does
that
actually
in
how
do
the
town
is
truly
like
this
address
of
those
things
and
like
which
use
cases
specifically?
Is
it
looking
to
address
I
guess
where
I'm
going
with
this
is
like
to
your
point
so
tooling,
like
tilt,
for
example.
C
Right
is
the
idea
that
you
can,
as
far
as
I
understand
it
inject
into
a
running
application,
a
new
instance
that
would
be
able
to
that.
You
would
have
like
whole
development
control
over
like.
If
you
make
a
change
to
that
code,
then
the
instance
running
inside
of
your
target
environment
would
would
be
represented
by
that
new
code
change
very
quickly,
right,
basically,
solving
the
problem
of
making
sure
that
making
sure
that
you
know
you
have
some
very
quick
feedback.
Loop
I
mean
like
functionally.
D
I
think
one
area
where
that
is
still
partially
untapped
right
now,
where
this
tooling
could
go
and
I'm
kind
of
pushing
it.
But
it
you
know
it's
a
process,
it's
not
something
we
can
do
overnight.
It's
to
have
very
high-level
patterns,
the
let's
say
codified.
So,
for
example,
everyone's
copying,
darker
files
and
cuber
Nattie's
manifests
and
terraform
can
take
files
which
I
forgot.
D
What
they're
called
everyone's
copying
that
stuff
from
the
internet
from
other
websites
and
that's
cool
like
oh,
you
need
a
container
that
does
such-and-such
and
sets
up
this
environment
and
provides
these
tools
just
download
this
image,
and
everything
is
all
set
up
for
you.
So
one
area
where
I
see
things
going
is
for
us
to
have
that
same
kind
of
portability,
but
for
development
environments.
So,
for
example,
I
did
this
whole
talk
about.
D
So
those
kinds
of
things
if
we
can
prepackaged
those
and
offer
those
to
users
and
not
just
for
go
and
not
just
ready
for
debugging
but
for
all
kinds
of
development,
workflows,
I,
think
that
would
be
really
great.
So
we
can
offer
those
types
of
experiences
to
people
who
don't
necessarily
have
the
inclination
to
develop
those
work,
clothes
themselves,
yeah.
C
I
agree
and
I
mean
it's
interesting.
I've
had
a
few
conversations
lately
about
the
fact
that,
like
you
know,
kind
of
the
the
abstraction
layer
of
coding
in
the
way
that
we
think
about
it,
really
hasn't
changed
over
time.
Right
like
it's,
the
same
sort
of
thing,
so
that's
actually
a
really
relevant
point
like
it's
also
interesting
to
think
about.
Like
you
know,
with
these
sorts
of
frameworks
in
this
sort
of
tooling,
it
might
be
kind
of
interesting
to
think
of
like
what
else
we
can.
C
What
else
we
can
enable
the
developer
to
have
a
feedback
loop
on
more
quickly.
Right,
like
if
you
know,
add
to
your
point
right,
like
we
talked
about
how
these
different
environments,
who
develop
an
environment
and
your
production
environment
like
the
the
general
consensus,
is
they
should
be
as
close
as
you
can
get
them
reasonably
alright,
so
that
the
behavior
in
one
should
somewhat
mimic
the
behavior
and
the
other,
at
least.
That's
that's
the
story.
C
We
tell
ourselves
right
so
given
that
like
what
it
also,
it
would
also
be
kind
of
interesting
if
the
developer
was
getting
feedback
from
like
effectively
how
the
security
posture
of
that
particular
cluster
might
affect
the
work
that
they're
doing
right
like
you,
do
actually
have
to
define
network
policy,
and
you
know,
maybe
you
don't
necessarily
have
to
think
about
it.
If
we
can
provide
tooling
that
can
abstract
that
away,
but
at
least
you
should
be
aware
that
it's
happening
so
that
you
understand
you
know
if
it's
not
working
correctly.
C
D
At
the
last
cube
con,
where
was
it
in
San
Diego?
There
was
this:
this
running,
joke
I
was
running
around
with
the
security
crowd
and
there
was
this
joke
about
Kubica
to
apply
security
IMO
and
it
was
kind
of
in
a
mocking
tone
and
I
mean
it.
Was
it
I'm
not
disparaging
their
joke?
It
was
a
good
joke,
but
then
I
was
thinking.
What,
if
we
can
make
this
real,
like
I
mean?
D
Maybe
it
is
real
I,
don't
know,
I,
don't
do
security
myself,
but
what
if
we
can
apply
a
comprehensive
enough
set
of
security
measures,
security
monitoring
security
scanning
all
that
stuff
we
prepackaged
it.
We
allow
users
to
access
all
of
that
with
one
command
or
even
less
than
that.
Maybe
you
pre
configure
it
as
a
team
lead
and
then
everyone
else
in
your
team
can
just
use
it
without
even
knowing
that
it's
there
and
then
it
just
lets.
You
know
like
oh
hey.
This
thing
you
just
did.
D
E
Cool
and
the
it
what
you
just
mentioned,
Allen
and
Duffy
remembers
me
on
reminds
me
on
the
spring
community
is
Spring
Framework,
where
a
lot
of
the
boilerplate
or
like
bead
security,
stuff
or
connections,
integrations,
etc.
It's
being
abstracted
that
way,
and
you
just
enter
Tait
your
code
of
it
and
then
some
framework
and
spring.
E
D
Yeah
so
because
I
won't
shut
up
about
this
stuff
because
I
just
love
it,
we
are
doing
a
it's
in
a
very
early
stage
right
now
we
are
doing
a
thing,
a
tote,
we're
calling
extensions,
so
very
creative
name
I
suppose,
but
it's
basically
like
going
parts
but
for
those
were
closed
and
it's
still
at
a
very
early
stage.
So
we
still
have
some
road
ahead
of
us.
But,
for
example,
we
have,
let's
say
this
one
user
and
they
did
some
very
special
integration
of
helm
and
tilt.
D
So
you
don't
have
to
use
helm
by
hand
anymore.
You
can
just
make
all
of
your
helm
stuff
happen
automatically
when
you're
using
totes
and
usually
you
would
have
to
copy
like
I,
don't
know,
100
lines
of
code
from
your
tilt,
config
file
and
copy
that
around
for
other
developers
to
be
able
to
use
it.
So
now
we
have
this
thing
that
it's
basically
like
going
part
where
you
can
just
say
load
extension
and
give
it
a
name.
D
It
fetches
it
from
a
repository
and
it's
running
so
I
think
that
is
basically
an
early
stage
of
what
you
just
described
it
spring.
But
more
for
more
geared
towards,
let's
say
an
emperor
kubernetes
like
how
do
you
tie
in
for
kubernetes
that
kind
of
stuff,
with
higher
level
functionality
that
you
might
need.
E
D
Usually
tilt
watches
your
code
files
and
it
doesn't
care
which
IDs
you
use.
It
has
its
own
dashboard,
which
is
just
a
page
that
you
open
on
your
browser.
I
have
just
heard
this
week,
someone
mentioned
on
slack
that
they
wrote
an
extension
for
Thoth
I'm,
not
sure
if
it
was
her
TS
code
or
the
other
vs
code,
like
dotnet
editors,
you
know
I,
don't
remember
what
it's
called,
but
they
have
like
a
family
of
those,
so
I
just
heard
that
someone
broke
on
those
and
they
shared
the
repo.
D
D
D
So
if
you're
going
to
create
a
views
code
extension
you
you
either
replicate
that
completely
and
you
basically
take
the
stuff
that
was
in
the
browser
and
put
it
in
the
IDE
I,
don't
particularly
see
much
benefit
and
in
that,
if
enough
people
ask,
maybe
we'll
do
it,
but
it's
not
something
that
I
find
particularly
useful.
So
either
you
do
that
and
you
replicate
the
functionality
or
you
come
up
with
new
functionality
and
in
both
cases
I
just
don't
see
a
very
strong
point
as
to
what
different
and
IDE
specific
functionality
should
you
want.
Yes,.
E
So
and
the
reason
why
I
was
asking
is
that
we
see
all
these
Palomas
cdks
AWS
CDKs,
coming
up
where
you
basically
use
a
programming
language
to
write
your
application,
slash
application
infrastructure
code
and
in
your
IDE
and
then
all
the
the
templating
that
the
demo
stuff
etc
gets
generated
under
covers.
And
just
this
week
AWS
announced
CD
kate's
like
the
city
cave
basically
for
for
kubernetes
and
I
was
thinking.
Was
this
with
this
happening?
Where
some
of
these
providers
abstract
the
the
scaffolding
as
well,
including
the
build
right?
E
You
don't
even
have
to
build,
because
it's
kind
of
abstracted
away
under
the
covers
I
was
seeing
this
trend
and
then
obviously
we
still
have
him
and
the
10
building
and
the
customers.
I
know
when
you
still
have
the
manual,
as
you
assume
I
mentioned
in
the
beginning,
and
so
I
do
like
the
IDE
integration,
because
that's
where
I
spend
most
of
my
time
and
whenever
I
have
to
leave
the
IDE,
it's
kind
of
a
context
which
died,
I
have
to
go
through,
and
even
if
it's
just
for
for
opening
another
file.
E
Also
that
I
need
to
edit
somewhere
and
that's
why
I
think
having
a
d--
integration
is
useful
for
developers,
because
that's
Rowdy
is
most
spent
at
that
time.
But,
as
you
said,
there
might
be
reasons
to
not
do
it
in
an
IDE,
because
you're
just
replicating
functionality
that
might
not
be
useful.
There
yeah.
D
So,
in
the
case
of
thoth,
all
the
config
is
is
written
in
Starlog,
which
is
a
language
and
it's
basically
Python.
So
if
your
IDE
can
syntax
highlight
Python,
it
can
syntax
highlight
the
till
config
files
about
below
me
and
that
kind
of
stuff
I'm,
not
that
familiar
it's
stuff,
that
I
kind
of
know
how
it
works,
but
I
haven't
used
it
myself,
so
I'm
not
familiar
with
the
brows
and
the
the
IDE
integration
side
of
it.
D
The
thing
about
tools
like
tilt
is
that
usually,
if
you
said
set
it
up
right,
you
can
just
write
your
code
all
day
and
you
don't
have
to
look
at
the
tool.
You
just
switch
from
your
IDE
to
let's
say
your
browser
where
your
app
is
running,
so
you
get
feedback
and
that
kind
of
thing,
but
once
you
configure
it,
you
don't
really
spend
much
time
looking
at
it,
you're
gonna
look
at
it
when
there
are
errors,
so
you
know
you
try
to
refresh
your
application
and
it
fails.
D
B
B
Well,
if
you're
going
to
be
the
point,
two
coordinators
in
production,
you
should
consider
running
kubernetes,
so
local
development
environment
now
for
those
developers
who
don't
even
haven't
even
worked
with
kubernetes,
where
do
you
suggest
they
jump
in
to
they
sort
of
get
a
handle
on
work,
because
it's
too
many
things
that
we
covered
areas
already
so
big,
and
there
are
so
many
toolings
around
how
to
operate
kubernetes
itself
so
for
developer?
Who
is
ok?
B
I,
like
this
idea
of
having
my
own
local
kubernetes,
that
environment
or
a
development
environment
somehow
may
also
be
in
the
cloud?
Should
they
start
with
a
two
lane
like
tilt
or
something
similar?
Would
that
make
it
easier
for
them
to
wrap
their
head
around
kubernetes
and
well
coburn
ares
does
why
should
they
first
get
a
handle
on
kubernetes
and
then
look
at
a
tool
like
this.
D
Ok,
so
there
are
a
few
sides
to
this
question.
If
you
have
a
very
large
team,
ideally
you
should
get
one
or
a
few
people
to
actually
really
learn
kubernetes
and
then
make
it
so
that
everyone
else
doesn't
have
to
so.
Something
we
have
seen
is
like
very
large
company.
They
are
gonna,
do
kubernetes
in
development.
They
set
up
a
developer,
experience
team
and
then,
for
example,
they
have
their
own
wrapper
around
cube
cuddle
and
then
basically,
they
automate
a
bunch
of
stuff
so
that
everyone
and
the
team
doesn't
have
to
take.
D
You
know
a
certified
kubernetes
application
development
certificate
because,
like
for
people
who
don't
know
that
certificate,
it's
basically
how
much
Cube
kettle
can
you
do
off
the
top
of
your
head?
That
is
basically
what
that
certificate
is
about,
because
cube
kettle
is
it's
an
insanely,
huge
and
powerful
tool?
So,
on
the
one
hand,
you
should
do
that
if
you
have
a
big
team,
take
a
few
people
learn
all
that
you
can
about
kubernetes
write
some
wrappers
so
that
people
don't
have
to
do
cube
code
or
something
something
by
hand.
D
Just
make
very
easy
functions
like
you
know,
cube
Caudill.
Let's
say
you
know
a
name
of
your
rapper
context
and
a
name
and
then
that's
gonna
switch
you
to
a
namespace.
Let's
say
where
some
version
of
your
app
is
running.
So
that
kind
of
thing
now
about
the
tooling.
Once
you
have
your
development
environment
set
up
and
you're
going
to
need
someone
who
has
some
experience
with
kubernetes
to
set
that
up
in
the
first
place,
but
once
that
setup,
if
you
have
the
right
to
link
you,
don't
really
have
to
know
everything
that
kubernetes
does.
D
So
you
can
abstract
a
bunch
of
stuff
with
basically
good
sense,
so
that
you
know
the
common
operations
that
need
to
be
done
for
your
team
and
then
you
just
abstract
them
away,
so
that
people
don't
have
to
become
cube,
cuddle
experts
and
on
the
other
side,
you
can
also
abstract
a
bunch
of
stuff
away
with
tooling
and
basically,
as
long
as
your
developer
has
you
know
the
basic
grasp
of
containers-
and
you
know,
basics
of
cuban
IDs-
that
kind
of
stuff.
They
don't
need
to
know
how
to
operate
it
with
any
kind
of
depth.
D
E
Ellen
in
the
beginning
is
said
that,
like
it's
all
about
this
feedback,
loop
and
it'll,
reading
fast
and
part
of
a
feedback
loop
for
a
developer
is
unit
testing,
integration,
testing
or
all
sorts
of
testing.
How
do
you
see
that
changing
or
being
like
benefiting
from
tools
like
tilt,
especially
when
it
comes
to
integration?
Testing
unit,
is
usually
locally,
but
the
integration
testing
so.
D
D
You
could
basically
set
up
a
script
that
there's
a
bunch
of
stuff
which
would
basically
be
what
your
test
does,
and
if
it
returns
zero,
it
succeeded
if
it
does
and
it
failed.
So
you
can
set
something
up
like
that.
It's
not
something
that
we
have
right
now
in
a
prepackaged
farm
that
you
can
use
right
away.
So
you
would
basically
just
say:
hey
tails
run
this
thing
for
me
and
then
you
would
see
if
it
worked
or
not.
I
have
to
make
a
plug
to
the
competition
right
now.
Garden.
D
Has
more
of
that
part
of
it
that
part
of
things
set
up.
They
have
tests
as
a
separate,
primitive
right.
Next
to
you
know,
building
and
deploying,
which
is
what
you
usually
see,
so
they
also
have
testing,
and
it
does
basically
what
I
just
said
about
tilt,
but
they
have
kind
of
a
special
little
framework
around
it.
D
So
with
garden,
you
would
say:
oh
here's,
a
test,
here's
how
you
run
the
test,
here's
what
the
test
depends
on,
etc,
and
then
it
runs
it
and
it
tells
you
if
the
tale
or
not
with
tilts
it
would
be
a
more
generic
approach
where
you
would
just
say,
hey
tilt
run.
This
tell
me
if
it
fails
or
not,
but
without
the
like
the
little
wrapping
around
it,
that
specific,
that's
specific
for
testing
when
it
comes
to
how
things
work
like
when
you're
trying
to
push
the
production.
D
Let's
say
you,
you
done
a
bunch
of
stuff
locally,
you're,
happy
with
it
now
it's
time
to
push
the
production
and
then
there's
all
that
had
a
quit
CI
and
waiting
for
test
run
and
flaky
tests,
and
all
of
that
that
I
don't
know.
That
is
a
big
open
question
that
everyone's
unhappy
about
and
no
one
really
knows
which
way
to
run
to
that's.
C
Not
something
where
do
you
see
the
space
going
in
the
future
I
mean
like
that,
like
as
you
look
at
the
tooling,
that's
out
there,
maybe
not
specifically
till
it
tilt
particular
service
or
capability,
but
like
where
do
you
see
some
other
people
kind
of
exploring
that
space
like
we
were
talking
about,
like
AWS,
dropping
a
CD
k
and
they're
like
definitely
different
people
trying
to
solve
the
mo
problem,
but
like
more
from
the
developer
user
experience
tooling
kind
of
way
like?
Where
do
you
see
that
kind
of
space
going
for.
D
Me
it's
all
about
higher
level
abstractions
and
well-defined
best
practices.
So
right
now,
everyone
is
fumbling
around
in
the
dark,
not
knowing
what
to
do
trying
to
figure
out
what
works
and
what
doesn't
the
main
thing
that
I
see
changing
is
that,
given
enough
time
best
practices
are
going
to
emerge
and
it's
going
to
be
clear
for
everyone.
If
you're
doing
this
kind
of
thing,
you
should
use
this
kind
of
workflow.
If
you're
doing
that
kind
of
thing,
you
should
use
that
kind
of
workflow.
D
D
Don't
know
how
to
build
the
Linux
kernel,
even
though
I
use
Linux
every
day,
I
think
things
should
be
wrapped
up
in
a
way
that
developers
can
focus
on
what
matters
to
them,
which
is
right
now,
basically,
writing
code,
so
developers
should
be
able
to
you
know,
get
to
the
office
in
the
morning
open
up
their
computer
start
writing
code
or
doing
whatever
else
they
want
to
do
and
not
worry
about
your
bernardi's.
Not
worry
about
lambda
not
worry
about.
D
B
B
We
know
today
there
are
so
many
tools,
but
I
think
probably
we're
going
to
get
to
a
point
where
we
know
what
to
use
for
what
in
the
future,
and
with
that
we
have
to
wrap
up,
because
we
are
at
the
top
of
the
hour.
It
was
so
great
to
have
Ellen
or
Elle
how
she
I
think
prefers
to
be
called
and
to
have
you
on
the
show.
I
would
thank
you
so
much
I
mean
Elsie.
I
can't
even
follow
my
own
and
you're.
B
Very
active
on
Twitter
we're
going
to
have
all
the
information
for
how
to
reach
you
on
the
show
notes,
we're
going
to
have
a
transcript
and,
as
always
people
subscribe,
follow
us
on
Twitter,
so
you
can
be
up
to
date
with
what
we
are
doing
and
suggest
episodes
to
when
our
github
repo,
and
with
that.
Thank
you,
everybody.
Thank
you.
He'll
thank.