►
From YouTube: Kubernetes as per Kelsey Hightower (The Podlets, Ep 7)
Description
Kelsey begins by telling us what he has been doing and shares with us his passion for learning in public and why he has chosen to follow this path. From there, we then talk about the issue of how difficult many people still think Kubernetes is. We discover that while there is no doubting that it is complicated, at one point, Linux was the most complicated thing out there. Now, we install Linux servers without even batting an eyelid and we think we can reach the same place with Kubernetes in the future if we shift our thinking!
For the show notes and transcript: https://thepodlets.io/episodes/007-kubernetes-as-per-kelsey-hightower/
Feedback and episode suggestions:
https://twitter.com/thepodlets
https://github.com/vmware-tanzu/thepodlets/issues
info@thepodlets.io
Special guest
https://twitter.com/kelseyhightower
Hosts
https://twitter.com/carlisia
https://twitter.com/bryanl
https://twitter.com/embano1
https://twitter.com/mauilion
Photo credit: http://www.facesofopensource.com/kelsey-hightower-2/
B
C
B
C
So,
every
six
months,
or
so
so
cooper
neighs
the
hard
way
for
those
that
don't
know
it's
a
guide,
a
tutorial.
You
can
copy
and
paste
it
takes
about
three
hours
and
the
whole
goal
of
any
guide
was
to
teach
people
how
to
stand
up
a
kubernetes
cluster
from
the
ground
up
right.
So
starting
from
scratch.
Six
VMs,
you
install
SVD
all
the
components,
the
nodes,
and
then
you
run
a
few
tests
were
close,
so
you
can
get
a
feel
for
kubernetes
and
the
history
behind
that
was
when
I
first
joined
Google.
C
C
Docker
swarm
is
that
at
the
time
a
lot
of
people
are
using
meso
s--
and
we're
wondering
like
a
lot
of
the
feedback
at
that
time
was
kubernetes
is
too
complex,
so
kubernetes
our
Hardaway
was
built
as
a
idea
that
if
people
understood
how
it
worked
just
like
they
understand
how
Linux
works,
because
that's
all
so
complex
that
it
people
just
saw
how
the
moving
pieces
fit
together,
then
they
would
complain
about
the
less
about
the
complexity
and
have
a
way
to
kind
of
graphs.
It.
A
B
Thank
you
for
doing
that.
I
totally
forgot
to
introduce
who
I
was
on
the
show
and
inmate
Alicia,
and
we
did
not.
We
didn't
plan
what
the
topic
is
going
to
be
today.
I
will
take
a
wild
guess
and
we
are
going
to
touch
on
kubernetes,
I
love,
I
have
so
many
questions
for
your
kelsey,
but
first
and
foremost,
why
don't
you
tell
us
what
you
would
love
to
talk
about?
B
One
thing
that
I
love
about
you
is
that
every
time
I
see
I
hear
an
interview
of
you,
you're
always
talking
about
something
different
or
you're
talking
about
the
same
thing
in
a
different
way.
I
love
that
about
the
way
you
speak
and
and
I
know
you
offered
to
be
on
a
lot
of
podcast
shows
and
which
is
how
we
ended
up
here
and
I
was
thinking.
B
Oh
my
gosh,
you
know
we're
going
to
talk
about
what
everybody's
going
to
talk
about,
but
I
know
that's
not
going
to
happen
so
feel
free
to
get
the
conversation
started
and
we
are
p.m.
wearing
engineers
here
so
come
at
us
with
questions,
but
also
what
you
would
like
to
talk
about.
What
an
hour
show
today,
yeah.
C
So
I
mean
we're
all
just
coming
straight
off
the
heels
of
coop
con
right.
So
this
big
12,000
people
getting
together
we're
super
excited
about
kubernetes
reinvent,
is
just
you
know.
In
the
midst
of
reinvent
things
are
wrapping
up
there
as
well.
So
when
we
started
to
think
about
kubernetes
and
what's
going
to
happen
and
a
lot
of
people
saw
Amazon
jump
in
with
Fargate
for
eks
right,
so
those
unfamiliar
with
that
offering
over
the
years
all
the
cloud
providers
have
been
providing
some
hosted
Cabernets
offering.
C
The
idea
is
that
the
cloud
provider
just
like
we
do
with
hypervisors
and
virtual
machines
would
provide
the
base
infrastructure.
So
you
can
focus
on
using
kubernetes,
and
you
seen
this
even
flow
down
on
prim
with
VMware
right,
then
we're
saying,
hey,
kubernetes
is
going
to
be
a
part
of
this
control
plane
that
you
can
use
to
criminate
API
to
manage
virtual
machines,
then
containers
on
Prem.
So
at
some
point
now,
where
do
we
go
from
here?
C
There's
a
big
service
movement
which
is
trying
to
eliminate
infrastructure
for
all
kind
of
components,
whether
that's
compute
databases
or
storage,
but
even
in
the
kubernetes
world,
I
think
there's
an
appetite,
and
we
saw
this
with
our
gate
that
we
need
to
make
the
kubernetes
cluster
disappear
right.
If
we
can
make
it
disappear,
then
we
can
focus
on
building
new
platforms
that
extend
the
API
or
hell
just
using
Cooper
neighs,
as
is
without
thinking
about
managing
nodes,
operating
systems
and
Auto,
scalars
and
I.
C
Think
that's
kind
of
been
a
topic
that
I'm
pretty
interested
in
talking
about,
because
that
future
means
lots
of
things
disappear.
Right,
programming,
languages
and
compilers
made
assembly
disappear
for
a
lot
of
developers
assembly.
Still,
there
I
think
people
get
caught
up
on.
Nothing
goes
away
there
right,
nothing
goes
away,
but
the
number
of
people
who
have
to
interact
with
that
thing
is
greatly
reduced.
You.
D
Know
what
Kelsey
I'm
gonna
have
you
get
out
of
my
brain,
because
that
was
the
exact
example,
but
I
was
going
to
use.
I
was
on
a
bus
today
and
I
was
thinking
about
all
the
hubbub
about
the
whole
Fargate
eks
thing
and
then
I
was
thinking
well,
you
know
go,
for
example,
can
generate
assembler
and
then
it
compiles
that
down.
No
one
complains
about
the
length
of
the
assembler
that
go
generate.
Some
cares
and
that's.
How
would
you
think
about
this
problem?
That's
a
that's
a
whole
salt
problem.
Let's
think
about
bigger
things
and.
C
I
think
is
because
of
operations
we
tend
to
identify
ourselves
as
the
people
responsible
for
running
the
nodes
where
the
people
were
responsible
for
tuning
the
API
server.
So
when
someone
says
it's
going
to
go
away
in
UPS-
and
you
see
this
in
some
parts
right
so
op,
some
people
focus
a
lot
more
on
the
server
ability
they
can
care
less
about
what
machines.
The
thing
runs
on
they're
still
going
to
try
to
observe
and
tune
it.
C
You
see
this
in
SRA
and
some
various
practices,
but
a
lot
of
people
who
came
up
in
the
world
like
I,
have
in
a
traditional
ops
background.
You
were
the
one
that
pixie
booted
the
server
you
installed
that
Linux
OS
you
configured
it
with
puppet.
So
when
someone
tells
you
we're
going
to
move
on
from
that
as
if
it's
a
good
thing,
that's
my
job.
Definitely.
A
We've
brought
we
trucked
this
topic
through
a
couple
of
different
times
on
this
show
as
well,
and
it
definitely
comes
back
to
like
understanding
said,
I
least
in
my,
in
my
opinion,
it's
not
about
whether
there
we'll
be
work
for
people
who
are
in
operations.
People
who
want
to
focus
on
that.
The
real
question
to
come
to
mind
is
like
there
is
so
much
of
that
work
that
how
are
so
few
of
us
going
to
be
able
to
accomplish
it
unless
we
radically
rethink
how
it
will
be
done
like
we're
vastly
outnumbered.
A
C
Early
days
we
had
this
goal
of
abstract
or
automating
ourselves
out
of
a
job,
and
anyone
that
tried
that
a
number
of
times
knows
that
you're
always
gonna
have
something
else
to
do
and
I
think
if
we
carry
that
to
the
infrastructure.
I
want
to
see.
The
ops
folks
like
I
was
very
surprised
that
doctor
didn't
come
from
operations
folks,
it
came
from
the
developer
folks
same
thing
for
vagrant
and
the
same
thing
from
kubernetes.
These
are
the
developer
minded
folks
that
want
to
tackle
ever
structure
problems
and
I.
C
D
That's
exactly
what
we
should
do
and,
like
you
said
Kelsey
we
will
always
have
a
job.
Whenever
we
solve
one
problem,
we
could
think
about
more
interesting
problems.
We
don't
think
about
Linux
phone
servers
anymore.
We
just
put
server
Linux
on
servers
and
we
run
it.
We
don't
think
about
the
15
years,
where
it
was
a
little
rocky.
That's
gone
now
so
think
about
what
we
did
there
and
let's
do
that
again
with
what
we're
doing
now.
Yeah.
C
I
think
the
Prometheus
community
is
a
good
example
of
operations,
might
have
folks
producing
a
system
like
when
you
meet
the
kind
of
the
originators
of
Prometheus.
They
took
a
lot
of
their
operational
knowledge
and
kind
of
built.
This
metrics
and
monitoring
standards
that
we
all
kind
of
think
about.
Now,
when
we
talk
about
you
know
some
levels
of
observability
and
I
think
that's
what
happens.
We
have
good
operations,
people
that
take
prior,
you
know,
experience
the
knowledge,
and
that
can
happen
in
the
code
these
days.
C
D
E
You
see
the
world
changing
to
silver,
less
to
higher
abstractions,
more
complex
systems
on
one
hand,
but
then,
on
the
other
side,
we
have
ups
and
looking
beyond
or
outside
the
world
of
Silicon
Valley
into
the
traditional
ops
at
the
traditional
large
enterprise.
And
what
do
you
think
is
the
current
majority
level
of
these
ops
people
and
I
don't
want
to
discriminate
anyone.
You
know
I'm,
just
basically
throwing
this
out
as
a
question
and
where
do
you
think
do
they
need
to
go
in
terms
of
to
keep
up
with
this
evolving
and
higher
level?
C
So
this
is
a
good
good
question.
I
spend
half
of
my
time,
so
I
probably
spend
time
on
site
with
at
least
100
customers
a
year
globally.
I
fly
on
a
plane
and
visit
them
in
the
home
turf,
and
you
definitely
meet
people
at
various
skill
levels
and
areas
of
responsibility.
I
wanna
make
sure
that
I'm
clear
about
the
areas
of
responsibility,
sometimes
you're
hired
in
an
area
of
responsibility.
That's
below
your
skill
set
all
right.
Some
people
are
hired
to
manage
batch
jobs
or
to
translate
files
from
XML
to
JSON.
C
That
really
doesn't
say
a
lot
about
their
skill,
set
just
kind
of
talks
about
the
area
of
responsibility,
so
shout
out
to
all
the
people
that
are
dealing
with
mainframes
and
having
to
deal
with
that
kind
of
stuff.
But
when
you
look
at
it
there,
you
know
you
have
the
opportunity
to
rise
up
to
whatever
level
you
want
to
be
in
terms
of
your
education.
So
when
we
talk
about
this
particular
question,
some
people
really
do
see
themselves
as
operators
and
there's
nothing
wrong
with
that,
meaning
they
come
in.
C
They
get
a
system
and
they
turn
the
knobs.
You
gave
me
a
mainframe
I
will
tell
you
how
to
turn
the
knobs
on
that
mainframe.
You
buy
me
a
microwave
I'll.
Tell
you
how
to
pop
popcorn
they're,
not
very
interested
in
building
in
microwave.
Maybe
they
have
other
things
that
are
more
important
to
them,
and
that
is
totally
okay.
C
Then
you
have
people
who
are
always
trying
to
push
the
boundaries
so
before
kubernetes
think
about
if
I
think
back
to
10
years
go
maybe
eight
when
I
was
working
in
a
traditional
Enterprise
like
the
kind
of
ones
you're
talking
about
our
hinting
that
the
goal
has
always
been
to
abstract
away
all
of
the
stuff
that
it
means
to
deploy
an
application.
The
right
way
in
a
specific
environment
for
that
particular
company
and
the
way
I
managed
to
do
it
was
to
say,
hey.
Look.
C
We
have
a
very
complex
change
management
process,
I
work
in
finance
at
the
time,
so
everything
had
to
have
a
ticket,
no
matter
how
good
the
auto
mission
was,
so
I
decided
to
make
JIRA
the
ticketing
system
the
front
door
to
do
everything,
so
you
go
to
jera,
there'll,
be
a
custom
field
that
says:
hey
here
are
all
the
RPMs
that
have
been
QA
by
the
QA
team.
Here's
all
the
available
environments.
You
put
those
two
fields
in
that
ticket
goes
through
change
of
management
and
approval
and
then
something
below
the
scenes,
automated
everything.
D
Also
think
about
other
other
verticals
so
23
years
ago.
I
did
this
a
bit
work,
that's
that
was
my
job,
but
we
learned
how
to
program
and
C
and
C++,
because
we
were
on.
We
were
on
old
funds,
not
even
spark
machines.
We
were
on
the
old
suns
and
we
wanted
to
write
things
on
CDE
and
we
wanted
to
write
our
own
window
managers.
But
that
is
what
we're
doing
right
now
and
that's
why
you
see
like
Mitchell
Hashimoto
with
vagrant
and
you're,
seeing
how
we're
pushing
this
thing.
D
C
You
and
I
care
about
creating
the
next
big
thing.
There
are
parts
of
my
life
where
I
just
don't
care,
for
example,
I
pay,
Comcast
to
get
internet
access,
and
my
ops
involvement
was
going
to
Best
Buy
and
buy
a
new
modem
and
screwed
it
into
the
wall
and
I
troubleshoot.
This
thing
every
once
in
a
while
and
someone
in
the
household
complains,
the
Internet
is
there,
but
that's
as
far
as
I'm
ever
going
to
push
the
internet.
Boundaries
right,
like
I,
am
not
really
interested
in
pushing
that
forward.
I'm,
assuming
others
will
and
I.
C
A
Yeah
for
me
personally,
I
definitely
identify
as
an
Operations
person.
I,
don't
I,
don't
I,
don't
consider
it
my
life's
goal
to
create
new
work
necessarily
but
to
expand
on
the
work
that
has
been
identified
and
to
help
people
understand
the
value
of
it
right.
So
I
I,
find
I
sit
in
between
two
roles
personally,
like
one
is
to
help
figure
out
all
of
the
different
edges
and
pieces
and
parts
of
kubernetes
or
some
other
thing
in
the
ecosystem
and
second
to
educate
others
on
those
things
right.
B
One
thing
that
I
wanted
to
ask
you:
Klaus
is
so
I
work
with
on
the
little
project
and
that
does
makeup
and
recovery
of
kubernetes
cluster
ease
and
some
people
ask
me.
Ok,
so
tell
me
about
the
people
who
are
doing
back
out
so
I'm
like
I,
don't
know,
that's
boring,
I,
wonder
about
the
people
who
are
not
doing
backups.
It's
like
ok,
they're.
You
know,
let's
talk
about
why
you
should
be
doing.
Maybe
thinking
about
that
anyway.
B
C
Yes,
oh,
let's
use
your
backup
example,
so
I
think
when
I
hear
questions
at
least
lets
me
know
what
people
are
thinking
and
where
they're
at
and
if
I
ask
enough
questions,
I
can
kind
of
get
a
pulse
and
the
trend
of
where
the
majority
of
the
people
are.
So,
let's
take
the
backups
question:
when
did
I
hear
people
say
I
want
to
back
up
my
kubernetes
cluster
I
really
wanted
to
clock.
In
my
mind
and
say:
wow
I.
C
Remember
we
used
to
backup
Linux
servers
because
we
didn't
know
what
the
config
files
were
on
the
disk.
We
didn't
know
where
processes
were
running,
so
we
used
to
do
these
PS
snapshots
and
we
used
to
pal
up
the
whole
file
system
and
store
it
somewhere.
So
we
can
recover
it
like
Norton,
remember:
Norton
Ghost,
like
you,
take
a
machine
and
ghost
it.
So
you
can
make
it
again
and
then
we
said
you
know
what
that's
a
bad
idea.
C
What
we
should
be
doing
is
having
a
tool
that
can
make
any
machine
look
like
the
way
we
want
it
right.
Config
management
is
born,
so
we
don't
back
those
up
anymore.
So
when
I
hear
that
question
I
say
hmmm
what
what
is
happening
in
the
community,
that's
keeping
people
to
ask
these
questions,
because
if
I
hear
a
bunch
of
questions
that
I
already
have
good
answers,
that
means
those
answers
aren't
visible
enough.
I'm,
not
enough
people
are
sharing
these
ideas.
That
should
be
my
next
keynote.
C
Maybe
we
need
to
make
sure
that
other
people
know
that
that
is
no
longer
a
boring
thing,
even
though
it's
boring
to
me,
it's
not
boring
to
the
industry
in
general.
So
when
I
hear
these
questions,
I
kind
of
use
it
as
a
keeps
me
up
to
date,
keeps
me
grounded
right.
So
I
hear
stuff
like
how
many
kubernetes
cluster
should
I
have
I,
don't
think,
there's
a
best
practice
around
that
answer
like
it
depends
on
how
your
company
segregates
things.
It
depends
on
how
you
understand
kubernetes.
C
It
depends
on
the
way
you
think
about
things,
but
I
know
why
they're
asking
that
question
is
because
kubernetes
presents
itself
as
a
solution
to
a
much
broader
problem
set
than
it
really
is
right.
Kerberos
manages
a
group
of
machines,
typically
backed
by
is
api's.
If
you
have
that,
that's
what
it
does,
it
doesn't
do
everything
else.
It
doesn't
tell
you
exactly
how
you
should
run
your
business.
It
doesn't
tell
you
how
you
should
compartmentalize
your
product
teams,
those
decisions
you
have
to
make
independently
and
once
you
do,
you
can
serialize
those
insecure
Bernette.
C
B
Is
such
a
great
take
on
it
because,
yes
in
the
area
of
backup
people
who
are
doing
back
heavy
in
my
mind,
well
yeah,
it
says
it
should
be
independent
of
company
reason
arts.
But
let's
talk
about
the
people,
we're
not
doing
that
cars
like
what
more
events
you
should
not
do.
Backups
or
obviously
they.
D
D
It
the
other
way
we
so
think
about
it.
Like
this
way,
you
don't
some
people
don't
exercise
because
exercise,
it's
tough
and
it's
hard
and
it's
easier
to
sit
on
the
couch,
eat,
a
bag
of
chips
and
exercise,
and
it's
the
same
thing
with
backups.
Well
acting
up
my
kubernetes
cluster
before
bolero
was
so
hard,
but
I'd
rather
just
invest.
Brain
cycles
in
the
know
didn't
know
how
to
make
money.
So
that's
where
people
come
from
when
it
comes
to
hard
things
like
backups
and.
C
It's
a
trust
element
too
right,
because
we
don't
know
if
the
effort
we're
putting
in
is
worth
it,
but
when
people
do
unit
texting
a
lot
of
times
unit
testing.
This
can
be
seen
as
a
proactive
activity
where
you
write
unit
tests
to
catch
bugs
in
the
future.
Some
people
only
write
unit
tests
when
there's
a
problem,
meaning
wow.
There
are
some
odd
things
in
a
database.
C
Maybe
we
should
write
a
test
to
prove
that
our
code
is
putting
odd
things,
fix
the
code,
and
now
the
tests
pass
and
I
think
it's
really
about
trusting
that
the
investment
is
worth
it
and
I
think
we
start
to
think
about.
Backups
I've
seen
people
backup
a
lot
of
stuff
like
every
day
or
every
couple
of
hours
that
backing
up
their
database,
but
they've
never
restored
the
database.
B
A
Another
really
fascinating
thing
about
the
backup
piece
is
that
it
especially
like
in
this
in
this
in
the
Cooper
Divas
ecosystem,
with
Valero
and
stuffs,
like
we're
so
used
to
having
the
conversation
around
stateless
applications
and
being
able
to
ensure
that
you
can
use
it.
You
could
redeploy
in
the
case
of
a
failure
right,
you're,
not
trying
to
actually
get
back
to
a
known
state,
the
way
that,
like
a
backup
traditionally
what
you're
just
trying
to
get
back
to
a
running
state
and
so
there's
a
bit
of
a
dichotomy
there
freising
for
most
folks
right.
A
They
don't
realize
certain.
Let
me
they
maybe
they're,
not
conceptualizing
the
need
for
having
to
deal
with
some
of
those
stateful
applications
when
they
start
trying
to
think
about
how
Valero
fits
into
the
puzzle.
You
know
because
they've
been
told
over
and
over
again,
this
is
about
immutable
infrastructure.
This
is
about
getting
back
to
running.
This
is
not
about
restoring
some
complex
state,
you
know,
and
so
it's
kind
of
interesting
and.
A
E
C
The
case
is,
what
are
you
backing
up
and
what
do
you
hope
to
restore
right
so
replication
global
replication,
like
we
do
with
like
cloud,
storage
and
s3?
The
goal
is
to
give
some
people
11
9s
of
reliability
and
replicate
that
data,
almost
as
many
geographies
as
you
can
so,
where
it's
almost
like
this
active
backup,
you're
always
backing
up
and
restoring
as
a
part
of
the
system,
design
versus
said,
being
an
explicit
action
and
some
people
would
say
the
type
of
replication
we
do
for
object.
C
D
Is
it
better
to
back
it
up,
or
is
it
better
to
have
a
replica
right
next
to
it
and
then,
having
like
a
10-minute
delayed
replica
right
next
to
that
and
then
replicating
to
Europe
or
Asia
and
then
constantly
querying
the
data
that
you're
replicating?
Is
that
that's
the
backup
and
what
I'm
saying
here
is
that
we
can
change
the
way
that
we
talk
about
it.
Eclipses
are
as
conventional
as
they
they
used
to
be.
There's
definitely
other
ways
to
protect
your
data.
Yeah.
C
So
I
have
a
couple
questions
like:
when?
Should
people
not
use
kubernetes,
you
know
I
mean
like
I
visit
a
lot
of
customers.
I
work
with
a
lot
of
inch
teams
and
I
am
in
the
camp
of
kubernetes
is
not
for
everything
right
and
that's
a
very
obvious
thing
to
say,
but
some
people
don't
actually
practice
it
that
way,
right,
they're
trying
to
jam
more
more
in
the
kubernetes,
so
I
love
to
get
your
insights
on.
Where
do
you
see
crew,
Bernays
being
like
the
wrong
direction
for
some
folks
or
workloads?
C
D
A
A
I
have
a
couple
kind
of
follow-on
questions
for
this
real,
quick,
but
I
do
think
that,
like,
if
you're
not
actively
trying
to
develop
like
a
distributed
system,
something
where
you're
actually
making
use
of
the
primitives
the
kubernetes
provides.
Then
that
already
would
kind
of
be
a
red
flag
for
me
like
if
you're,
if
you're,
building
like
a
monolithic
application
or
if
you're
in
that
place,
we
were
just
rapidly
iterating
on
a
SAS
product
and
you're.
A
Just
trying
to
like
get
as
many
commits
on
the
thing
until
it
works
and,
like
you
know,
just
really
rapidly
prototype
or
even
create
a
thing.
Maybe
Cooper
need
is
distance.
The
right
thing
because,
like
although
we've
come
a
long
way
in
improving
the
tools
that
allow
for
that
iteration,
I,
wouldn't
say,
I,
certainly
wouldn't
say
that
we're
like
all
the
way
there.
Yet
you
know,
but.
A
Right
and
then
the
other
part
of
it
is
the
question
the
other
question
I
have
is,
like
you
know,
kubernetes
aside,
I'm
curious.
What's
the
same
question
as
it
relates
to
containerization
right,
like
is
containerization
the
right
thing
for
everyone
or
or
are
we
or
have
we
made
that
pronouncement
push
I
know.
C
A
E
C
I
think
the
container
to
me
I
treat
as
a
glorified
turbo.
That's
the
way
I've
been
seeing
it
for
years
registry
store
them,
they
replace
yum
great
and
we
kind
of
have
a
more
maybe
universal
packaging
format
that
can
handle
simple
use
cases.
Scratch
containers
where
there's
just
your
binary
and
the
more
complex
use
cases
where
you
have
to
compose
multiple
layers
to
get
the
output
right
and
I
think
rpm
spec
files
used
to
do
something
very
similar.
When
you
start
to
build
those
things
into
chroot.
Alright,
we
got
that
piece.
C
C
People
I
guess
because
it's
easier
to
put
on
your
laptop
people
believe
that
it
needs
to
be
there
so
I
think
kubernetes
is
overused,
because
people
just
don't
quite
understand
what
it
does
and
I
think.
There's
a
case
where
you
don't
use.
Cabernets
like
I
need
to
read
a
file
from
a
bucket
someone
uploaded
in
an
XML
file
and
my
app
is
going
to
translate
it
into
JSON.
That's
it.
In
that
case,
this
is
where
I
think
functions
as
a
service,
something
like
cloud
run
or
even
no.
C
Roku
make
a
lot
more
sense
to
me,
because
the
operational
complexity
is
kind
of
hitting
within
the
provider,
and
it's
linked
almost
like
an
SDK
to
the
overall
service,
which
is
the
object
store
right.
So
the
compute
part
I,
don't
want
to
make
a
big
deal
about
because
it's
only
there
to
process
the
file
that
got
uploaded
right.
It's
almost
like
a
plug-in
to
an
FTP
server.
A
Those
applications
that
require
the
primitives
that
kubernetes
provides
service
discovery
the
ability
to
define
ingress
in
a
in
a
normal
way
when
you
actually
starting
to
to
figure
out
how
you're
going
to
platform
that
application
with
regard
to
those
primitives
I,
do
see
the
argument
for
having
kubernetes
locally,
because
you're
going
to
be
using
those
tools
locally
and
remotely
rightly
have
some
way
of
of
defining
what
that.
But
that
platforming
requirement
is
so.
C
C
So
the
need
for
a
service
discovery
usually
arises
this
when
you
don't
know
where
things
are,
but
if
you're
literally
on
your
laptop,
you
you,
you
know
where
the
things
are
like
you,
don't
really
have
that
problem.
So
when
you
bring
that
problem
space
to
your
laptop
I,
think
you're,
actually
making
things
worse.
I
think
people
depend
on
kerbin
a
service
discovery
for
the
app
to
work,
meaning
they
just
assume
they
can
call
a
thing
by
name
and
they
don't
support
IPS
and
ports.
C
They
don't
support
anything
because
they
said
oh
no
you'll
always
be
running
into
kubernetes.
No,
it's
gonna
happen
in
five
or
ten
years
we're
gonna
be
talking
like.
Oh,
my
god,
you
remember
when
we
used
to
lose
communities,
man
that
legacy
thing
I
built
my
whole
career,
porting,
apps
away
from
kubernetes
for
the
next
thing
and
a
number
one
thing
we'll
talk
about
is
where
people
lean
too
hard
on
service
discovery
or
people
who
build
apps
that
taut
to
confirm
that
config
Maps
directly.
But
why
are
you
calling
the
kubernetes
api
from
your
app?
C
E
A
fair
point
and
two
answers
from
my
end
to
your
question.
So
one
is
I,
just
build
an
appliance
which
basically
bling
tries
to
bring
a
AWS
lambda
X
experience
to
the
vSphere
ecosystem
and
because
we
don't
or
actually
my
approach
is
that
I
don't
want
any
ops
people
who
needs
to
do
some.
One
of
things
like
connect
this
guy
to
another
guy
I,
don't
want
him
to
learn
kubernetes
for
that
right.
It's
just.
It
should
be
as
simple
as
writing
a
function.
E
So
for
that
appliance
we
had
to
decide
how
do
we
build
it
because
it
should
be
scalable.
We
might
have
some
function
as
a
service
component
running
on
there,
so
we
looked
around
and
we
decided
to
put
it
on
kubernetes
to
build
the
appliance
as
a
traditional
VM
using
kubernetes,
and
so
for
me
as
a
developer.
C
Case
you're
building
a
platform
I
would
hate
for
you
to
tell
me
that
you
rebuilt
in
Cooper
neighs,
like
think
just
for
that
appliance
all
right.
So
in
your
case,
it's
a
great
use
case.
I.
Think
the
problem
that
we
have
as
platform
builders
is
what
happens
when
things
start
leaking
up
to
the
user
right
right,
you
tell
a
user.
All
you
have
to
care
about
is
functions.
Then
they
get
some
errors
saying.
Oh
there's
some
kubernetes
security
context
that
doesn't
work
and
I'm
like
what
the
hell
is.
C
E
Point
is
where
I
wanted
to
throw
this
question
back
was
now
these
functions
being
written
as
simple
scripts
or
whatever,
and
the
operators
put
in
they
run
on
kubernetes
know
the
operators
does
know
that
it
runs
in
kubernetes,
but
going
going
back
to
your
question:
when
should
we
not
use
kubernetes?
Is
it
me
writing
in
a
higher
level
abstraction
like
a
function
not
using
kubernetes
in
the
first
sense,
because
I
don't
know
actually
I'm
using
it
by
under
covers
I'm
still
using
it?
C
Seen
these
single
node
appliances
there's
only
one
node
right
and
they're
only
there
to
provide
like
ml
at
a
grocery
store.
Yes,
you
don't
have
a
distributed
system
now.
What
people
want
is
the
kubernetes
api?
The
way
it
deploys
things
the
way
it
swaps
out
of
running
container
for
the
next
one?
We
want
that
kubernetes
api
today.
The
only
way
to
get
it
is
by
essentially
bringing
up
a
whole
kubernetes
cluster
I.
Think
the
k3s
project
is
trying
to
simplify
that
by
re-implementing
kubernetes,
no
FEC
de
Cicco
light.
C
Instead,
a
single
binary
that
has
everything
so
I
think
what
we
start
to
say.
What
is
kubernetes
there's
the
implementation,
which
is
a
big
distributed
system
and
there's
the
API
and
I
think
what's
going
to
happen
is
if
you
want
the
Cooper
nase
API
you're
gonna
have
so
many
more
choices
on
the
implementation,
the
better
sense
for
the
target
platform.
D
Maybe
what
happened
McCune
ends
over
the
next
few
years
is
what
happened
with
with
the
Linux
API
or
the
ABI
you
can
in
firecracker
and
jeep
visor
did
this
weekend.
Wsl
did
this.
We
can
basically
swap
out
Linux
on
the
back
end,
because
we
can
just
get
all
the
calls.
So
maybe
that
will
happen
with
kubernetes
as
well,
so
maybe
kubernetes
will
become
a
standard
where
you're,
where
it's
kubernetes
to
stand.
There
then
kubernetes
the
implementation
that
we
have
right
now.
I,
don't
even
know
about
that
that
one
we're.
C
Starting
to
see
it
right,
so
when
you
say
here's
my
pod
and
we
can
just
look
at
Fargate
for
eks
as
an
example,
when
you
give
them
a
pod,
their
implementation
is
definitely
different
than
what
most
people
are
thinking
about.
Our
running
these
days
right,
one
pod
per
VM,
not
using
virtual
cube
so
they've,
taken
that
pod
spec
and
try
to
uphold
its
means,
but
the
problem
with
that
you
get
leaks.
For
example,
they
don't
allow
you
to
bind
to
a
host
port.
C
Well,
the
pod
spec
says
you
can
bind
to
a
host
for
the
implementation,
doesn't
allow
you
to
do
it
and
we
see
the
same
problem
with
G
Weiser.
It
doesn't
implement
all
the
system
costs
right
like
you
couldn't
run
the
docker
daemon
on
top
of
GE
Weiser.
It
wouldn't
work
so
I
think.
As
long
as
we
don't
leak
right,
because
when
we
leak,
then
we
start
breaking
stuff.
So.
D
We're
doing
the
same
thing
with
project-specific
here
at
being
with
her
they're
a
where
this
concept
of
a
pod
is
actually
a
virtual
machine
that
loops
in,
like
tenth
of
a
second,
it's
pretty
crazy,
how
they,
how
they've
been
able
to
figure
that
out.
So
if
we
can
get
this
right,
though,
that's
that's
huge
for
us.
That
means
we
can
move
out
of
our
vines
and
we
can
create
better
things
that
actually
work
on
one
being
working
specific
I'm
on
AWS
and
I
want
this.
Namespace
I
can
use
Fargate
in
eks
yeah.
E
I
remember
this
presentation
cuz,
he
did,
you
gave
I
think
two
or
three
years
ago
might
might
be
three
years
where
you
took
the
kubernetes
picture
and
you
remove
the
boxes
and
the
only
thing
remaining
was
the
API
server,
and
this
is
where
it
clicked
to
me.
It's
like
this
is
right
because
I
was
focused
on
the
scheduler
I
wanted
to
understand
the
scheduler,
but
then
you
zoomed
out
you
stripped
of
all
these
pieces
and
the
only
thing
remaining
was
the
API
server
and
there.
E
This
is
where
it
clicked
to
me:
it's
like,
like
gilepsy
or
like
the
Cisco
interface,
it's
basically
my
API
to
do
some
crazy
things
that
I
would
have
ride
on
my
own
and
assembly
kind
of
some
things
before
I
couldn't
even
get
started,
and
this
was
a
breakthrough
moment
for
me.
This.
The
specific
presentation,
I'm.
C
Working
on
an
analogy
to
talk
about
what's
happening
with
the
kerbin
api,
I
haven't
refined
it
yet,
but
it's
when
the
web
came
out,
we
had
all
of
these
HTTP
verbs
put
posts,
get
we
have
a
body,
we
have
headers
and
you
can
extract
that
out
of
the
whole
web
right,
the
web
browser
plus
the
web
server.
And
if
you
have
tracked
about
that
one
piece,
then
we
instead
of
building
web
pages,
we
can
build
api's
and
craft.
You
well
right,
because
we
can
reuse
many
of
those
mechanisms
and
we
just
called
it
restful
interfaces.
C
C
So
maybe
you
start
with
helm
and
then
helm
gets
piped
into
something
like
customize.
That
then
gets
piped
into
an
admission
controller
right.
That's
how
kou
Bernays
actually
works
and
that
data
model
to
API
development,
I
think
is
gonna,
be
a
unique
thing
that
lasts
longer
than
the
curb
renée's
container
platform.
Does
we're.
B
Talking
about
correct
me,
if
I'm,
if
I
misinterpret
platform
is
there,
there
are
to
me,
is
meant
to
be
consumed
and
I
actually
have
been
thinking
since
said:
oh,
we
should
developers
should
not
be
developing
apps
that
connect
directly
to
kubernetes,
so
the
figure
said
the
kubernetes
api
and
then
I
was
thinking
way.
I
heard
I've
heard
so
many
times.
People
saying
that
that's
one
great
benefit
of
communities
that
the
apps
have
that
access.
So
now,
if
you
see
my
confusion,
please
clarify
it.
Yeah.
C
So
alright
I
remember
early
on
when
we
were
doing
config
Maps
and
then
the
big
debate
about
how
config
master
should
be
consumed
by
the
average
application.
So
one
way
could
be:
let's
just
make
a
config
Maps
API
and
tell
every
developer
that
they
need
to
import
a
kubernetes
library
to
call
the
API
server
right.
So
now,
everybody's
app
doesn't
work
anymore
on
your
laptop,
so
we
were
like,
of
course
not.
What
we
should
do
is
have
config
Maps
be
injected
into
the
file
system.
C
So
that's
why
you
can
actually
come
to
describe
a
config
map
as
a
volume
and
say
take
these
key
values
from
the
config
map
and
write
them
as
normal
files
and
inject
them
into
the
container.
So
you
can
just
read
them
from
the
filesystem.
The
other
option
also
was
environment
variables
right.
You
can
take
a
config
map
and
translate
them
into
an
environment
variables.
And,
lastly,
you
can
take
those
environment
variables
and
put
them
into
command
line
flex.
C
So
the
whole
point
of
that
is
all
three
of
the
most
popular
ways
of
configuring:
an
app
environment,
variables,
command
line
flags
and
comment
and
and
files
kubernetes
molded
itself
into
that
world,
so
that
developers
would
never
tightly
coupled
themselves
to
the
kubernetes
api.
Now,
let's
say
you're
building
a
platform
like
you're
building
a
workflow
engine
like
argo
or
you're,
building
a
network
control
plane
like
sto.
Of
course
you
should
use
the
kubernetes
api
right,
you're,
building
a
platform
on
top
of
a
platform
and
I
would
say
that's
kind
of
the
exception
to
the
rule.
C
If
you're
building
a
platform
but
a
general
application,
that's
leveraging
the
platform.
I
really
think
you
should
stay
away
from
the
kubernetes
API
directly
right.
You
shouldn't
be
making
sis
calls
that
directly
add
abandon
of
your
runtime
right
like
the
unsafe
package
and
go
once
you
start
doing
that
goat
can't
really
help
you
anymore.
You
start
paying
yourself
to
specific
threads
you're
gonna,
be
in
a
bad
time
right.
C
That
was
the
whole
benefit
of
coop
and
docker,
even
saying
you
know
what
don't
worry
too
much
more
about
sea
groups
and
namespaces.
Don't
even
try
to
do
that.
Your
second
remember
there
was
a
period
of
time
where
people
were
actually
trying
to
build
sea,
grooves
and
network
names
and
namespaces
into
the
runtime
right,
there's
a
bunch
of
like
Ruby
and
Python
projects
that
they
were
trying
to
containerize
themselves
with
in
the
runtime
whoa.
C
I
had
to
have
the
fortunate
time
to
spend
some
time
with
mark
where's
right.
He
came
out
with
the
promise
theory
right
and
the
promise
there
is
the
underpinnings
of
puppet
chef,
ansible
cfengine,
and
this
idea
that
we
would
make
promises
about
something
and
eventually
convergent
to
that
state.
Yeah.
The
problem
was
with
puppet
chef
and
ansible.
We
were
basically
doing
this
with
shell
scripts
and
Ruby.
Right,
like
we
were
trying
to
write
all
of
these.
If
and
else
statements,
and
when
those
didn't
work.
What
did
you
do?
C
You
made
an
exact
statement
at
the
bottom
and
then
you're
like
oh,
just,
run
some
bash
and
who
knows
what's
going
to
happen
and
the
other
that
was
a
yeah
and
that
early
implementations
of
premise
theory:
we
didn't
own
the
resource
that
we
were
making
promises
about
right,
like
anyone
could
go
behind
us
and
remove
the
user
or
the
user
could
have
a
different
user
ID
on
different
systems,
but
mean
the
same
thing
in
the
kubernetes
world.
We
pushed
a
lot
of
that.
C
If
else
statements
into
the
controller
we
forced
the
API
not
to
have
any
code,
that's
the
big
difference.
If
you
look
at
the
kubernetes
api,
you
can't
do
if
statements
terraform,
you
can
do
if
statements,
so
you
kind
of
fall
into
the
imperative
trap
at
the
worst
moments
when
you're
doing
dry
runs
or
something
like
that
and
and
it
does
a
really
good
job
of
it.
Don't
get
me
wrong,
so
the
kubernetes
api
says
you
know
what
we're
gonna
go
all-in
on
this
idea.
You
have
to
change
the
controller
first
and
then
update
the
api.
C
E
So
we
got,
we
got
swagger,
we
got
API
definitions,
but
he
made
the
very
easy
D
point
of
if
I
give
you
an
open,
expose
and
I
write
and
read,
method
or
an
API
you'd
still
don't
know
how
to
call
them
in
sequence,
and
we
want
to
call
it
all,
and
this
is
simple
to
go
for
the
go
SDK
for
standard
library.
If
you
look
at
that,
so
I
always
have
to
force
myself
should
I
need
to
cook
or
close
or
I'm,
not
leaking
some
stuff,
and
so
I.
Look
it
up
versus
some
protocols.
E
If
you
look
at
the
RFC
definitions,
they
are
very,
very
precise
and
very
cleanly
outlined
and
of
what
you
should
do,
how
you
should
behave,
how
you
should
communicate
between
those
systems,
then.
So
this
is
more
about
communication
and
less
about
the
actual
implementation
of
an
API
and
I
still
have
to
go
through
that
talk
again
and
I'm.
Gonna
put
it
in
the
show
notes,
but
this
kind
of
opened,
my
my
my
mind
again
a
little
bit
think
more
about
communication
between
systems
and
contracts
and
promises
at
us.
C
They,
given
the
curse
of
carbonate,
is
that
it
does,
but
it
tries
to
do
both
all
the
time
right
for
some
things
like
a
pod
or
deployment.
We
all
feel
that
if
I
give
a
Miku
Bernays
cluster,
a
deployment
object,
I'm
gonna
get
back
a
running
pod.
This
is
what
we
all
believe,
but
to
think
is.
It
may
not
necessarily
run
on
the
same
kernel.
It
may
not
run
on
the
same
OS
version.
It
may
not
even
run
on
the
same
type
of
infrastructure
right.
So
this
is
where
I
think
criminate
is
ends
up
leaking.
C
Some
of
those
protocol
promises
right.
A
pod
gets
you
a
deployment,
gets
you
a
set
of
running
pods,
but
then
we
drop
down
to
a
point
where
you
can
actually
do
your
own
API
and
build
your
own
protocol
like
so
I.
Think
you're,
right
sto
is
a
protocol
for
thinking
about
service
to
mesh,
whereas
Cabernets
provides
the
api
for
building
such
a
protocol.
A
So
on
the
Fargate
stuff,
I
thought
it
was
really.
It
was
a
really
interesting
article
or
actually
an
interesting
project.
By
up
here,
o
suta
I
want
to
give
him
a
shout-out
in
this,
because
I
thought
was
really
interesting.
He
wrote
a
an
admission
controller
that
leverages
autoscaler,
node
affinity
and
pod
affinity
to
effectively
do
the
same
thing
so
that
whenever
there
is
a
new
pod
created,
it
will
spin
up
a
new
machine
and
associate
only
that
pod
with
that
machine.
A
C
I
think
that's
the
thread
that
virtual
cube
was
pulling
on
right.
This
idea
that
you
can
simplify
auto
scaling
if
you
remove
that
layer
right,
because
right
now
we're
trying
to
do
this
musical
chairs
dance
right
like
in
the
cloud.
Imagine
if
someone
gave
you
the
hypervisor
and
told
you
you're
responsible
for
attaching
hypervisor
workers
and
the
VMS,
it
would
be
a
nightmare.
We
wouldn't
be
talking
about
auto-scaling
the
way
we
do
in
the
cloud,
so
I
think
kubernetes
moving
into
a
world
where
one
pod
per
resource
envelope
today
we
call
them
VMs,
but
I.
C
Think
at
some
point
we're
gonna
drop
the
VM
and
we
would
just
call
it
a
resource
envelope
and
vm's.
This
is
the
way
we
think
about
that
fire
crackers
like
hey.
Does
it
really
need
to
be
a
complete
VM
and
fire
crackers
saying?
No
it
doesn't.
It
just
needs
to
be
a
resource
envelope
that
allows
you
to
run
their
particular
workload.
C
C
Again,
it's
just
like
compute
on
edge
has
been
a
topic
for
discussion
forever.
Yep
problem
is
when
some
people
say
compute
on
edge,
they
mean
like
go,
buy
some
servers
from
Darrow
and
putting
it
in
some
building
somewhere
as
close
to
your
property
as
you
can,
but
then
you
have
to
go,
build
the
api's
to
deploy
to
that
edge.
What
people
want
and
I
don't
know
how
far
off
it
is.
Makuu
Bernays
has
set
the
bar
so
high
that
the
turbinates
api
comes
with
the
way
to
low
balance
attached
storage.
C
All
of
these
things
by
just
writing
a
few
llamó
files.
So
what
I
hear
people
saying
is
I
want
that
close
to
my
data
center
or
store
as
possible.
So
when
you
say
kuba
is
on
the
edge.
That's
what
they're
saying
it's
like.
What
we
currently
have
on
an
edge
is
not
enough
right.
Well,
like
we've,
been
taught
we
bit
in
providing
edge
for
a
very
long
time.
Openstack
was
me,
remember,
OpenStack,
oh
we're
gonna
do
OpenStack.
C
D
Stores
have
been
doing
this
for
forever
in
some
form
or
another.
Twenty
years
ago,
I
worked
for
a
duty-free
place
and
literally
traveled
all
over
the
world,
replacing
point-of-sale
you
might
think
of
Point
of
Sales.
It's
a
cash
register.
There
was
a
computer
back
and
it
was
rs-232
links
to
from
the
cash
register
to
the
computer
in
the
back,
and
then
there
was
dial
up
or
at
least
line
to
our
central
thing.
D
We've
been
doing
edge
for
a
long
time,
but
now
we
can
do
edge
and
the
central
facility
can
actually
manage
the
computer
infrastructure.
All
they
care
about
is
basically
CPU
and
memory
and
network
storage
now,
and
it's
a
lot
more
flexible.
So
this
this
journey
is
long
but
I
think
where
we're
gonna,
do
it
it's
gonna
happen
and
I
think
we're
almost
ready.
You.
C
Verizon
is
starting
to
allowed
these
edge
components
to
leverage
5g
for
the
last
mile
and
that's
a
game
changer,
because
most
people
are
very
skeptical
about
5g
being
able
to
provide
the
same
coverage
as
4G
right
because
of
the
wavelength,
and
you
know
point-to-point
all
these
things,
but
for
edge.
This
thing
is
a
game-changer
higher
bandwidth,
but
you
know
shorter
distance.
This
is
exactly
what
edge
wants
right
now.
You
don't
have
to
dig
up
the
ground
and
run
fiber
from
point
to
point.
C
So
if
you
combine
these
kubernetes
api's
plus
concepts
like
5g
and
giving
that
closer
to
people,
yeah
I
think
that's
gonna
change
the
way
we
think
about
regions
and
zones
that
kind
of
goes
away.
We're
gonna,
move
compute
closer
to
CD
ends
like
CloudFlare,
has
been
experimenting
with
what
there
were
core
technology.
A
Well,
the
edge
stuff
I
think
that
there's
also
an
interesting
dichotomy
happening
right.
There
there's
a
definition
of
edge
that
we've
referred
to
edge,
isn't
storage
buffer
and
one
that
you're
alluding
to,
which
is
that
you
know
there
may
be
like
some
way
of
actually
having
some
edge
capability
at
a
point
of
presence
in
the
year
and
a
5g
tower,
or
some
point
like
that.
A
In
some
cases,
edge
means
data
gravity
right,
like
you're,
actually
taking
a
bunch
of
data
from
sensors
and
you're
trying
to
store
it
in
a
place
where
you
don't
have
to
pay
the
cost
of
moving
all
the
data
from
one
point
to
another,
where
you
can
actually
centralize,
compute
and
so
like
in
those
edge
cases,
you're
actually
willing
to
invest
in
the
about
a
high-end
compute
to
allow
for
the
manipulation
of
that
data.
Where
that
data,
like
is
so
that
you
can't
afford
to
move
it
into
some
centralized
location
later.
A
C
You
know
that
thing
so
once
we
start
to
do
this,
for
like
email
capabilities,
security
capabilities,
I,
think
you're,
just
gonna
see
that
POS
like
Bing,
expand
and
then
computers
or
get
a
little
bit
more
robust
to
do
exactly
what
you're
saying
right
treat
the
data
local.
Maybe
you
ship
models
to
that
thing
so
that
it
can
get
smarter
over
time
and
then
upload
the
data
from
various
stores
over
time.
Yeah.
E
One
last
question
from
my
end:
switching
gears
a
bit
if
allowed
q
Khan,
so
I
left
Q
Khan
with
some
mixed
feelings
this
year,
but
my
my
perspectives
different
because
I'm,
not
the
typical
one
of
these
two
twelve
thousand
people,
because
most
of
them
were
newcomers
actually
and
so
I
looked
at
them
and
as
I
asked
myself.
If
I
would
be
new
to
this
huge
big
world
of
cincy,
eV
and
communities
and
all
the
stuff.
D
Isn't
anything
and
Kelsey
was
a
cube
contraire
before
I
was
but
I
was
a
cube
contraire
this
time
and
I
can
tell
you
exactly
why
every
like
it
is
unfortunately
well
fortunately,
and
unfortunately,
this
cloud
Native
community
is
huge.
Now,
there's
lots
of
money.
There's
lots
of
people
there's
lots
of
interest.
If
we
would
went
back
to
coop
con
when
it
was
in
San,
Francisco
years
o
or
even
like
the
first
Seattle
one
that
was
a
it
was
a
community
event.
D
We
could
make
the
event
for
the
community
now
with
there's
community
the
people
who
are
creating
the
products,
there's
the
end
users,
the
people
who
are
consuming
the
products
and
there's
these
big
corporations
and
companies,
the
people
who
are
actually
financing
this
whole
entire
thing.
We
actually
have
to
balance
all
three
of
those.
So
as
a
person
who
just
wants
to
learn.
What
are
you
trying
to
learn
from?
Are
you
learning
from
the
consumption
piece?
Are
you
learning
to
be
a
vendor?
Are
you
learning
to
be
a
contributor?
D
So
you
have
to
think
about
that
and
at
a
certain
point
that's
that's
good
for
kook,
that's
good
for
kubernetes!
It
means
that
we've
been
able
to
do
that.
Whole
chasm
thing
we've
crossed
over
to
chasm.
This
thing
is
real.
It's
big!
It's
going
to
make
a
lot
of
people
a
lot
of
money
one
day,
but
I
do
see
the
issue
for
the
person
who's
trying
to
come
in
and
say
what
do
I
do
now.
Well,
unfortunately,
it's
like
anything
else.
What
do
you?
Where
do
you
start?
D
Well,
you
take
it
all
in
so
you
need
to
figure
out
where
you
want
to
be
and
I'm
not
gonna,
be
the
person.
That's
gonna.
Tell
you
well
go
to
a
sick,
that's
that's
not
it!
What
I
want
to
tell
you
is
like
anything
else
that
we've
had
to
learn.
That's
real
Hardware,
this
programming
language
or
a
new
technique,
figure
out
where
you
want
to
be,
and
you're
gonna
have
to
do
some
research
and,
and
then
hopefully
you
can.
You
can
contribute
and
I'm
sure
Kelsey
has
thinking
on
this
as
well.
If
you.
C
Think
I
think
Brian's
right,
I
mean
I.
Think
it's
just
like
a
pyramid
happening
at
the
very
bottom
Onew.
We
need
to
get
everybody
together
in
one
space
and
it
becomes
more
of
a
trade
show
like
an
introductory
like
a
tasting
right
when
you're
hungry
and
you
go
and
just
taste
everything,
and
then
you
figure
out
what
you
want,
and
that
will
be
your
focus
and
that's
gonna
change
every
year
for
a
lot
of
people.
Some
people
go
from
consumer
to
contributor
and
they're.
C
Gonna
want
something
out
of
the
conference
like
they're
gonna
only
want
to
go
to
the
contributor
day,
and
maybe
some
of
the
deep
dive
tentacle
tracks
so
you're
trying
to
serve
everybody
in
two
or
three
days
right.
So
you're
gonna
start
to
have
like
everything
pulling
for
your
attention,
everything's
pulling
for
your
attention
and
I
think
what
you
got
to
do
is
commit
like
as
a
if
you
go
and
you're
a
contributor
or
you're
someone
that's
building
on
top.
You
may
have
to
find
a
separate
event
to
kind
of
go
with
it.
C
So
when
I
go
I
like
to
meet
new
people,
sit
down
with
them
out
of
the
12,000
people,
I
call
it
a
win
if
I
can
meet
three
new
people
that
I've
never
met
before,
and
you
know
what
I'll
do
a
follow-up
hangout
with
them
to
go
deeper
in
some
areas,
so
I
think
it's
more
of
a
catch-all.
This
definitely
has
a
tradeshow
feel
now
because
it's
big
and
there's
a
lot
of
money
and
opportunity
involved.
C
But
at
the
same
time
you
got
to
know
that
hey
you
got
to
go
and
seek
out
like
you
got
a
Spotify
right.
Spotify
has
so
much
music,
so
many
dramas
I've
never
heard
of.
But
you
got
to
make
your
own
playlist.
You
got
to
decide
what
you
want
and
also
look
go
to
sessions.
You
know
nothing
about
be
confused
on
purpose
like
you're,
not
gonna
Spotify,
sometimes,
like
you
know
what
what's
happening
in
country
music
right
now,
country,
music,
top
ten.
C
You
know
what
I'll
try
it
I
will
literally
try
a
new
drummer
and
just
let
it
play,
and
then
you
what
you
find
is
you'll
find
one
song
is
like
oh
hold
on.
Who
is
that?
And
it
turns
out
that
one
new
artist
I
actually
like
some
of
their
music
and
then
I
dive
deep
in
that
artist,
maybe
not
the
whole
genre
yeah.
B
It's
like
when
you're
in
school
and
you
go
to
class
and
you
didn't
win.
You
do
homework,
didn't
do
any
of
the
reading.
You
sit
down
you're
like
I,
sighs,
I
empathize,
with
the
amount
amount
to
sort
through,
but
if
you
just
slice
it
and
so
through
a
piece
of
that
select
and
like
Kelsey
is
saying
also
I
agree
with
that.
D
Works
for
me,
one
less
thing:
I'll
say
one
last
thing
on
this:
if
the
market
decides
that
a
certain
segment
of
users
are
not
being
taken
care
of
there'll,
be
another
conference
and
I
think
you
should
go
to
that
conference.
Cn
CF
does
not
own
all
the
brain
space
for
cloud
native
and
and
and
kubernetes
so
we'll
let
the
market
figure
that
out,
but
you're
right
over.
D
So
we
were
twelve
thousand
people
like
this
two
weeks
ago,
in
San,
Diego
I'm,
not
sure
how
big
I
am
surname
will
be
and
I'm
sure
Boston
will
be
that
size,
maybe
maybe
15,
maybe
even
more
people,
so
the
community
or
the
the
ecosystem
will
figure
it
out.
Like
we've
done
it
with
everything
we
don't
just
have
programming
where
you
set
programming
conferences.
Now
we
have
all
these
languages,
so
we're
growing.
But
it's
a
good
thing.
As
now.
We
can
actually
focus
on
some
of
things
that
we
want
to
talk
about,
but.
C
Keep
asking
that
question
you
know
to
me:
I
think
that
authenticity
when
I
don't
see
it,
you
got
to
remind
people
of
it.
You
don't
even
mean
like
this
year
when
I
decided
to
what
to
talk
about.
During
my
keynote
I
decided
to
strip
away
to
the
live
demos,
stripping
away
a
lot
of
the
stuff,
and
just
say
you
know,
maybe
I'll
try
something
new
right
into
the
trying
to
bring
it
back
down
to
my
own
kind
of
ground
level,
and
we
need
everything
we
need
people
pushing
the
bar.
C
B
E
C
Yeah
I
mean
I
always
end
with
just
pay
attention
to
the
fundamentals.
That's
the
people
stuff.
Fundamentally,
we
just
people
working
on
some
stuff.
Fundamentally,
the
technology
is
roughly
the
same
when
I
peel
back
my
ten
years.
The
tech
looks
very
similar
that
it
did
ten
years
ago,
except
for
the
way
we
do.
It
is
slightly
different
and
I
think
people
should
find
a
little
bit
of
encouragement
and
in
that
that
this
isn't
overwhelming
new.